Blake:
I think that the language in RFC 3280 is fine for CA certificates.
I do think that additional guidance should be given to the recipient of a
signed message. Here is my proposal.
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 think that this is a reasonable approach because it specifies a clear
behavior for an S/MIME library (such as SFL), but it does not prevent
application that might use such a library from imposing additional
requirements on these bits.
Anyone have other thoughts?
Russ
At 03:30 PM 10/17/2002 -0700, Blake Ramsdell wrote:
The use of the digitalSignature and nonRepudiation bits in the key usage
certificate extension are not explicitly covered in the current -CERT.
Where this would go is the rather brilliant language "interpretation and
syntax for all extensions MUST follow [KEYM], unless otherwise specified
here".
However, there has been some concern that the wording in [KEYM] is not
sufficient, and that this should be addressed specifically in -CERT.
1. Which bits should be set for an end-entity certificate used to sign
an S/MIME message? Is there a difference in this application between
nonRepudiation and digitalSignature, or can the assertion of either be
sufficient to convey the proper signing authority?
2. Which bits should be set in CA certificates?
The current thinking is that if the extension is present, either (or
both) bits MUST be asserted on end-entity certificates when used for a
signature. If the extension is present in a CA certificate, then either
(or both) bits MUST be asserted also.
I'll be hiding under my bed if anyone needs me.
Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com