NR bit absence, was Re: Deprecate the NR bit?

[Ed Gerck <egerck@xxxxxxx>]

"David P. Kemp" wrote:

> I hope that we all agree that as a general principle, applications
> do not require the absence of any particular key usage bit:
>
>  * Applications that do encryption require that the key
>    transport/agreement bits be set, and ignore the signature and cert
>    signing bits.
>
>  * Applications that verify cert paths require that the
>    cert/CRL signing bits be set, and ignore the signature and
>    encryption bits.
>
>  * Applications that support "non-repudiation" (however that is eventually
>    defined) require that the NR bit be set and ignore the rest.
>
> ....there is no need for certain applications to require the
> absence of the NR bit -- PKIX-conforming applications would simply
> require the *presence* of the key usage bit appropriate to the operation
> being performed, while PKIX-conforming CAs would not issue certain
> combinations of key usage bits.

Dave:

Sorry to disturb the "all agree", but let me continue the list above:

* Applications that do signature require that the key
   signature bit be set, and ignore the rest.

which would imply that such applications would sign a message as
NR ... just because the cert NR bit was set ... and ignored.  So, the
application would do what was NOT requested by defaulting to an
ACK when the NR bit is detected, instead of defaulting to an
NACK  -- a common mistake in protocols.

Note also that this cannot solved by PKIX-conforming CAs not issuing
certain combinations of key usage bits (even if we forget that RFC 2459,
Section 4.2.1.3  says the very opposite) -- because, what is there NOT  to
issue? One must have the signature bit *with* the NR bit in order to
sign *and* assert usage of NR services (whatever NR is decided to be),
which means that this combination of the two bits is compliant and
useful -- and yet, would lead to an application wrongly signing a msg
as NR because *absence* of the NR bit was not checked by the application.
You would need *more* keyUsage bits to do what you propose and you
would need to revoke Section 4.2.1.3, and still not solve the problem as
further analysis would show.

The solution is however simple, though it reverses what you said.
As a general principle, compliant PKIX applications MUST require
the absence of a particular key usage bit in certain situations, for
example, by requiring absence of the NR bit in the key cert when the
message to be signed by the corresponding key does not use NR
services.

> Note: I agree with the current text of RFC 2459 Section 4.2.1.3:
> "This profile does not restrict the combinations of bits that may
> be set in an instantiation of the keyUsage extension."

Me too.  And this is another reason to let applications require
absence of bits in certain cases.  And, absence of the NR bit can have
three meanings, as I commented before, which also need to be
made clear somewhere.

Cheers,

Ed Gerck