Subject: Re: Options, was Re: To Be, or NR To Be ...

From: "David P. Kemp" <[email-masked]>
Date: Wed, 25 Aug 1999 14:47:50 -0400 (EDT)

> From: Tony Bartoletti <[email-masked]>
> 
> In some ways, the NR-bit is like marketing bottles of wood alcohol that
> are simply labeled "alcohol".  The designation is "not necessary" to those
> that have performed investigation and use the liquid for cleaning purposes.
> The designation is "not sufficient" for those who assume that the liquid
> is grain alcohol and can be taken internally.

Your position is that more information on the label is better?

What label should be attached to a key which is known to be relatively
less suitable for supporting a NR process (perhaps because the binding
between a single individual and a specific private key is weak or
nonexistent) - "Key, NR=0", or simply "Key" ?

The "necessary and sufficient" line of reasoning is as bogus with
respect to the NR bit as it is with respect to any other bit.  A
necessary and sufficient statement says that the set of keys (or more
generally, the set of technologies) which can support and will provide
an XX operation is identical to the set of keys which have the XX bit
asserted in a certificate.  No matter what you value you substitute for
XX (digitalSignature, nonRepudiation, keyEncipherment, ...
decipherOnly), the "necessary and sufficient" condition is patently
false.  We have the keyUsage extension because a cert with it provides
more information than a cert without it, not because the extension is
either necessary or sufficient to achieve any particular security
goal.

---

From: Elliot Ginsburg <[email-masked]>
Date: Wed, 25 Aug 1999 16:08:36 -0400

I think everyone agrees that the keyUsage extension provides more
information than would be present without it. The discussion on this
list seems to be, exactly what information does it provide? Anyone have
a clear proposal to make for what it means, other than 'go read the
CPS', because this adds nothing.

It seems easy to decide that NR==0 means 'don't use it for NR' (if
critical, you're forbidden to; if non-critical, you're advised not to).
But what exactly does NR==1 convey? From reading this list, I might
conclude it means 'you might want to use it for NR, depending on the
policy, your requirements, and the availability of NR services to you'.
While this doesn't do much, at least NR==0  is still very useful.

Elliott N Ginsburg
CygnaCom Solutions
[email-masked]
703-848-0883
703-848-0960(FAX)

> -----Original Message-----
> From:	David P. Kemp [SMTP:[email-masked]]
> Sent:	Wednesday, August 25, 1999 2:48 PM
> To:	[email-masked]
> Subject:	Re: Options, was Re: To Be, or NR To Be ...
> 
>

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 25 Aug 1999 18:32:24 -0600

Elliot,

A couple of observations.

First, I'm not sure that I agree that if the keyUsage extension is critical, 
and NR==0, that you are forbidden to use "it" (whatever "it" might be).

I know that this issue has been discussed previously in conjunction with another
attribute, and I may not be remembering it properly, but I thought that the 
Critical bit merely meant "if you don't understand what this bit means, 
you should reject the certificate"  That's not quite the same thing as 
saying "if you do understand what this bit means, you are absolutely
compelled to either do or not do that thing, under pain of ...?"

Secondly, although NR==0 clearly means, "you shouldn't assume that
the NR property applies" it isn't clear that that is useful if I don't know what
NR means.  What is the CA, the subscriber, and/or the relying party 
supposed to do in that case?  It still isn't clear, and so it's an empty bag.
Maybe NR means, 'hang your clothes on a hickory limb, and don't
go near the water." :-)  I don't know what that means, either.

I am beginning to be of the opinion that we should deprecate the NR 
bit entirely, and then define several new bits to define exactly what we 
do mean, as I suggest under the "subdividing the NR bit" thread.

I certainly agree that "go read the CPS" adds little or nothing. Does
NR==0 mean that I don't have to read the CPS?  If so, that would be 
a very useful thing to have, but I don't think it means nonrepudiation. :-)

At this point, I am afraid that there is so much baggage, implied semantics,
and past history in the name "nonrepudiation" that I don't think we will 
ever achieve consensus.

There is a little bit of merit in Ed's Proof of Authentication label, but that doesn't
really connote what I would like at least one of the bits to mean.  And 
"rebuttable presumption" also has some merit, and so does "intent to sign".

I think that everyone but Steve Kent believes that the name "nonrepudiation" 
conveys something quite different than the current definition, which to my 
mind at least is hopelessly vague and circular.  However, we have not 
yet achieved consensus on one single definition of what it does mean, 
in part, I think because there are multiple things going on that are all 
interrelated, and a single bit is simply not sufficient to cover them all.

What do others thing about deprecating NR, and starting over with a 
clean sheet of paper?

Bob
>
>
>>>> Elliot Ginsburg <[email-masked]> 08/25/99 02:08PM >>>

---

From: Elliot Ginsburg <[email-masked]>
Date: Thu, 26 Aug 1999 08:32:08 -0400

Bob,

The reason I interpreted critical/non-critical the way I did is this
from X.509 keyUsage bit:
"This extension may, at the option of the certificate issuer, be either
critical or non-critical. 
If the extension is flagged critical, then the certificate shall be used
only for a purpose for which the corresponding key usage bit is set to
one. 
If the extension if flagged non-critical, then it indicates the intended
purpose or purposes of the key, and may be used in finding the correct
key/certificate of an entity that has multiple keys/certificates. It is
an advisory field and does not imply that usage of the key is restricted
to the purpose indicated. A bit set to zero indicates that the key is
not intended for that purpose. If all bits are zero, it indicates the
key is intended for some purpose other than those listed. "

As far as NR==0, here's what I meant. Since we can't agree on exactly
what NR means, we'll leave it to the replying party to know whether
he/she has access to a non-repudiation service.  But even if he/she
does, a cert with NR==0 can't be used for this purpose; a cert with
NR==1 is required. I don't think this is very interoperable across
security domains, however. 
Here's what I think the difference between authentication and NR is:
authentication lets me identify a transactor at this time;  NR, in
addition to the above, implies that I will be able to re-do that
authentication process, for that moment in time, for some significant
time into the future. NR probably requires archiving and the like,
although there are probably other ways to do it; authentication only
requires the ability to complete the validation in the present or near
present, not five years from now.
Yes, if we can't agree on what it means, then we should deprecate its
use.

Elliott N Ginsburg
CygnaCom Solutions
[email-masked]
703-848-0883
703-848-0960(FAX)

> From:	Bob Jueneman [SMTP:[email-masked]]
> Sent:	Wednesday, August 25, 1999 8:32 PM
> To:	[email-masked]; [email-masked]
> Subject:	RE: Options, was Re: To Be, or NR To Be ...
> 
> Elliot,
> 
> >> > In some ways, the NR-bit is like marketing bottles of wood
> alcohol
> >> that
> >> > are simply labeled "alcohol".  The designation is "not necessary"
> to
> >> those

---

From: Ivan Milman <[email-masked]>
Date: Thu, 26 Aug 1999 12:46:05 -0500

EG = Ed Gerck
AWA = Al Arsenault

EG> First, of course, a necessary and sufficient condition for a certificate to be
EG> verifiable is for it to be digitally signed.  So, I guess this much is OK and
EG> equivalent: "certificate is signed" <--> "certificate is verifiable".  A certificate
EG> is verifiable if and only if it is signed -- the "if" is a sufficient condition and
EG> the "only if" a necessary condition.

AWA>The fact that is certificate is signed does NOT make it verifiable.

EG> Yes it does, as verifiable as the signature allows it.  If a certificate
EG> IS signed THEN I affirm that this is equivalent to saying that the
EG> certificate is verifiable -- where, of course, "is verifiable" means that
EG> it CAN be verified.  And, of course, the fact that it CAN be verified
EG> does not mean that it MUST be verified.  Of course, it also depends
EG> if the available public-keys match the signature (maybe not, and maybe
EG> you need more keys), if the public-key that matches has not been
EG> revoked, etc.  But, nonetheless the certificate is verifiable and the
EG> result is either YES or NO -- if the certificate is signed.

Believe it or not, gents, I think you are in agreement here.  If we were to
say that a signature on a certificate is necessary but not sufficient for verification,
then I think everybody would be happy.  Ed seems to think so, by stating:

EG> Of course, it also depends
EG> if the available public-keys match the signature (maybe not, and maybe
EG> you need more keys), if the public-key that matches has not been
EG> revoked, etc.

and I'm pretty certain Al had similar statements in his original posting on this thread.

Thanks,
Ivan

Ivan M. Milman	Technical Director	DASCOM
email:  [email-masked]		phone: 1-512-458-4037, ext. 5014

---

From: Ed Gerck <[email-masked]>
Date: Thu, 26 Aug 1999 13:52:53 -0700

Alfred Arsenault wrote:

> Ed,
>
>         Please accept my apologies if your feelings were hurt, but quite
> frankly I'm getting really tired of your continual twisting of my (and
> other people's words) to support whatever mindgame you have going on at
> the moment.

I regret that you interpret my messages as mindgames and that you choose 
to talk for others.  And, I also regret in the name of future dialogue 
that you have really not recalled your previous misstatements.  I also 
remind you that you have now more than two weeks of no-reply to my very
clear questions of August 11 -- even though you asked for them with the
now usual emphasis.

>               If you give me a signed certificate, and I want to determine if it is
> valid for my purposes as a relying party, I can get one of three
> results:
>         - yes, the certificate is valid;
>         - no, the certificate is invalid (for whatever reason, such as it
> expired, has been revoked, contains the wrong subject DN, etc.)
>         - I don't know; there's not enough information (because I can't trace
> back to a trust anchor, or I can't get the necessary CRL/OCSP response,
> etc.)

If you need to make a decision, it is always YES or NO.  A decision can't
be MAYBE or DON'T KNOW.

If I give you my signed certificate and you are going to decide whether to
rely on it in order to send me merchandise, then the "I don't know" case is NO.
However, if you need to rely on my certificate in order to send me a query
by email, then the "I don't know" case is YES.

Either way, the cert is verifiable because it is signed -- a value of either
YES or NO is assigned to the final state.

BTW, and that is what every browser does -- either the cert is accepted or
not according to the trust-points it has acquired, but a cert is always 
verifiable if signed.  Of course, you may argue that the  browser will not
be able to verify the cert if it is signed with a PGP syntax -- but, in 
fact, the browser is able, since it will refuse to accept the cert and the
final state in verification will be NO.

Cheers,

Ed Gerck

---

From: [email-masked]
Date: Wed, 25 Aug 1999 14:48:22 -0400

(snip)
> Although I agreed that use of the NR bit is neither necessary nor
> sufficient, in isolation, I have also given many examples of where the bit
> of of significant benefit in an overall NR scheme.

I do not recall any use of the "NR bit" in isolation and I don't think it
would be usable either.  The statement that the NR bit is neither necessary nor
sufficient to provide NR services had no indeed no opposition in this WG --
and this statement simply proves that NR services are independent of such
NR bit, q.e.d.

[Tom Gindin]   I think this is a bit of an overstatement.  While there is no, or
very little, opposition to the statement that the NR bit is not sufficient for
the NR service, it is not clear that the bit is not necessary or at least highly
desirable for the service.  And, while "highly desirable" would leave the NR
service logically independent of the NR bit, this no more establishes the
uselessness of the NR bit than the usability of X.509v1 certificates for digital
signature establishes the uselessness of the digital signature bit.

(snip)