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

[Ed Gerck <egerck@xxxxxxx>]

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