Re: Deprecate the NR bit?

["Aram Perez" <aram@xxxxxxxxx>]

Bob Jueneman wrote:

> 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.

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".

>
> 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.

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

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

Agreed except not with bits.

>
> 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.

Agreed.

>
> 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.

No more bits please ;-)

Regards,
Aram Perez

>
> 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
>