Blake,
I agree with the general principle outlined by Russ and Trevor, that
treatment of the digitalSignature and nonRepudiation bits for purposes
beyond mechanical use of the digital signature algorithm may depend
on application-specific policy.
However, I am concerned that the proposed language does not give
developers any guidance on what code to write to handle these bits,
and does not give purchasers of applications any knowledge of what
they are buying. The S/MIME standard should allow the existence
of additional requirements, but should state that an S/MIME
application MUST either:
1) explicitly cite a policy/specification/document/profile
describing the additional treatement of these bits, or
2) treat the digitalSignature and nonRepudiation bits identically
Dave
Blake Ramsdell wrote:
As it stands right now, I am putting the language in -CERT as Russ has
presented it:
S/MIME receiving agents MUST NOT accept the signature of a message
if it was verified using a certificate which contains the keyUsage
extension without either the digitalSignature or nonRepudiation bit
set.
Sometimes S/MIME is used as a secure message transport for
applications beyond interpersonal messaging. In such cases, the
S/MIME-enabled application can specify additional requirements
concerning the digitalSignature or nonRepudiation bits within the
keyUsage certificate extension.
I believe that this is not contrary to any of the opinions voiced so far
about nonRepudiation semantics, and it does a fine job of offloading the
actual meaning and interpretation of this bit to good ol' "application
defined behavior".
Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com
smime.p7s
Description: S/MIME Cryptographic Signature