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

From: Ed Gerck <[email-masked]>
Date: Wed, 25 Aug 1999 13:09:37 -0700

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

---

From: Alfred Arsenault <[email-masked]>
Date: Wed, 25 Aug 1999 18:33:34 -0400

Ed Gerck wrote:

> the "only if" a necessary condition.

AWA:  Bzzt!  Sorry, that is not correct, but thank you for playing
anyway.

The fact that is certificate is signed does NOT make it verifiable.  A
certificate is verifiable only if it is signed - that much is true
within the context of PKIX.  However, a signed certificate is not
necessarily verifiable - it might not be possible to construct a cert
path from the cert back to a trust point; revocation information may not
be available, etc.

> representation, if those bits are not representing logical states?

AWA: Once again, incorrect.  We've had this discussion numerous times
before.  Let's define some service, call it "FRED".  (I prefer to call
it "non-repudiation", but I'm trying to avoid getting wrapped up in that
mindgame for now.)

Bit 0 is to be set if the certificate is to be used for signing in cases
where "FRED" is not provided.

Bit 1 is to be set if the certificate is to be used for signing is cases
where "FRED" is provided.

If the certificate is to be used for signing in both cases (i.e., it's
okay to use this cert for signing when "FRED" is to be provided by
system elements outside of those specified in PKIX; and when "FRED" is
not provided in the system), then both bit 0 AND bit 1 can be set. 
Thus, the value of bit 0 does not depend on the value of bit 1; they are
in fact independent.

To quote from RFC 2459:

>    This profile does not restrict the combinations of bits that may be
>    set in an instantiation of the keyUsage extension.  However,
>    appropriate values for keyUsage extensions for particular algorithms
>    are specified in section 7.3.

			Al Arsenault

--- speaking only for myself; yada, yada, yada

---

From: "Peter Williams" <[email-masked]>
Date: Wed, 25 Aug 1999 16:43:39 -0700

> Thus, the value of bit 0 does not depend on the value of bit 1; they are

That is quite correct. In PKIX, ISO NR and use of the NR bit
does not depend on use of a digital signature
mechanism (except as it is is to issue certs and CRLs.)

---

From: Ed Gerck <[email-masked]>
Date: Wed, 25 Aug 1999 20:26:16 -0700

> mechanism (except as it is is to issue certs and CRLs.)

Peter:

If I say that  "I want an ice-cream other than vanilla", this means that I want ANY
ice-cream EXCEPT vanilla.  Thus, when the spec says that bit_0 is TRUE when
the subject public key is used with a digital signature mechanism to support
security services OTHER THAN non-repudiation (bit 1), then the spec is saying
that any service can be used with bit_0 EXCEPT non-repudiation.    For a logical
derivation and further comments, please see [1].

Is the spec wrongly written in this regard?  Well, this much is certain because
2459 also says that it does not restrict the combinations of bits that may be
set in an instantiation of the keyUsage extension -- which is in contradiction with
the above.  Thus, either passage must be corrected; and this is NOT the only
example (check the cRLSign bit for instance).

The assumption that the certificate can be used for signing (bit_0 = TRUE) also
when "bit_1 = TRUE" due to system elements outside of those specified in PKIX
is a simple fallacy because bit_1 is defined as a signed bit by the PKIX
specification and cannot be asserted *after* bit_0 is signed.  The entire certificate is
signed and "frozen" at the time of issuance and must thus conform to the spec at that
time, which affirms that bit_0 is TRUE when the subject public key is used with a digital
signature mechanism to support security services EXCEPT non-repudiation (bit_1).

Cheers,

Ed Gerck

[1]   As I quoted, the sentence in 2459 specifies:

Now, suppose I define two boolean variables A and B (where "bit_1" means both
the service of "non-repudiation" and the bit that indicates the service):

A = (the subject public key is used with a digital signature mechanism to support ANY security services)
B = (the subject public key is used with a digital signature mechanism to support security services other than bit_1)

which variables I define  to be TRUE if the subject public-key "IS" used in the context
specified or FALSE if it is NOT used in that context.

The logical expression that is equivalent to the quoted phrase in 2459 would read:

bit_0 =  A and not  (bit_1)

because, in logic notation,  B = A and not (bit_1).  The set of security services in A
is larger than the set of security services in B -- because B excludes ("other than")
the non-repudiation service.

In other words, 2459 says that bit_0 is asserted when a subject's public-key is used
with a digital signature mechanism to support services which are in mathematical
complement to non-repudiation.  Hence, bit_0 and bit_1 can't be TRUE at the same
time if the spec text is correct.