Re: Subdividing the NR bit.

[Tony Bartoletti <azb@xxxxxxxx>]

At 10:30 AM 8/24/99 -0400, Stephen Kent wrote:
>Tony,
>
><snip>
>
>>It seems that the NR-bit is a sort of arm-waving approach to covering many
>>unspecified things, such as "took extra care to ascertain real ownership",
>>"used a cleaner-room to generate certificate", "promise to archive for a
>>long, long, time."  But none of this is actually promised or specified.
>>Instead, they abide to sign "NR=1" where its meaning is "some of all of
>>the above, to some degree, (see CA/CPS for details)" which does not
>>automate well.  Beyond this, the only mechanical use of the NR-bit is
>>"not to be set in conjunction with bits x, y, or z" (something they DO
>>have control over, if they actually read what they sign.)
>
>I think part of the problem here is a presumption that one can automate all
>of the decision making process on the part of an RP.  I don't think this is
>realistic.  A more tractable model assumes that the RP makes a value
>judgement, perhaps based on reading the CPS for the CA in question, and
>then decides to accept certs that contain an appropriate policy OID and
>have the NR bit set to 1.  Use of the NR bit supports this use model, with
>no further enchacements.  The NR is useful in this context because it
>allows a user to have multiple certs under the same CA, perhaps under the
>same policy OID, and to segregate these by intended use.

Steve,

Perhaps my emphasis upon automation is misplaced (caveat, I believe the
future hold far more automation than we generally imagine.)

As long as the RP will be expected to review the CPS prior to accepting
a cert with a given subset of key-usage bits, then the NR-bit supports
this use model, as you say.

A burden, perhaps necessary, to place upon the RP.

(Aside - Does this model intentionally impede extended automation?)

And there is no particular gain in adding additional key-usage bits
(e.g., subdividing NR) if the bits do not distinguish an automatably
distinct key-usage catagory.

But does this provide sufficient guidance to the subscriber in wielding
the keys in question?  Does software need know?  Am I promising intent?
Am I declaring future denials apriori null and void?  Am I declaring
only simple cognizance of the signing act?
 
I also suppose that the main motivation behind a revision of the NR
(nomenclature or definition) comes from developers who must take their
cues from the folks that give them requirements, those folks possessing
varied/conflicting notions about the precise intent of the NR-bit setting.

The evidence of this list suggests at least some of these issues
remain a concern.

Regards,

___tony___


Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: azb@llnl.gov                                   LLLLLLLL