Subject: Re: Non-Repudiation

From: Stephen Kent <[email-masked]>
Date: Fri, 13 Aug 1999 18:32:02 -0400

Bob,

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

There are many examples of PKI use where the thorny legal issues you cite
do NOT arise, as I have noted in the past.  For example, using certs for
authentication for SSL and IPsec, in lieu of using passwords, SecurID cards
etc.  So, irrespective of the casual e-mail example, we have lots of
situations that are of value to businesses but which do not involve NR and
do not require "help" from attorneys.

>>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.)

Given the broad base of WG members, including new members, I do not
evaluate the utility of a definition by whether it is well understood by
everyone who happens to contribute to discussions.  In a less contentious
example, we have had numerous examples of confusion in the IPsec WG over
completely factual issues, due to less than careful reading of specs, etc.
So, I don't agree with your criteria for deciding whether the NR definition
I cited is appropriate or not.

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

Yes, and if this were the ABA committee, I'm sure that would be a
beneficial debate.  But this is NOT that committee.

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

Yes, so?

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

Yes, so?

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

Most of "we" are not trying to do what you suggest.  We are defining a bit
and explaining what we mean when the bit is turn on or off.  Others will
decide, over time, how that fits into any specific legal context.  We have
an obligation to make good technical decisions regarding the syntax and
processing for our protocols, and I believe that we are doing just that.

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

Deliberation on a topic is valuable up to a point.  I think we passed that
point on this topic a while ago.

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

I'd rather not devote much time on the list to speculating on those out of
scope topics, providing less than expert fodder for those other discussions.

<snip>

Steve

---

From: Ed Gerck <[email-masked]>
Date: Sat, 14 Aug 1999 01:19:03 -0700

Stephen Kent wrote:

> Bob Jueneman wrote:
> >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.
> >would have been a lot easier to develop and use.  But for business uses,
> >have been working to try to draw the technologists and the legal community

Steve:

The US has 50% of the world's lawyers. This is also the only country
I know of where amateur lawyers are accepted. And yet, based on
my direct professional experience in Germany, Belgium, US, Argentina and
Brazil and also with companies based in Sweden, Switzerland, Japan, Italy
and France, I have not yet seen a country where the gulf between lawyers
and non-lawyers is so large.  No one needs "help" from attorneys, since they
usually charge for it ;-),  but anyone that uses the word "business" and then
denies any value of "legal issues" in regard to it either does not know business,
does not know law or thinks that the reader does not know them.

So, I must agree 100% with Bob Jueneman when he affirms: "for business uses,
it is simply not possible to ignore the potential legal issues".  As a bit of advice,
I suggest you do too.

BTW, using client certs for authentication in SSL does introduce a series of
new legal questions over using passwords -- but I am not going to explain
this again since I already did it in the list. I am just noting that lack of
opposition oftentimes does not denote accord but simply a courteous attitude
in face of lack of understanding.  This is also why I chose not to reply when, for
example, you denied the need to consult a CRL before relying on an S/MIME
message.  Or, when you denied the need for fresh data in NR. Or, when you
insisted that the lifetime of a certificate is inversely proportional to the square
of the number of attributes.  I believe however these actions are an overstepping
of your function as WG Chair since this WG is not supposed to be an one-man
show, and I do not say this in order to question your authority or as a personal
argument but to point out that bullying the debate has a limit -- over which
people may just politely bow and let the way clear to the cliff.

Again, I don't care what  ISO says about NR because ISO is wrong and
several voices here have said this besides myself, and ISO is a private
company -- not an international treaty organization that must be followed.
Surely, ISO is entitled to their  opinions or 'standards' -- so, I have
nothing against ISO per se.  But the argument  that IETF matters are
defined by ISO would mean that IETF must also abandon TCP/IP and
SMTP (just to cite a few cases).  So, I do not buy it.

If my private mailbox could be proof, or if one would do an unbiased survey
of the PKIX list messages over the past weeks I believe it would become
clear that the WG consensus is that the present definition of NR *and* the
present text on the nonRepudiation bit are both misleading and need to be
changed ASAP before they create lateral damage, besides their own technical
and legal damage.

Already in another thread here, we can read [Russ Housley]:

"The setting of the nonrepudiation bit is a rat hole, as you can see on
other threads on ietf-pkix.  It does not impact cert path validation, so I
would like to avoid that rat hole...."

I note also that, of recent, you have been insisting that "I think we passed that
point on this topic a while ago" in regard to revisiting the NR bit .  Thus, I infer
that this is the last strawman argument on the NR debate.  But, I do not buy it.

Since I have no interest whatsoever in IETF politics or long rethorics over
the "broad base of WG members",  and my motivation is essentially
technical as an Engineer and a Ph.D., you may take my opinion as a sincere
vision of what list consensus indicates is a largely uncontrolled liability and a
rat hole, regardless how old the mistake is or how "small" that bit may seem.

A secondary but overshadowing mistake is, as I have also commented, that
this IETF WG may be connected with an extension of IETF protocols over
the domain of applications and, even, what "user intent" is. Language in the
current text says :

 " ...to provide a non-repudiation service which protects against the signing
  entity falsely denying some action"

and now we have user intent ("falsely denying") as a parameter in an IETF
spec, besides the empty word "protects".  Perhaps, following this slippery
slope further down, a new WG should be formed to discuss an RFC on
"falsely denying" and define how it  can be established in a protocol over the
wire. Clearly, I am exaggerating -- but, how else, pray tell, could you define
"falsely denying" in an IETF protocol?  The exaggeration is thus not in my
words but in what is affirmed in that spec.

So, in all fairness,  I think this WG has reached a reasonable intersubjective
understanding of the NR issue and it is now up to the spec scribes to make
the next move and correct the old spec version. That is what this WG is for,
no?

Cheers,

Ed Gerck

---

From: Paul Koning <[email-masked]>
Date: Mon, 16 Aug 1999 10:02:57 -0400

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

 Stephen> Bob,
 >> 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.

 Stephen> There are many examples of PKI use where the thorny legal
 Stephen> issues you cite do NOT arise, as I have noted in the past.
 Stephen> For example, using certs for authentication for SSL and
 Stephen> IPsec, in lieu of using passwords, SecurID cards etc. 

Agreed.  But, unless I'm missing something, those don't involve the
semantics, if any, of the NR bit.  It's the NR bit that's been the
subject of this long drawn-out discussion.  My understanding of the NR 
concept has always been that it is tied to legal issues.  Viewed in
purely technical isolation in such applications as IPSec endpoint
authentication, it doesn't seem to do anything useful.

So I think the issues Bob raises are relevant.  If the only meaningful 
applications of the NR bit are tied to legal notions, but those legal
notions aren't in agreement with what the NR bit does, or the
mechanisms don't work to support them, then the NR bit doesn't
actually do anything useful.  It doesn't seem like a good idea to have 
a bit whose name suggests a specific application, but it doesn't
actually support those applications, and if it supports other things,
those things aren't what the name implies.  Finding out whether that's 
indeed the case seems to be what the debate is all about.  I don't
think it's appropriate to try to stop it while that issue clearly
remains unsettled.

	paul

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Aug 1999 14:48:13 -0400

Oaul,

>authentication, it doesn't seem to do anything useful.

You are correct that NR is not a bit I would expect to set in certs used
for IPsec or SSL, for example.

>think it's appropriate to try to stop it while that issue clearly

The issues Bob and Ed raise are relevant, but we do not agree that they are
correct.  The NR bit is provided to allow a CA to assert whether a
certificate is suitable for use in an NR context.  Not setting the bit is,
by itself, valuable, to prevent certs from being considered suitable as
part of NR evidence when there is clear intent that this not be done.
However, even when the NR bit is set, one must be cognizant of the policy
of the CA in question, which can be specified by a policy OID.  One might
ask if, given the availability of a policy OID, do we need to use the NR
bit?  Perhaps not.  But various combinations of uses of these fields are
possible.  For example, a CA may have on policy that covers all certs it
issues, and it may the rely on the NR bit to state which part of the policy
applies to a given cert.  Or, a CA may not put policy info into a cert and
rely on a posted CPS, and again rely on inclusion of the NR bit to trigger
which part of the CPS is applicable to the cert in question.

In each of these cases, there is a valid, reasonable use of the NR bit in
conjunction with other aspects of conveying NR policy info.  No one can
point to a uniform, international, legal approach to the technical details
of NR evidence, so it is not valid to argue that the examples I have cited
here are inconsistent with such (non-existant) rules.  Under these
circumstances is appropriate for the WG to continue to develop technical
mechanisms for expressing intent re the use of certs, so long as we have a
solid technical basis for doing so.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Tue, 17 Aug 1999 12:34:19 -0700

Stephen Kent wrote:

>  No one can point to a uniform, international, legal approach to the technical
> details of NR evidence, so it is not valid to argue that the examples I have cited
> here are inconsistent with such (non-existant) rules.

Steve:  But, there is. Pls read my reply to Tom Zmudzinski.

Cheers -- Ed Gerck

PS.: this is a short message ;-)

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Aug 1999 16:28:47 -0400

Ed,

>PS.: this is a short message ;-)

Yes, it's short, but not true.  ;-)

Note my insistence on uniform rules, on a worldwide basis.  The examples
you provide are the opinions of a few people, based on digital signature
laws and regulations that vary from state to state and from country to
country. I have been involved with some of the ABA committee early
deliberations, I subscribe to the list, I have professional interations
with some of the international regs (as my company sells into these
markets).  It's a mess, it's unstable, and there are widely varying
opinions among legal professionals about these matters.

I believe in the ability of well-grouned technical standards to pave the
way for appropriate legal regulations, although they are not a guarantee of
such.

Steve

---

From: "tog" <[email-masked]>
Date: Tue, 17 Aug 1999 22:36:22 -0700

Stephen -

----- Original Message -----
From: Stephen Kent <[email-masked]>

SNIP -

> The NR bit is provided to allow a CA to assert whether a
> certificate is suitable for use in an NR context.

This is exactly the reason for this argument. We all say that there should
be a way of signifying a "different mode" of processing or looking at the
cert operations, but this is a single bit. That makes a total of two
possible modes. NR and Not NR.

The issue is that becuase we acknowledge that PKI needs multiple modes of
processing and a mechanism from the trust component to signal this to the
app that is using it, so all we have to ask is the simple question: IS TWO
MODES ENOUGH?

I personally think not, and that the NR bit could easily be upgraded to be
either a bit or an OID in the TS process. This would allow for much more
control on policy sensitive models that use the timestamp for more than an
evidentiary token so I think its a very good thing.

> Not setting the bit is,
> of the CA in question, which can be specified by a policy OID.

Maybe someone will do an ID on standard policy models, and we can get some
template policy OIDS. Actually, it sort of sounds like something that NIST
should supply.

> One might
> bit?  Perhaps not.

No, I think that you are right that the NR feature is conceptually a good
thing, but I want to have it at least optionally  based on an OID at the
very minimum. As a single bit it is pretty of limited in the scope of its
effectivity.

> But various combinations of uses of these fields are