[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Deprecate the NR bit?
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 <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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content='"MSHTML 4.72.3110.7"' name=GENERATOR>
</HEAD>
<BODY bgColor=#ffffff
style="FONT: 10pt Arial; MARGIN-LEFT: 2px; MARGIN-TOP: 2px">
<DIV>Steve, is exactly right, there -- this is precisely why I wanted to clearly
define</DIV>
<DIV>what the NR bit meant, so we would know whether or not an application
should</DIV>
<DIV>be allowed to use such a key.</DIV>
<DIV> </DIV>
<DIV>Unfortunately, by not defining the semantics of the bit precisely, we now
have the</DIV>
<DIV>predictable situation where various CAs and institutions like DOD are using
the bit in </DIV>
<DIV>mutually contradictory fashion, making it nearly impossible to say anything
meaningful</DIV>
<DIV>about the purpose of that bit, and thereby degrading its utility to
practically zero.</DIV>
<DIV> </DIV>
<DIV>Although I strongly agree with the concept of requiring either the presence
or </DIV>
<DIV>the absence of the NR bit with respect to certain applications, at this
point the </DIV>
<DIV>meaning, and hence the value of the bit has been so degraded that
personally,</DIV>
<DIV>I despair of ever getting the horses back into the barn.</DIV>
<DIV> </DIV>
<DIV>That's why I suggested deprecating the existing bit, and defining some new
ones with</DIV>
<DIV>very carefully crafted semantics.</DIV>
<DIV> </DIV>
<DIV>Maybe Tom Gundin can pull the fat out of the fire (I seem to be on a
metaphor roll :-)</DIV>
<DIV>and come up with a definition of some useful function that we can all agree
to for </DIV>
<DIV>the existing bit -- if so, he will certainly deserve a medal.</DIV>
<DIV> </DIV>
<DIV>But even if he comes up with a satisfactory, suitably limited definition of
"technical NR"</DIV>
<DIV>or something like that, I think we have clearly identified a need for
additional </DIV>
<DIV>functionality that needs to be endorsed by the CA in order to constitute
adequate</DIV>
<DIV>notice. so I think additional bits will be necessary. Whether we put
them in the keyUsage</DIV>
<DIV>or the extendedKeyUsage fields, I don't care.</DIV>
<DIV> </DIV>
<DIV>Bob</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>>>> Stephen Kent <<A
href="mailto:kent@po1.bbn.com";>kent@po1.bbn.com</A>> 08/31/99 08:20AM
>>><BR>At 8:53 AM -0700 8/30/99, Aram Perez wrote:<BR><BR>>Ron
Ramsay wrote:<BR>><BR>>> Except that the NR bit cannot be added to the
certificate by the<BR>>> application!<BR>><BR>>But the application
can add a much better indicator to the data that needs<BR>>to be part of the
evidence that supports non-repudiation as has been<BR>>proposed on this
mailing list.<BR><BR>Not all applications may be trusted to properly assert
invocation of NR<BR>services. By including the NR bit in a cert, we
have a (potentially)<BR>higher assurance mechanism that can allow or prohibit an
application from<BR>invoking NR services. For example, if one provides an
application with<BR>access to certs ONLY with NR=0, we can ensure that these
apps cannot assert<BR>that they are acting in an NR capacity on behalf of the
user. This is a<BR>very useful security facility and a good reason to keep the
NR bit.<BR><BR>Steve<BR></DIV></BODY></HTML>