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

[Alfred Arsenault <awa1@xxxxxxxx>]

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


Ed Gerck wrote:
> 
> Ron Ramsay wrote:
> 
> > But the bit doesn't say anything EXCEPT vanilla, it says STRAWBERRY!
> >
> > 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