Subject: Re: Deprecate the NR bit?

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

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 Gundin can pull the fat out of the fire (I seem to be on a metaphor roll :-)
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: "Aram Perez" <[email-masked]>
Date: Thu, 02 Sep 1999 10:09:32 -0700

> be allowed to use such a key.

I don't think "Steve is exactly right". When he states "if one provides an
application with access to certs ONLY with NR=0", who is providing the
access? In my experience, it is the application that does the filtering, not
the directory/database service. It is the application asks the directory
service "find all certificates for Jon Doe that have NR=0".

> I despair of ever getting the horses back into the barn.

I agree that there should be an indicators depending on the applications,
but I think using bits is too limiting.

> very carefully crafted semantics.

Agreed except not with bits.

> the existing bit -- if so, he will certainly deserve a medal.

Agreed.

> or the extendedKeyUsage fields, I don't care.

No more bits please ;-)

Regards,
Aram Perez