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

[Alfred Arsenault <awa1@xxxxxxxx>]

Ed Gerck wrote:
> 

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

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.

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

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