Options, was Re: To Be, or NR To Be ...

[Ed Gerck <egerck@xxxxxxx>]

Dave Kemp wrote:

> What label should be attached to a key which is known to be relatively
> less suitable for supporting a NR process (perhaps because the binding
> between a single individual and a specific private key is weak or
> nonexistent) - "Key, NR=0", or simply "Key" ?

What do you mean when NR is "on"? What do you mean when NR is "off"?
These are the first two questions that need to be answered before setting
that bit "on" or "off".  And yet, these questions have at least 4 answers for
the first and 3 answers for the second -- as we have seen here.  Then, still,
one needs to specifi "who" sets or clears the NR bit -- the CA, the subscriber,
both, a fourth-party (eg, a validating service), etc.

Actually, in this case and using if I may Tony's analogy with a labeled bottle
of methanol that says "alcohol", we would have the label in one place and
the bottle in another ;-)

> The "necessary and sufficient" line of reasoning is as bogus with
> respect to the NR bit as it is with respect to any other bit.

Holy Aristoteles! I disagree, and let's just move ahead a bit (pun intended) and
see what other bits need to be changed ;-)

First, of course, a necessary and sufficient condition for a certificate to be
verifiable is for it to be digitally signed.  So, I guess this much is OK and
equivalent: "certificate is signed" <--> "certificate is verifiable".  A certificate
is verifiable if and only if it is signed -- the "if" is a sufficient condition and
the "only if" a necessary condition.

Next, we study the eight key usage bits defined in RFC 2459 and which define
the purpose (e.g., encipherment, signature, certificate signing) of the key
contained in the certificate, which may be:

           digitalSignature        (0),
           nonRepudiation          (1),
           keyEncipherment         (2),
           dataEncipherment        (3),
           keyAgreement            (4),
           keyCertSign             (5),
           cRLSign                 (6),
           encipherOnly            (7),
           decipherOnly            (8)


Now, we begin to read:

     The digitalSignature bit is asserted when the subject public key
      is used with a digital signature mechanism to support security
      services other than non-repudiation (bit 1)

which means that the first two bits are not independent. So, you are right,
if the meaning of bit 0 is going to depend on bit 1 and the state where both
are set is undefined, why have them as two independent bits?    Indeed, who
cares what is bitwise necessary and sufficient in the good old laws of logic
representation, if those bits are not representing logical states?

But, after all, if 2459 predicates independent bits  with independent names
then a reader should assume they should be independent and represent
independent states, no?  Or, should one just have octet-codes -- where
many octet-codes  would be "not defined" and thus open to be defined
in the CPS?

It seems thus that there are more faults in this bit logic than the NR bit fuzzy
definition and non-descriptive name.  So, if your call is to use octet logic instead
of bit logic, then I think that 2459 should say so and clearly spell out the octet-codes
that are valid and for what purpose.  Then, those octect-codes should be necessary
and sufficient conditions for each purpose -- to say otherwise is to deny logical
equivalence to the purpose.

As another option, bit logic should be followed as implied in 2459 and the
bit-values should likewise be necessary and sufficient conditions for each purpose.

Cheers,

Ed Gerck