Subject: Re: Non-Repudiation

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 12 Aug 1999 18:01:41 -0600

(Warning -- longer than even Ed Gerck's missives, but worth every megabyte.)

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

>>> Stephen Kent <[email-masked]> 08/03/99 03:01PM >>>

>Aside: Could you be related to Bob Jueneman?  In the anals of IETF WG
mailing lists, only he has tended to send such long, detailed messages, as
well as being so involved in the legal aspects of PKI :-}.

In the annals of the IETF WG, I've never seen anyone form a plural
of the word 'anal'.  The mind boggles at the thought, but perhaps it's 
appropriate for this thread. :-)

The reason why I have been so interested in the legal issues of PKI is that the 
four companies I have worked for in the 15 or so years I've been involved in 
this space have all had a reasonable expectation that eventually a product 
(or service) would emerge from this that they could make some money on.
If we were only interested in protecting casual e-mail, certainly PGP would 
have been a lot easier to develop and use.  But for business uses, 
it is simply not possible to ignore the potential legal issues, and I have 
been working to try to draw the technologists and the legal community
toward a common understanding of these issues.

>This is an IETF (technica)l WG, not the ABA Technical Committee on Digital
Signatures. The technical definition of NR that we use comes from ISO
7498-2.  

Definitions are of course neither right nor wrong in and of themselves, 
since they are definitions.

Instead, they are either helpful, because they are consistent with the 
general  and accepted usage of a particular term, or they are not helpful.  
Just because one person or group puts together a set of definitions, that 
does not automatically ensure that they will be particularly helpful, or 
well accepted. (The oxymoronic X.521 "useful attributes" with their 
specificity of syntax and paucity of semantics, would be a good case 
in point.)

The technical definition of NR in ISO 7498-2 may or may not have been
helpful in the context of an X.400 message delivery service, but the lack of 
consensus or even understanding of that definition, as has been 
repeatedly demonstrated in this WG for at least the last half-dozen years, is
convincing evidence that the definition is distinctly NOT helpful, useful, or
in agreement with the common usage, and it therefore deserves to be 
deprecated, and either fixed or ignored, regardless of the position taken by
ISO or one of the cochairs. (That does NOT mean, however, that
the bit itself should be removed from the spec, or necessarily even renamed.
We just need to clarify the semantics.)

Attorneys, especially attorneys who are relatively new to the field of PKI and
therefore haven't absorbed all of the technical jargon, would tell you that in 
the law, there is no such thing as nonrepudiation. A given statement can be 
repudiated for any of a whole host of reasons, ranging from denial of the facts of 
the case, to duress or compulsion, to lack of knowing intent, to legal or 
mental incapacity or lack of agency * the infamous "infants, idiots, and married 
women" clause.

On the other hand, as Tony Bartoletti pointed out, neither the presence nor 
the absence of the NR bit is necessarily definitive as to whether a court of law 
determines that you signed (or didn't sign) something.

There are so many different digital signature laws and regulations in various
jurisdictions, and no case law as yet, that it is very difficult to say anything 
with absolute certainty, but it is pretty clear that even if your certificate 
was expired or even explicitly revoked at the time a document was signed, 
that does NOT automatically mean that a given digital signature was 
invalid, if a preponderance of the evidence to the contrary can be presented.

Strange as it may seem, a digital signature may be valid, and the contract binding,
even though it can be absolutely established that the subscriber was not and 
could not possibly be the person who caused the digital signature to be associated 
with a document. In that case, it is quite possible that the forger of a digital 
signature (perhaps someone who stole someone else's private key) ends up being
contractually bound by the terms of the contract he signed, even though 
he used a key and certificate issued to another person. Caveat hacker!

Obviously, however, it is more difficult to convince a jury that the subscriber 
did in fact sign a document if the certificate had been revoked. And even 
more importantly, it is much more difficult for the relying party to prove 
that his reliance on such a digital signature was "commercially reasonable," 
and that he should not bear the loss in that case.

In this regard I agree with Peter, when he said "An electronic signature 
created using a digital signature security procedure satisfies writing and 
signature requirements, with or without non-repudiation properties, whether 
it is created by, or on behalf of, a user." That is generally true with respect to
the statute of frauds requirements that contracts be in writing.  But this may 
not go as far as a higher level of presumptive validity that may attach to a
"secure electronic signature", AKA "digital signature" (to refer to the Illinois act)

There are two fundamental issues in contract law -- who has the burden of proof,
and who bears the risk of loss.  These two issues are NOT automatically linked --
it is perfectly possible that the subscriber (the putative signer) has the burden of 
(dis)proof, yet the relying party bears the risk of loss.  In fact, that is precisely
the case under the rebuttable presumption, burden-shifting statutes such as the
Utah, Washington, etc. acts pertaining to the voluntary use of a certificate issued by
a Licensed CA.

So all that even the best PKI can do is to provide the technical basis for such a 
rebuttable presumption, and to make it substantially easier to prove one thing, and 
substantially more difficult to disprove it. But God-like infallibility isn't going to happen,
and fortunately isn't required..

This WG cannot DEFINE what the legal consequences of some "nonrepudiation" 
bit is or should be.  That is completely beyond our power (and expertise), and 
can only be done by contract, or by statutes such as the Uniform Electronic
Transactions Act being considered by the state commissioners responsible 
for drafting the Uniform Commercial Code in the U.S.

However, this WG can and does have enormous influence in this area, because in 
the absence of either an explicit contract or a statutory requirement or permission, 
the common trade practices within an industry, e.g. as may be established by 
technical standards; or by the course of trade between two parties, are typically 
given great weight by the court in determining whether a given mark or 
signature should be considered legally binding.  Chinese chops may be binding in 
San Francisco's Chinatown, but not in the New York diamond district, where a 
handshake is traditionally considered binding.  In addition, as lawmakers rush 
to pass feel-good legislation in favor of electronic commerce, motherhood, 
and apple pie, their staffs tend to point to the quote the technical definitions 
(whether they understand either the law or the technology).  So it is very important
that we be as deliberative as possible in this issue.

The real problem in all of this is that PKIX is quite CA-centric, and fixated on 
the issue of certificates and protocols, with the tendency to believe that if we can
just solve those problems, everything else is trivial. The other parts of the 
problem (unfortunately) tend to lie outside of our charter, yet nonetheless 
the other groups listen. 

So Peter was correct when he went on to say "On the NR issue, nothing in 
the NR definition requires there to be evidence of user intent. USER INTENT 
IS REQUIRED IN THE UNDERLYING ELECTRONIC SIGNATURE 
AGREEMENT, however." (My emphasis.)  

The question, then is whether it is legitimate to INFER user intent from a particular 
key usage type, and to what extent, if any, the subscriber can be bound to such a 
an alleged "death penalty" type of certificate on the basis of some shrink-wrapped or 
"click-wrapped" contract of adhesion, based on the user's cursory acceptance of
a CA's CPS or subscriber agreement.

We could argue that the user should be so bound, and in fact I have so 
argued with some of my attorney friends. But invariably, I lost. Emotional 
consumer protection issues generally ended up triumphing over logic.

I am therefore inclined to take a more moderate position.  The NR bit 
in the certificate should be interpreted as ENABLING the use of digital 
signatures that are intended to be legally binding, but I now believe that it would 
be prudent to provide an additional indicator to serve as a more explicit 
indication that the user did in fact consciously intend to be legally bound
by her signature.

The ideal place to provide this indication would be in the CMS used by S/MIME.
However, although I am not as certain as I'd like to be, I don't believe that the 
existing "digital signature" signedData bit in CMS provides this indication.  
That bit, as I understand it, says what the purpose of the particular CMS
 wrapper is, i.e., encryption vs. signature, but that DOESN'T even address
the issue of intent.  It might be, for example, that a message was
digitally signed to prevent its undetected corruption in transit or storage, 
but that the intent of the message was approximately "look at what these 
idiots have done now."

Granted, in a traditional mail message that intent can and should be indicated 
by the text of the message itself, but in a transaction processing system we 
want the "message" to be completely machine process able and unambiguous.

I am therefore in complete agreement with Larry Layton (who may have been 
repeating an earlier argument of mine): "If the certificate indicated non-repudiation, 
then an [standards-compliant -- RRJ] application would have to specifically ask for a user's 
authorization to use the certificate to create a [NR type of legally binding] signature." 
[And it probably ought to provide an additional explicit indicator of that fact 
in the message itself, and not rely solely on the certificate - RRJ]"

"I realize that this gets into the policy area rather than the
technical area, but in my mind, the NR indicator provides
a technical means to support a policy whereby specific user
action is required (versus a digital signature used for authentication)."  

Exactly right.

In other words, I disagree with David Kemp when he says: 

> "CMS signedData provides technical nonrepudiation and requires certs
  with the NR bit set", and

> "TLS does not provide technical nonrepudiation of user-level data,
   and when it uses digital signature certs those certs must have the
   DS bit set"

I agree with respect to SSL/TLS -- it does not provide "technical nonrepudiation"
or any kind of nonrepudiation, except arguably nonrepudiation of origin of 
the entire message stream.

But I disagree that CMS signedData provides nonrepudiation, except in the sense that 
Tony Bartoletti argued, i.e., authentication, UNLESS signedData REQUIRES AN 
EXPLICIT CONFIRMATION OF USER INTENT TO BE BOUND.  signedData therefore
should NOT require a certificate with the NR bit set, since there are lots of times when
it may be useful to provide authentication (integrity with origin) when there is absolutely 
no intent to be legally bound.  Instead, I would like to see an additional bit defined
in CMS, perhaps called "bindingIntent."

To be crystal clear, and to bring this diatribe to a close, I divide the end-user uses of 
public key cryptography into three relatively disjoint sets:

1.  Encryption.  Encryption (key agreement or key exchange, really) keys are generally 
subject to key recovery, either on behalf of the user, so he can recover stored 
encrypted data some number of years later, or on behalf of his organization, for 
reasons ranging from business continuity to investigating fraud.

2.  Authentication, using what is conventionally called a digital signature, and in 
particular using the DS key usage.  Since authentication is typically (but not always) 
used to access organizational resources and is not legally binding, authentication keys 
are typically not very sensitive to whether key recovery is permitted or not. But
authentication may apply to a logon for a stream type of session, such as TLS, or it 
may apply to a signed message that is not intended to be legally binding. (The fact t
hat it wasn't so intended doesn't necessarily mean that it couldn't be construed to be 
binding, however, just as an unsigned e-mail message might also be legally binding 
under the rather relaxed rules for what constitutes a signature.)

3.  Legally binding, "nonrepudiation" type of signatures reflecting the user's intent to be 
legally bound, whether or not someone (such as the RP) bothers to go to the trouble of 
actually collecting all of the timestamps, CRLs, etc., that might making proving the validity
of the signature considerably easier.  Since in this case it is vitally important to both the 
user and the RP that only the bona fide subscriber be able to sign such a document, business
key recovery (and/or centralized key generation) is absolutely unacceptable, and even the 
ability to do personal key recovery may be unwise, because of the presumably greater risk 
of compromise.

The reason why a mixed or unspecified use of encryption plus digital signature (much less NR) 
is such a bad idea is due to the business key recovery requirements, and in addition to the (US) 
export laws that tend to constrain the key length for encryption, but do not constrain digital 
signature key lengths, for those system that enforce such distinctions.

Hope this helps to clarify some of these issues.

Regards,

Bob

---

From: Ed Gerck <[email-masked]>
Date: Thu, 12 Aug 1999 18:57:36 -0700

Bob Jueneman wrote:

> [snip]
> ....
> ....
> legally bound, ....

Note that a digital signature can be legally binding even though repudiable.  In other
words, one must be carefull not to equate "legally binding" with "nonrepudiation" --
the difference is that rights equate to duties while power equates to liability  So that
absence of nonrepudiation liability does not mean absence of contract duties -- for
example, the duty to return the merchandise.

In fact, if the nonRepudiation bit would be fully erased from the PKIX specs then
there would IMO be no significant decrease in the value of the specs in order to
support legally binding contracts.  The value of keeping that pesky bit IMO can
thus only be justified if its meaning is clear -- it has no meaning but that which
is defined in a particular CPS.  Otherwise, it will muddy the waters and backfire,
since the UCC does make CAs liable for using incorrect methods.

Cheers,

Ed Gerck

---

From: "Dale Gustafson" <[email-masked]>
Date: Fri, 13 Aug 1999 11:57:56 -0500

Hi Bob,

A comment or two, inline.

Best Regards,

Dale Gustafson
Datakey, Inc.
407 West Travelers Trail
Burnsville, MN 55337 USA
612.808.2360 voice
612.890.2726 fax

[snip]

[snip]

> actually collecting all of the timestamps, CRLs, etc., that might make proving the validity

Smart card vendors will provide software libraries and card operating systems that include support
for a "signing only" key pair.  The distinguishing characteristic of this special type of
public/private key pair is that access to the private key component is protected by a special
"Signing Key PIN" (distinct from the User PIN that controls general user access to the card).  The
Signing Key PIN must be entered each and every time that private key is used to create a digital
signature (preferably through a protected authentication path reader device -- the PIN characters go
directly from the keyboard or PINpad to the card and do not traverse the user's desktop or laptop
machine.)

I believe card vendor initial requirements were defined and driven by the new German Digital
Signature laws.  Perhaps their concept of requiring the user to enter this signing key PIN (or
perform some other concious action) for each and every digital signature, which appears to be
motivated by a very similar set of issues, may be useful to this discussion as well.

---

From: "Peter Williams" <[email-masked]>
Date: Fri, 13 Aug 1999 10:45:13 -0700

The NR diatribe, and comments on diatribe, show
that PKIX-QC must first address these issues, before it
can proceed. It cannot proceed 
until, in its definitions and other implied
semantic assumptions, it clears up this NR 
issue set to the satisfaction of the consensus.
(The chairs may bully this process a little.)

So, in summary, for PKIX-QC to proceed,
it should surely define the IETF semantics of the NR
bit it mandates.  The authors should make
a best attempt to represent what the community
has stated the various technical issue set to 
be, here; and not merely quote some evidently 
quite useless, abstract ISO definition(s). Once 
the dust settles, the issues will be settled for 
the moment, and the first generation CEC qualified
certificate will at least have a firm, if
disputable, semantic basis.

To proceed as is will be like deploying the Maginot
Line on quicksand.

> -----Original Message-----
> From: Ed Gerck [mailto:[email-masked]]
> Sent: Thursday, August 12, 1999 6:58 PM
> To: Bob Jueneman
> Cc: [email-masked]; [email-masked]
> Subject: Re: Non-Repudiation
> 
> 
> 
> 
> Bob Jueneman wrote:
> 
> > [snip]

---

From: Marc Branchaud <[email-masked]>
Date: Fri, 13 Aug 1999 11:37:28 -0700

WRT the issues that Bob raises below (the need for intent and such), I
have been inclined to consider current practices with "wet" signatures.

Wet signature mechanisms -- applying ink to paper and hand to pen --
have nothing to do with the intent of the signatory.  Instead, the
document being signed usually states that the intent of the signature
is.  There's usually a line somewhere like "I represent that the above
information is true." or "I hereby agree to the above conditions."

So I think that adding an extra bit here and there inside certificates
or CMS is completely inadequate.  To capture current practice it is
necessary to extend the way documents are signed.  Instead of adding a
bit to CMS, an authenticated attribute should be defined that is
basically a statement of intent for the signature.  Statements such as
"I am Party A as identified in this contract" or "I am witnessing the
following 3 signatures on this will." would go a long way towards
clarifying intent.

Bitwise NR is still important, if only to add a layer assurance that a
person will use the certified key pair for NR.  But bitwise NR can never
capture intent, so we shouldn't even try to make it do so.

IANAL, but I think that some technical & legal types could get together
to define a few intent-statement authenticated attributes along with the
cryptographic semantics that machines can enforce to make the intentions
sensible.  (For example, two parties signing a contract would probably
be implemented as parallel signatures, whereas a witness signature would
include existing signatures on the document).

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL
INC.
 [email-masked]        PKI References page:             
www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1

Bob Jueneman wrote:

[ snip ]

> The question, then is whether it is legitimate to INFER user intent from a
> particular key usage type, and to what extent, if any, the subscriber can be
> bound to such a an alleged "death penalty" type of certificate on the basis
> of some shrink-wrapped or "click-wrapped" contract of adhesion, based on the
> user's cursory acceptance of a CA's CPS or subscriber agreement.
> 
> signatures that are intended to be legally binding, but I now believe that it
> would be prudent to provide an additional indicator to serve as a more
> explicit indication that the user did in fact consciously intend to be
> legally bound by her signature.
> 
> However, although I am not as certain as I'd like to be, I don't believe that
> the existing "digital signature" signedData bit in CMS provides this
> indication.