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

[Ron Ramsay <Ron.Ramsay@xxxxxxxxxxxxxxxxxxxx>]

But the bit doesn't say anything EXCEPT vanilla, it says STRAWBERRY!

I'm going mad!! Stop! Stop! Stop!

> -----Original Message-----
> From:	Ed Gerck [SMTP:egerck@nma.com]
> Sent:	Thursday, August 26, 1999 1:26 PM
> To:	Peter Williams
> Cc:	ietf-pkix@imc.org
> Subject:	Re: Options, was Re: To Be, or NR To Be ...
> 
> 
> 
> Peter Williams wrote:
> 
> >
> > > Thus, the value of bit 0 does not depend on the value of bit 1;
> they are
> > > in fact independent.
> >
> > 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.)
> 
> 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:
> 
>        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)
> 
> 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.
>