Re: Subdividing the NR bit.

[Stephen Kent <kent@xxxxxxx>]

Tony,

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

Note that this is not a burden that has to be endured every time one
accepts signed data in an NR context.  There is a notion of evaluating the
CPS and associated policies once, and then being able to put in place rules
that embody the value judgement made by the individual who read the
material.

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

The model I cite does not support completely automated RP processing, but
it is consistent with the level of due diligence currently exercised on a
bilateral basis in establishing business relationships.  I've spoken to a
number of attorneys working in the PKI arena, and many of them believe that
this is a reasonable goal for PKIs, and it would offer significant
benefits, even though it does not go all the way toward automating RP
processing.

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

Agreed.

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

These distinctions can be declared through policies and specified via OIDs,
at the discretion of the CA.

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

Hopefully we have clarified this in our discussions, and maybe we can add
some text to 2459 to codify that clarification.

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


Steve