Subject: Nonrepudiation and what to do about it

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 18 Aug 1999 09:30:24 -0600

(Apologies if this shows up twice. It was sent yesterday at 3:01PM, and hadn't
shown up on the list by 9:10 this morning.)

For those who have been asleep or don't subscribe to the PKIX list,
there has been an argument raging about the meaning of the nonrepudiation 
key usage in a certificate.

I have recently posted a fairly lengthy summary of the legal/technical issues
that are involved in issue of whether or not a digital signature is binding,
and in particular whether it could be construed as being binding when
that was not the intent -- particularly from a consumer protection standpoint.

I'll be happy to send any one the entire note who is interested, but since
part of my proposal suggests the creation of a new attribute to be included 
in the CMS signedAttibutes, let me at least summarize the proposal for this group.

------

The message which follows is a rather lengthy attempt to recap of 
the last five years or so of technical/legal discussion regarding 
digital signatures, followed by a proposal for what to do to fix these 
problems.

However, since many may want to skip the justification and cut 
to the bottom line, I'll put the proposal up front, and then justify it:

My proposal is that the text of the nonrepudiation key usage bit I
n the PKIX RFC (and hopefully in X.509) be revised to unambiguously 
state that the defined semantics of this bit is to indicate the willingness 
of the subscriber to be legally bound by a digital signature which can be 
verified by a certificate that can be established to have been valid at the 
time of signature, where "valid" has the normal meaning of not expired, not 
revoked, etc., etc.

In addition, I propose that we create an additional indicator of a 
human being's conscious and willful intent to be legally bound by 
a digital signature that would be applied on a message by message 
basis. This additional indicator would require, as an integral part of 
its semantic definition, that an explicit computer-to-human interaction 
be required to provide some reasonable level of ceremonial and due 
caution warning be provided to the user.  In addition, the semantics 
of this indicator should specify that its use must be ENABLED by the 
NR bit ( as redefined) in the certificate which includes the corresponding 
public key.  If the certificate does not have the bit turned on, the 
application is not obligated to request the ceremonial, due caution 
approval; and relying party software should ignore a per-message 
indicator even if present in that case.

The obvious, but not necessarily the only, place to put such a message 
by message indicator would be in the Cryptographic Message Syntax 
used by S/MIME V3, in particular as a new signedAttribute.  Since 
signedAttributes is a SET of self-describing attributes, adding 
an additional one would be very simple.

[snip]

Comments?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

---

From: Russ Housley <[email-masked]>
Date: Wed, 18 Aug 1999 14:29:24 -0400

Bob:

First, the current charter does not include your suggestion.  But, the 
charter could be updated if there is sufficient interest in your suggestion.

Second, some of the things that you are suggesting are included in RFC 2634 
(Enhanced Security Services for S/MIME).  Take a look at section 5.4 
(Signing Certificate Attribute).

Russ

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Wed, 18 Aug 1999 17:11:13 -0400

I agree in part and disagree in part.

First non repudiation must be an attribute of the signed document.

For this reason I don't see a need to modify the NR semantics of the
certificate - if indeed this is possible. I don't see that the working group
can increase the legal weight applied to this bit at this point.

The second issue is that NR is not a binary attribute. The issue for the
recipient is whether they can trust the degree of certainty in the assurance
provided by the signature. This will inevitably be a complex function of
many factors, not least the CPS governing issue of the certificate in
question.

If anyone thinks they can compress a CP or CPS into one bit...

All the NR bit can do is signal 'the circumstances of issue for this cert
are such that it is not intended to create contracts'.

Since NR is complex attribute the most appropriate format for the document
indicator would be an attribute with a URI as the parameter. The URI could
then identify the governing semantics.

Again, I think folk are overestimating the extent to which complex legal
issues can be eliminated through bits on the wire. I see an issue raised and
a 'solution' advanced which does not solve the problem identified as far as
I am concerned.

Three things are certain: death; taxes and lawyers.

	Phill