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

From: Ron Ramsay <[email-masked]>
Date: Thu, 26 Aug 1999 13:55:40 +1000

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:[email-masked]]
> Sent:	Thursday, August 26, 1999 1:26 PM
> To:	Peter Williams
> Cc:	[email-masked]
> 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.
>

---

From: Ed Gerck <[email-masked]>
Date: Wed, 25 Aug 1999 22:04:56 -0700

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

;-)  the slightly maddening point here is not what the NR bit says when it is "on"
(there are at least 4 different flavors already named -- not just strawberry) nor what it
says when it is "off" (there are at least 3 more flavors named) but what other
bits can co-exist with the NR bit if one takes the spec to task, by what it says (but,
what else would one do -- interpret the spec at will?).

And, this was brought up when I went on with Dave Kemp's suggestion that the
spec was neither necessary nor sufficient to specify any key usage bit, not just
the NR bit -- and pointed out that following Dave's suggestion would imply either
that the spec is defining octet-codes that in most cases would be left open to the
CPS (apparently, what Alfred also said when he interpreted the "bit_0 and bit_1"
case to be provided outside of PKIX) or that the spec can indeed be interpreted
at will.

The simple conclusion is that either the PKIX spec provides necessary and
sufficient conditions in order to define the NR bit (and *all* other bits in the
key usage field) or it will be very difficult to warrant interoperation with any
other security spec or overlayed service that may rely on the semantics of
such bits -- and I don't mean only IETF protocols but other protocols and
also applications.   Interoperation is a basic tenet in the Internet but  we seem
to be reaching a limit where matters need to be made clearer in order to define
borders that, paradoxically, will afford interoperation by providing clear
semantics.  To proceed otherwise is to go back to those "value add" services
of the 80's, where splitting the market in incompatible networks/services was
profitable. However, the Internet is becoming more transparent by the day
and showcases a different paradigm -- that there is more value in
interoperation, even with all the problems.

Cheers,

Ed Gerck

---

From: Alfred Arsenault <[email-masked]>
Date: Thu, 26 Aug 1999 10:09:52 -0400

Sigh!!!

No, Ed, read my words carefully, and please don't twist them.

You asserted that bit_0 and bit_1 were not independent.

I demonstrated that under PKIX 2459, bit_0 and bit_1 meet all of the
definitions of independence.  

I noted that, if the CA agrees that a key in a certificate can be used
to digitally sign something in applications where some service ("FRED"
or non-repudiation, or...) is NOT provided, bit_0 should be set.

I also noted that, if the CA agrees that a key in a certificate can be
used to digitally sign something in applications where that service
("FRED" or non-repudiation or...) IS provided, bit_1 should be set.

If I wasn't clear enough before, I'll try to be clear now:

	RFC 2459 permits (does not prohibit, does not deprecate, pick whatever
words you want) PKIs that allow the same key to be used both in cases
where "FRED" is provided, and in cases where "FRED" is not provided.

Thus, we can have:

	bit_0 = 0 and bit_1 = 1; or
	bit_0 = 1 and bit_1 = 0; or
	bit_0 = 0 and bit_1 = 0; or
	bit_0 = 1 and bit_1 = 1

All combinations are allowed in PKIs compliant with RFC 2459, and thus
bit_0 and bit_1 are independent. (And if you want to get into the
strict  probabilistic definition of variable independence as noted in
either classical probability theory or in Bayesian statistics, we can
play that game, too, but I'd really rather not.)

That was the point I was trying to make.  That's how the spec should be
interpreted.  I haven't found anything in RFC 2459 that contradicts
this.

		Al Arsenault

-- speaking for myself, yada, yada, yada