[Top] [All Lists]

RE: The Great nonRepudiation vs. digitalSignature Debate

2002-10-21 14:48:21

No, the non repudiation bit is in fact the number of the beast.

That is at least the conclusion we came to after the argument in 

I think the problem here is that the only thing we can get agreement on
is what a repudiation bit would be - I make no undertaking to take
care of this key. A non repudiation _bit_ is like a solvency
bit, completely inadequate.


-----Original Message-----
From: Trevor Freeman [mailto:trevorf(_at_)windows(_dot_)microsoft(_dot_)com]
Sent: Monday, October 21, 2002 5:21 PM
To: Housley, Russ; Blake Ramsdell
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: The Great nonRepudiation vs. digitalSignature Debate

It's definitely a matter of local client policy what you accept. Even
with interpersonal messaging - the email may have legal 
significance. I
would have thought that the use of the NR bit would be also 
tied to some
certificate policy. The issuer may think that the policy is 
good for NR,
hence is OK to set the NR bit. I as the relying party I may not agree
and mapped the policy to one which excludes the use of NR in 
which case
I have implicitly mapped NR to plain DS.

-----Original Message-----
From: Housley, Russ [mailto:rhousley(_at_)rsasecurity(_dot_)com] 
Sent: Monday, October 21, 2002 7:02 AM
To: Blake Ramsdell
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: The Great nonRepudiation vs. digitalSignature Debate


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
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
    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?


At 03:30 PM 10/17/2002 -0700, Blake Ramsdell wrote:

The use of the digitalSignature and nonRepudiation bits in the key
certificate extension are not explicitly covered in the 
current -CERT.
Where this would go is the rather brilliant language "interpretation
syntax for all extensions MUST follow [KEYM], unless otherwise

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
(or both) bits MUST be asserted also.

I'll be hiding under my bed if anyone needs me.

Blake Ramsdell | Brute Squad Labs |