Subject: Summary of current nonRepudiation situation

From: "Blake Ramsdell" <[email-masked]>
Date: Thu, 24 Oct 2002 18:06:34 -0700

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

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 25 Oct 2002 08:31:31 -0400

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