(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
bjueneman(_at_)novell(_dot_)com
1-801-861-7387