Subject: Re: Non-Repudiation

From: "Aram Perez" <[email-masked]>
Date: Thu, 05 Aug 1999 10:53:57 -0700

David Kemp wrote:
> 
>> 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.)

Your statements are correct if you assume that your applications are using a
general purpose, but very low level crypto API such as RSA's BSAFE or MS
CAPI. The trouble is that I can write an application that bypasses all the
checks you've just stated. If you use what a call a "good" crypto API, then
you can enforce the three basic key usages: data encipherment, key
agreement/exchange and authentication/signatures. Then I can't write
applications that violate the basic key usages. If you try to limit/control
anything beyond the basic key usages, then you have to start interpreting
the data stream which means you can't have a general purpose crypto API.

Regards,
Aram Perez