Subject: Re: Deprecate the NR bit?

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 02 Sep 1999 10:54:20 -0600

(I have absolutely no idea why the previous message came up blank -- maybe there is
something wrong with my html editor.  I'll try it again in plain text.)

Bob
---

Steve is exactly right, there -- this is precisely why I wanted to clearly define
what the NR bit meant, so we would know whether or not an application should
be allowed to use such a key.

Unfortunately, by not defining the semantics of the bit precisely, we now have the
predictable situation where various CAs and institutions like DOD are using the bit in 
mutually contradictory fashion, making it nearly impossible to say anything meaningful
about the purpose of that bit, and thereby degrading its utility to practically zero.

Although I strongly agree with the concept of requiring either the presence or 
the absence of the NR bit with respect to certain applications, at this point the 
meaning, and hence the value of the bit has been so degraded that personally,
I despair of ever getting the horses back into the barn.

That's why I suggested deprecating the existing bit, and defining some new ones with
very carefully crafted semantics.

Maybe Tom Gindin can pull the fat out of the fire (I seem to be on a metaphor roll today :-)
and come up with a definition of some useful function that we can all agree to for 
the existing bit -- if so, he will certainly deserve a medal.

But even if he comes up with a satisfactory, suitably limited definition of "technical NR"
or something like that, I think we have clearly identified a need for additional 
functionality that needs to be endorsed by the CA in order to constitute adequate
notice. so I think additional bits will be necessary.  Whether we put them in the keyUsage
or the extendedKeyUsage fields, I don't care.

Bob

>>> Stephen Kent <[email-masked]> 08/31/99 08:20AM >>>
At 8:53 AM -0700 8/30/99, Aram Perez wrote:

>Ron Ramsay wrote:
>
>> Except that the NR bit cannot be added to the certificate by the
>> application!
>
>But the application can add a much better indicator to the data that needs
>to be part of the evidence that supports non-repudiation as has been
>proposed on this mailing list.

Not all applications may be trusted to properly assert invocation  of NR
services.  By including the NR bit in a cert, we have a (potentially)
higher assurance mechanism that can allow or prohibit an application from
invoking NR services.  For example, if one provides an application with
access to certs ONLY with NR=0, we can ensure that these apps cannot assert
that they are acting in an NR capacity on behalf of the user. This is a
very useful security facility and a good reason to keep the NR bit.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Thu, 02 Sep 1999 11:23:04 -0700

Bob Jueneman wrote:

> But even if he [Tom Gindin] comes up with a satisfactory, suitably limited definition of
> "technical NR" or something like that, I think we have clearly identified a need for additional

In my analysis, four cases are needed at least -- and, for heaven's sake, yes, four different
names. Instead of calling all as "NR".  We now have "technical NR", "full NR", and maybe,
following this track we will have "waning NR",  "quasi-empty NR", etc. ;-)

Of course (paraphrasing a very well-known text), no objection can be raised
against the self-definition of NR itself in PKIX, at most one might take exception
to the name "non-repudiation" given to this quantity on the ground that the term is
reserved for another, "known" concept.  But, as far as the exposition of PKIX
clarified by Tom's proposed RFC is concerned, the term was not "known" -- as it has
appeared for the "first time" in PKIX and then was defined in a precise form in Tom's
proposed RFC.

It is true however that human beings, business and law do have a concept of
non-repudiation which differs from PKIX usage, and I think it is unfortunate that
these ends cannot meet when I would think it would be very easy to do so.  But,
it just adds another level of indirection.

However, I feel that today this issue is NOT the most relevant one.  The most
relevant issue today IMO is to massage Tom's RFC to an at least passing grade.

As I see it any full treatment will have to be formally defined, not just protocol
defined -- since protocol is not the only way of implementing it and protocol
cannot do it alone. I already circulated a draft on the formalism to two people in
the WG but it seems that interest is not high enough at this time.  It is like talking
about the need to have air traffic control in 1920, it seems ;-) .. just too soon.  Thus,
I welcomed Tom's initiative and I ask you Bob to take a good hard look at it
and perhaps you will also agree that if this RFC is the most one can have at the
moment ... then let's have it.

Cheers,

Ed Gerck