Deprecate the NR bit?

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

Elliot,

I should have rechecked the text regarding the Critical bit.

As to the difference between "Alice" (what you call authentication,
which is semantically yet another deep pit) and the "Nancy Reagan"
bit, I would quibble just a bit.

What you call the "Alice" condition (NR=0) would seem to imply 
that the signature and certificate chain can be trusted for the 
duration of the certificate validity interval,, not just at the moment,
 assuming that the RP checks the CRL.  If the CRL says that 
everything is still fine, great.  Otherwise, the RP only knows that 
something may have gone wrong, but he may not know when.  
This is the retroactive "you should have gotten a timestamp on 
the signature and the next subsequent CRL to protect yourself"
condition.

The NR bit, and by implication the NR "service"  SEEMS to be 
promising that the RP doesn't have to worry, because the CA 
will keep the status of that certificate (not revoked prior to its 
expiration, or revoked as of date T for reason X) around in perpetuity.

My problem, among others having to do with user intent, etc., is that
I don't believe that such a service is credible. Seven years, just maybe,
but not much longer.  In any case, I believe that the Relying Party
is much better off archiving the CRLs along with the data itself,
than depending on the CA to still be around for that long.

My sense is that tempers are fraying, everyone's patience is wearing 
decidedly thin, and that the group is getting quite frustrated by the 
fact that we haven't been able to identify any single, reasonably 
simple definition for what we mean by NR.

If that is the case, I believe we should deprecate the NR bit within 
PKIX, and then charter another WG to explore the interaction between 
the certificate contents, application (as opposed to protocol) behavior,
and the business and legal issues involved with signed documents.

Bob


>>> Elliot Ginsburg <ginsburg@cygnacom.com> 08/26/99 06:32AM >>>
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
ginsburg@cygnacom.com 
703-848-0883
703-848-0960(FAX)

> -----Original Message-----
> From:	Bob Jueneman [SMTP:BJUENEMAN@novell.com] 
> Sent:	Wednesday, August 25, 1999 8:32 PM
> To:	ginsburg@cygnacom.com; ietf-pkix@imc.org 
> Subject:	RE: Options, was Re: To Be, or NR To Be ...
> 
> 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 <ginsburg@cygnacom.com> 08/25/99 02:08PM >>>
> >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
> >ginsburg@cygnacom.com 
> >703-848-0883
> >703-848-0960(FAX)
> >
> >> -----Original Message-----
> >> From:	David P. Kemp [SMTP:dpkemp@missi.ncsc.mil] 
> >> Sent:	Wednesday, August 25, 1999 2:48 PM
> >> To:	ietf-pkix@imc.org 
> >> Subject:	Re: Options, was Re: To Be, or NR To Be ...
> >> 
> >> 
> >> > From: Tony Bartoletti <azb@llnl.gov> 
> >> > 
> >> > 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.
> >
> >
> >
> >