Subject: Re: Nonrepudiation and what to do about it

From: Vin McLellan <[email-masked]>
Date: Wed, 18 Aug 1999 16:32:47 -0400

Hi Bob,

        I'd appreciate a copy of the post you mention below.  If you have a
URL at Novell  (or a URL for the PKIX archive where I could find it) I could
spread it around and limit the number of folks asking you for a copy.  On
Cyberia-L, a legal forum, and elsewhere, this is a topic of current interest
too.

        Regards,

                        _Vin

At 09:30 AM 8/18/99 -0600, Bob Jueneman wrote:

>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

---

From: [email-masked]
Date: Thu, 19 Aug 1999 10:40:00 -0600

The number of people who have asked me privately for 
the entire summary is such that I think that sending the original note
to the entire list may not be too great a waste of bandwidth.

Just be advised that the topic is being debated extensively 
on the PKIX list, and that some points are being made that are 
prompting me to think about some minor adjustments to my 
proposal.  Before we get to that point, however, I think it 
would be useful to hear from other people.

Vin McLellan asked for a URL, but unfortunely, our firewall policy 
makes it a little too awkward for me to post something.  Feel free to 
circulate it as desired, however.

Bob

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 t
o 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.

Now for the history lesson.

When the ABA Digital Signature Guidelines were being formulated within the 
Information Security Committee, with lots of very bright, well-informed 
attorneys and technologists contributing, there was a fundamental, underlying 
assumption that PKI technology could be used to reduce some of the uncertainty that 
was perceived to be a barrier to the efficient use of electronic commerce.

Instead of having to use proprietary, value added networks and negotiate 
N*(N-1) contracts between all of the trading partners, it was expected that 
the use of a common PKI technology and appropriate legal frameworks 
would eliminate most of that overhead.

It was recognized that a accretion of case law had resulted in a situation 
where printed forms, letterhead, FAXs, telegrams and later Telexes, 
ordinary e-mail, and who knows what else forms of communications could, 
under the proper circumstances, be interpreted as being a legally binding 
signature.  The trouble was that the technology had moved much faster t
han the case law, and the uncertainty was increasing at a compounded rate.

For example, back when printed forms were created on letterhead presses, 
and were filled in using either handwriting or a typewriter, it was pretty obvious 
what the difference was. And because going to a printer and having a lot of 
standard forms printed involved some expense, time and effort, the 
conventional use of such a form for purposes of trade might reasonably 
be considered tantamount to a signature of the company. Unfortunately, 
a technological decision that was rational at the time is no longer rational 
in the age of laser printers, when preprinted forms have almost disappeared.  
But the case law hasn't changed, so the question of what constitutes 
signature becomes more of a risk, both for the relying party who thought 
it was valid, and for the originator, who really didn't intend for it to be anything 
more than a draft proposal.

In addition to these technical/legal issues, there was also the issue of 
liability in the event of something going wrong, such as a key being compromised.

One approach would be the very loose standard of care embodied in 
the US credit card law (Regulation E), where even the most egregious 
carelessness on the part of the subscriber could only result in a $50 loss.  
The problem with that approach is that it effectively required the 
establishment of a mechanism that would be very similar to the 
credit card industry to centralize the reporting of every time 
a certificate was used to verify a transaction, so that loss 
limits could be enforced.

At the other end of the spectrum was "strict liability,' which is 
the standard used between major financial institutions.  Because 
of the volume of the business, and the difficulty of backing out 
transactions in error that might otherwise leave an innocent third 
party holding the bag for a transaction gone wrong, inter-bank 
transactions are generally governed by strict liability -- no matter 
what the extenuating circumstances might be the bank was 
still liable for a transaction that went out in its name.

In between these two poles were standards of simple negligence 
or gross negligence as a possible defense.

The final decision that was incorporated in the Guidelines, 
Section 5.6 Presumption in dispute resolution, was to create 
a "rebuttable presumption" that a digital signature verified by 
reference to the public key listed in a valid certificate is the 
digital signature of the subscriber listed in that certificate.

The effect of this presumption was to allocate the burden of 
proof to the person who is challenge the validity of the 
signature.  In the case of a claimed forgery, for example, 
the burden of proof (independent of the risk of loss) falls on 
the subscriber, who would generally be in a much better 
position to know how the keys were protected, etc., than 
the relying party.

The State of Utah, in their pioneering Digital Signature Act, 
didn't go quite so far as that. Instead, they applied the rebuttable 
presumption argument only to a special class of certificates created 
by so-called "Licensed Certification Authorities" that were subject 
to a higher level of assurance, involving inspection and audit and 
financial viability controls that were intended to make the imposition 
of a rebuttable presumption a more reasonable proposition.  And 
these Licensed CA certificates were strictly a voluntary opt-in provision.  
No one had to use them, and if they didn't, the traditional common-law 
provisions regarding signatures was explicitly stated to be unaffected.  
Some other states, including Washington and Minnesota, and a large 
number of foreign countries, also adopted this model.

Nonetheless, some elements of the legal profession were strongly opposed.  
A law student by the name of Bradford Biddle published a law review article 
or polemic bitterly attacking the Utah statute as an unholy interference in the 
market by creating financial subsidies for a particular class of technology 
while disadvantaging others (which others were being disadvantaged was 
never explained.) A noted lobbyist for a company who was marketing a 
biometric-based, digitized signature device managed to get the Secretary of 
State of California to effectively gut their digital signature law by completely 
redefining a "digital signature" to be something else entirely.  (At the same
time he has made a rather convincing case for a certain element of 
"ceremonial" and "due caution" protection in any device or 
program that applies a legally binding signature to a document, whether a 
digital signature or not. In particular, he has effectively raised the issue of 
an automaton or daemon applying a digital signature automatically, without 
any human input at all. And of course that is precisely what S/MIME v3 "
Enhanced" Security Services with automatically signed receipts is intended to do!)

Meanwhile, a young but influential attorney in the Massachusetts state 
government, responding the electoral "mandate" of their Libertarian governor, 
Gov. Weld, strongly opposed the "regulatory burden" that might be imposed by 
State licensing of CAs, leading to the rather ironic situation of arch-conservative 
Utah sponsoring a regulatory regime, while ultra-liberal Massachusetts was trying 
to privatize CAs  and let the lawyers fight it out in court. In addition, some of the 
computer industry was also opposed to any kind of regulatory regime -- they didn't 
want the government, any government, telling them what they could do, ever. 
So the establishment of some kind of a rebuttable presumption faced serious 
political difficulties. 

And then another segment of the academic legal community raised a consumer 
protection issue that quickly became even more of an political hot potato.  If a 
digital signature was presumed to be valid, then, since "everybody knows" that 
operating systems are not secure and that the Internet is a cesspool of viruses, 
etc., poor Grandma is going to lose her house someday because her keys were 
compromised.  (This is q variation on the "death-penalty" certificate theme.)

From this perspective, what was desired was not more nonrepudiation, but 
LESS!  Or to be more precise, a better way to control exactly when and 
how a signature might reasonably be viewed as being intended to be legally 
binding, and when it might be restricted to being used for more benign applications.

Restricting such usages to a certificate issued by a Licensed CA might have 
been a reasonable option – Grandma should never apply for or accept such a 
certificate if she never wanted to be legally bound, especially for a high-value 
transaction such as selling her house, and the CA would presumably be 
obligated to make sure that she understood the possible risks and need to 
adequately protect her keys before accepting such a certificate.  Unfortunately, 
since statutes enabling the use of a Licensed CA are not yet common and are 
being opposed by some, this may not be a viable approach.

Another approach MIGHT be to very carefully spell out the terms and 
conditions of use for a certificate in the CAs Certification Practice Statement.  
But despite the general belief in the PKIX community of the efficacy of a CPS 
to cure all ills, there are very grave doubts about whether a CPS is really all t
hat helpful in this case.

First of all, there is not necessarily any requirement for a relying party to even 
read the CPS.  Granted, if the relying party does not conform to the terms of 
the CPS, it may have a more difficult time suing the CA for damages, but even 
this is arguable.

Second, no matter what the CPS states with respect to what the subscriber 
is obligated to do with respect to the CA, and no matter what the CPS might 
imply with regard to the relying party, (assuming it can be demonstrated that 
an enforceable contract even exists between the CA and the RP), there is 
absolutely no privity of contract between the subscriber and the relying party 
that is caused by the CA and the CPS.  The RP can't sue the CA because of 
something the subscriber did or didn't do, and likewise the subscriber can't sue 
the CA for something the RP did or didn't do. The RP can sue the CA if it 
misrepresented the subscriber to the RP, and the subscriber can likewise 
sue the CA if it misrepresented the subscriber to the RP, but that is about it.

So relying on the CPS to protect the subscriber against a claim that she 
signed a legally binding document when she never intended to do so is a 
rather shaky legal premise.  Of course, like the fabled chicken soup remedy 
for a cold, it probably won't hurt, either, and so CPS's tend to include all sorts
of things just in case they might help.

What is really needed, given the lack of legal consensus as to how to 
approach these issues, is an unambiguous, standards-based way of indicating 
whether even a relatively naive consumer did or did not intend to be legally 
bound, ever, by a particular public key and certificate, and in particular by 
any kind of a high-value transaction that might allegedly be signed by t
hat person.  (In a certain ironic sense, we really need a positive, 
"repudiation" bit in a certificate, rather than the absence of a nonrepudiation 
bit.)  Insofar as possible, this indication must not depend on the existence or
nonexistence of digital signature laws, especially laws providing a rebuttable 
presumption to certain classes of certificates, because of the uncertainty of 
passage of such laws and the possibility that they might be preempted by 
federal legislation.. The desired effect therefore must be clearly stated in 
the semantics of the indicator itself, and interpreted as such by application 
programs, so that there can be very little doubt.

Secondly, in the case where a knowledgeable subscriber is in fact willing to 
be legally bound by a digital signature, it seems highly advisable to define a 
means of explicitly indicating, on a case by case, document by document 
basis, the subscriber's human consent and intent to be so bound, and to 
ensure that such an indication could not reasonably be interpreted as 
applying to any kind of an automatic or programmed generation of a 
digital signature by a human user.  (A server or automated process may 
automatically generate a digital signature on behalf a subscriber such as 
an organization, but it must NOT be applied in such as way as to indicate 
human consent on a case by case basis.)

My proposal, therefore, is that the text of the nonrepudiation key usage bit in 
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.

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 .  Since signedAttributes 
is a SET of self-describing attributes, adding an additional one would 
be very simple.

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