Re: Deprecate the NR bit?

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

(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 <kent@po1.bbn.com> 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