Subject: Re: Deprecate the NR bit?

From: "David P. Kemp" <[email-masked]>
Date: Fri, 3 Sep 1999 10:17:56 -0400 (EDT)

> From: "Bob Jueneman" <[email-masked]>
> 
> Although I strongly agree with the concept of requiring either the presence or 
> the absence of the NR bit with respect to certain applications, at this point 
the 
> meaning, and hence the value of the bit has been so degraded that personally,
> I despair of ever getting the horses back into the barn.

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.
   
A community expresses its intent to prohibit the use of a particular
keypair for a particular combination of purposes by writing a
certificate profile that prohibits the corresponding bits from being
set simultaneously by a CA, and by requiring conformance to the
community certificate profile as a condition of extending trust to
that CA.

If, by some stretch of the imagination, the entire Internet Community
reached agreement that certain other key usages are incompatible with
"supporting non-repudiation", then that consensus could be elevated to
the PKIX CA conformance profile.  But even if such an agreement were
reached, 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.

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."

---

From: Ed Gerck <[email-masked]>
Date: Fri, 03 Sep 1999 11:17:36 -0700

"David P. Kemp" wrote:

> ....there is no need for certain applications to require the

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.

> 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