Subject: Re: Non-Repudiation

From: "David P. Kemp" <[email-masked]>
Date: Thu, 5 Aug 1999 12:18:51 -0400 (EDT)

> From: Tony Bartoletti <[email-masked]>
>
> The NR-bit was intended (I believe) so that (for instance) the dutiful
> vendor of contract-signing software would code "Sorry, I can't sign this
> contract with this key, its (cert's) NR-bit is 0."  And likewise,
> vendors of (say) routine data-packet authentication software would code
> "Sorry, I can't sign these packets with this key, its NR-bit is 1."

Close.  My interpretation is that each application checks only the bit
corresponding to the function being performed.

If the app is verifying the signature on a cert, it ensures that
keyCertSign is set and ignores all others.

If it is a contract signing application, it checks that nonRepudiation
is set and ignores the others.

If it is doing data authentication with signatures (CMS signedData), it
checks that digitalSignature is set and ignores the others.

If it is doing symmetric key data authentication and/or encryption
(SSL/TLS), it should check that keyAgreement or keyEncipherment is
set, and ignore the others.  I don't believe it should make any
difference to SSL/TLS whether the NR bit is set or not - TLS
applications should look only at the KA or KE bits.

The TLS Security Considerations might point out the implication of
using a single key (with both KA/KE and NR set) in both a web browser
and the contract-signing application, but that is something for the CA
and the user to consider; the TLS app shouldn't care.

(As an aside, the dataEncipherment bit "is asserted when the subject
public key is used for enciphering user data, other than cryptographic
keys".  No general-purpose protocols use public key encryption of
arbitrary-length user data, so the dataEncipherment bit should almost
never be used.)