Subject: Deprecate the NR bit?

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 26 Aug 1999 18:43:45 -0600

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 <[email-masked]> 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
[email-masked] 
703-848-0883
703-848-0960(FAX)

> -----Original Message-----
> 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,
> 
> 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 >>>
> >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: 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: William Flanigan <[email-masked]>
Date: Fri, 27 Aug 1999 09:39:57 -0400

Now, this makes sense!  What do others feel?

Bob Jueneman wrote:

[snip]

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 27 Aug 1999 16:05:07 +0200

I must admit that I have not followed everything said regarding the NR-bit
on this list, but I'm not surprised that PKIX can't provide a common
understanding on what NR is in detail.

In fact I don't think PKIX should even try to do that, other than in the
very general context that has already been done in RFC 2459.

This does not mean that the bit is useless and should be deprecated. The NR
bit belongs in a much wider context totally above the PKIX level. The fact
is also that the NR-bit is used in many higher level context with success.
If you would deprecate the bit you would force them to be non-compliant to
PKIX.

It is up to higher level of system design to provide the exact semantics of
this bit, presumably in combination with some defined electronic signature
policy. And then its up to the lawyers and judges to judge the outcome of
this higher level context.

So I would rather deprecate this discussion within PKIX then deprecate the bit.

/Stefan

>> and the business and legal issues involved with signed documents.

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. +46-40 108588              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: "todd Glassey" <[email-masked]>
Date: Fri, 27 Aug 1999 08:47:18 -0700

Bob, I heartily agree! and this is easily a posture that the proposed WG on
e-tokens could take up as Evidentiary Process models and proposed use
models. Part of its applicability statements that are mandated with this
WG's submissions, this could easily fit in well here with a "recommended use
model" for such technologies.

I applaud the sense of unloading the use specific issues from the core
enablement so that the use models, the reason for the protocol's existing in
the first place, can finally be defined.

Seems to me that building the Cart before the Horse and spending all this
time arguing about whether the horse has three or four legs is all that we
have accomplished so far.

Lets pull up to 50,000 and look at what we are trying to accomplish so that
the total bounding of the use of the NR bit and the whole protocol can be
evaluated as to what it actually accomplishes and how it does that.

Todd

---

From: Stephen Kent <[email-masked]>
Date: Fri, 27 Aug 1999 13:52:17 -0400

Bill,

>> and the business and legal issues involved with signed documents.

No.

Steve