My co-author (a lawyer) responds in detail to Ian Grigg's criticisms.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

--- Begin Message ---
At 15:11 27/12/2003 -0500, Ian Grigg wrote:

>Ben Laurie wrote:
>> 
>> Ian Grigg wrote:
>> > Carl and Ben have rubbished "non-repudiation"
>> > without defining what they mean, making it
>> > rather difficult to respond.
>> 
>> I define it quite carefully in my paper, which I pointed to.
>
>
>Ah.  I did read your paper, but deferred any comment
>on it, in part because I didn't understand what its
>draft/publication status was.
>
>
>Ben Laurie said:
>> Probably because non-repudiation is a stupid idea:
>> http://www.apache-ssl.org/tech-legal.pdf.
>
>
>You didn't state which of the two definitions
>you were rubbishing, so I shall respond to both!
>
>
>
>Let's take the first definition - your "technical
>definition" (2.7):
>
>  "Non-repudiation", in its technical sense, is a property of a communications
>  system such that the system attributes the sending of a message to a person
>  if, but only if, he did in fact send it, and records a person as having received
>  a message if, but only if, he did in fact receive it. If such systems exist at all,
>  they are very rare.
>
>  Non-repudiability is often claimed to be a property of electronic signatures of
>  the kind described above. This claim is unintelligible if "non-repudiation" is
>  used in its correct technical sense, and in fact represents an attempt to confer a
>  bogus technical respectability on the purely commercial assertion the the owners
>  of private keys should be made responsible for their use, whoever in fact uses
>  them.
>
>Some comments.
>
>1. This definition seems to be only one of the many
>out there [1].  The use of the term "correct technical
>sense" then would be meaningless as well as brave
>without some support of references.  Although it does
>suffice to ground the use within the paper.

The other definitions all seem to have in common the notion that "non-repudiation" in 
the technical context is a property of a system or service, which is the essential 
element for the purpose of the paper.  If our definition is thought to be wrong in 
some material way, however, it would certainly be interesting to know what it is.


>2. The definition is muddied by including the attack
>inside the definition.  The attack on the definition would
>fit better in section 6. "Is \non-repudiation" a useful
>concept?"

That's a matter of taste.  In a formal, academic, paper, I would agree; but those 
don't try to avoid boring the reader with definitions before getting to the point.


>3. Nothing in either the definition 2.7 or the proper
>section of 6. tells us above why the claim is "unintelligable".

A little common sense is called for, certainly.  If "non-repudiation" is a 
*communications system* property, then it cannot be conferred or achieved by a single 
static component like a digital signature.  This is because there is no way of knowing 
from a digital signature who made it, without sufficient knowledge of the system 
within which it was made.  The article assumes some knowledge of familiar facts like 
these.


>To find this, we have to go back to Carl's comment
>which gets to the nub of the legal and literal meaning
>of the term:
>
>    "To me, "repudiation" is the action only of a human being (not of a key)..."
>
>Repudiate can only be done by a human [2].  A key cannot
>repudiate, nor can a system of technical capabilities [3].

I agree.  Indeed, I think these propositions are obvious and well-known, as a matter 
of the ordinary use of "repudiate".  The arguments criticised in our paper arise from 
the fact that "non-repudiation", in such arguments" is used to mean "being proof 
against improper repudiation" rather than "not having been repudiated".  The latter 
sense is the one which might have been thought natural before the invention of PKC and 
the development of what we say is the correct technical usage of "non-repudiation".

>(Imagine here, a debate on how to tie the human to the
>key.)
>
>That is, it is an agency problem, and unless clearly
>cast in those terms, for which there exists a strong
>literature, no strong foundation can be made of any
>conclusions [4].

Agency problems arise in contexts where there are two persons, a principal and an 
agent with authority to bind the principal.  Our discussion does not involve two such 
persons (machines are not recognised by any legal system I have ever heard of as 
having personality).


>4. The discussion resigns itself to being somewhat
>dismissive, by leaving open the possibility that
>there are alternative possibilities.  There is
>a name for this fallacy, stating the general and
>showing only the specific, but I forget its name.
>
>In the first para, 2.7, it states that "If such systems
>exist at all, they are very rare."  Thus, allowing
>for existance.  Yet in the second para, one context
>is left as "unintelligable."  In section 6, again,
>"most discussions ... are more confusing than helpful."
>
>This hole is created, IMHO, by the absence of Carl's
>killer argument in 3. above.  

The proposition in question (which it seems to me an exaggeration to call an argument) 
amounts to making explicit what is plainly implicit in the meaning of "repudiate".  
The article certainly assumes it.  I don't follow what the hole or the fallacy are 
that are mentioned above.

>Only once it is possible
>to move on from the fallacy embodied in the term
>repudiation itself, 

I don't think there is any such fallacy, though there are discussions which fail to 
distinguish between different meanings of "non-repudiation", and are as a result more 
confusing than helpful.

>is it possible to start considering
>what is "good" and useful about the irrefutability (or
>otherwise) of a digital signature [5].
>
>I.e., throwing out the bathwater is a fine and regular
>thing to do.  Let's now start looking for the baby.
>
>> > But, whilst challenging, it is possible to
>> > achieve legal non-repudiability, depending
>> > on your careful use of assumptions.  Whether
>> > that is a sensible thing or a nice depends
>> > on the circumstances ... (e.g., the game that
>> > banks play with pin codes).
>> 
>> Actually, its very easy to achieve legal non-repudiability. You pass a
>> law saying that whatever-it-is is non-repudiable. I also cite an example
>> of this in my paper (electronic VAT returns are non-repudiable, IIRC).
>
>Which brings us to your second definition, again,
>in 2.7:
>
>    To lawyers, non-repudiation was not a technical legal term before techies gave
>    it to them. Legally it refers to a rule which defines circumstances in which a
>    person is treated for legal purposes as having sent a message, whether in fact
>    he did or not, or is treated as having received a message, whether in fact he
>    did or not. Its legal meaning is thus almost exactly the opposite of its technical
>    meaning.
>
>
>I am not sure that I'd agree that the legal
>fraternity thinks in the terms outlined in the
>second sentance.  I'd be surprised if the legal
>fraternity said any more than "what you are
>trying to say is perhaps best seen by these
>sorts of rules..."

I think in these terms, and I come across other lawyers doing likewise.


>Much of law already duplicates what is implied
>above, anyway, which makes one wonder (a) what
>is the difference between the above and the
>rules of evidence and presumption, etc, etc
>and (b) why did the legal fraternity adopt
>the techies' term with such abandon that they
>didn't bother to define it?

(a) the above states a presumption - there is no difference
(b) although one cannot be sure, I suspect that they were misled into thinking the 
problem of false repudiation had been solved by technical means.


>In practice, the process of dispute resolution is
>very strongly oriented towards addressing evidence
>and moving it to a supported conclusion.  A
>digital signature is evidence, and conclusions
>can be supported based on that evidence;  what
>we techies should perhaps draw from this is
>that our efforts to define any new terms and any
>new procedures are childish in comparison to the
>logic and procedures developed in the forum of
>the law over the last few millenia.

I certainly think that the use of the new technical meaning of non-repudiation has 
lead to much misunderstanding.


>Next para:
>
>    Such a rule may be imposed by law, as for example this rule:
>
>       The person making the return to the Controller
>       shall be presumed to be the person identifed as
>       such by any relevant feature of the electronic
>       return system.[2]
>
>I disagree [6].  That clause creates a presumption.
>Nothing in the clause states that this cannot be
>repudiated.  In fact, careful examination of the
>preceeding clause concerning the time of the return
>indicates that "conclusive presumption" was preferred
>in this alternate time context.  Thus, repudiation
>of the party is anticipated, and repudiation of the
>time is "ruled against" [7].

Presumptions may be rebuttable or irrebuttable (sometimes also called "conclusive").  
This may appear from them, either by the use of the word "conclusive" or by a 
provision that states that the presumption applies "unless the contrary is proved".  
Sometimes the position is not made clear, and it is a matter of interpretation whether 
the presumption is rebuttable or not.

In this case I agree that the fact that a preceding presumption is stated to be 
conclusive suggests that this one is rebuttable since it is not also stated to be 
conclusive.  Disregarding the context, the rule is more likely to be regarded as 
laying down an irrebuttable presumption. since it makes no provision for the contrary 
to be proved.

Whether we chose a good enough example (and it's my fault that perhaps we didn't) is 
of course logically independent of the point that irrebuttable presumptions are a 
technique known to the law and capable of being instantiated in statute or contract.


>Further, repudiation as a word or concept does not
>appear in that act.  What happens is that the act
>ties down the event of the return;  it does not
>state that the return cannot be repudiated (although
>I grant that might occur elsewhere).  In Section
>(4L)(a) it specifically raises a case of potential
>repudiation.

"Non-repudiation" is not a term usually used by lawyers, since they already have 
presumptions which can do exactly the same work.


>The second (surveyors) clause/example is the same -
>it creates a presumption that can always be repudiated.

No.  It is a mistake (of law) to think that no presumptions can be conclusive, or that 
evidence can always be admitted to rebut them.

>In practice, the repudiation is an uncertain thing, as
>is all repudiations.  But, it is not possible to
>conclude, AFAIK, in law, that the clause is non-
>repudiable, simply because it states so.

No.  Words can mean just what they say.  The "parole evidence" rule (that oral 
evidence cannot be admitted to contradict a written agreement) still reigns.  For a 
recent example see the speech of Lord Hobhouse of Woodborough in Shogun Finance 
Limited v Hudson (FC) [2003] UKHL 62.


>Which all leads to this:  I don't think you have
>nailed down any legal definition of non-repudiability.
>Or, if that is what it is, the legal fraternity also
>knows that the techies' definition is a chimera, a
>mere hope on which to attach the use of dig sigs, in
>which case, this logic needs to be explained within
>the paper - that the definition doesn't exist.

I wish the legal fraternity understood better the extent to which the techies' notion 
of non-repudiation is based on a chimerical assumption that the gap between the 
signature and the signer can be closed by technical means.

>In essence, I can imagine a lawyer saying "yes,
>we already do what you are aiming for (presumption),
>but, your technical non-repudiability is impossible
>under the law because the law doesn't think in those
>terms..."

Technical non-repudiation is achievable, if at all, in the world of fact.  If it can 
be shown to have been achieved, then the law will respect it (perhaps over-respect it, 
as with some DNA evidence).  Legal non-repudiation can be achieved under the law by 
the use of conclusive presumptions.

What our paper was trying to make clear is that it is important not to muddle the two 
up.  If you can really do technical non-repudiation, you don't need to lay down a 
conclusive presumption; but if you can't, then you shouldn't lay down a conclusive 
presumption, and it's a matter of substantial policy debate whether you can fairly lay 
down even a rebuttable one.

>Nor does the paper nail why it doesn't make sense.

These comments certainly make clear to me that some of what we assumed could have been 
made more explicit.

>It omits the killer argument that the process of
>the dispute resolution moves from evidence to
>application of law to ruling;  

This is reasonably well known.

>a statement of
>non-repudiability is meaningless in that context.

Not at all.  Not only does it not follow from the preceding proposition, it is anyway 
wrong.

>(A lawyer would need to make this argument more
>carefully - I am not such and am conscious that I
>also haven't nailed it myself :)
>
>
>> Read my paper (it was co-authored with a lawyer, so I believe we've got
>> both the crypto and legal versions covered).
>
>
>I note the English & Wales legal context.  If there
>is a law that covers non-repudiation, by technical
>means, that would definately effect the nature of
>the discussion.
>
>iang
>
>
>[1] ref: Lynn's post that pointed at the ISO SC27
>definitions:
>http://www.garlic.com/~lynn/aadsm11.htm#14
>
>[2] http://dictionary.reference.com/search?q=repudiate
>...
>       1.To reject the validity or authority
>         of: "Chaucer... not only came to
>         doubt the worth of his
>         extraordinary body of work, but
>         repudiated it" (Joyce Carol
>         Oates). 
>       2.To reject emphatically as
>         unfounded, untrue, or unjust:
>         repudiated the accusation. 
>       3.To refuse to recognize or pay:
>         repudiate a debt. 
>       4.
>             a.To disown (a child, for
>                example). 
>             b.To refuse to have any
>                dealings with.
>
>For most relevance, examine 3., 4.a.
>
>
>[3] This is in part an assumption, as I am assuming
>here that AI and similar things cannot enter
>into contracts, or, if they do so, they are
>then persons, and thus the model stands.  We
>can test this by determining as to whether
>these "new persons" can take standing in a
>forum of dispute resolution.  Lawyers might
>like to comment on that, and as I say, it's
>an assumption!

Only a person can make a contract, though they can use a machine to do it.  The law 
lays down what counts as a person (it includes companies, for example, in addition to 
humans).


>[4] Agency problems are ones where a principal
>delegates powers to an agent, and those powers
>are used or abused according to the incentives
>and circumstances.  Canonically, a shop owner
>employs an assistant to mind the counter;  does
>the money taken in by sales made by the assistant
>go into his pocket, or her cashbox?
>
>[5] Irrefutability I proposed in an earlier
>email, and as yet lacks any credibility.
>
>[6] Link reproduced:
>http://www.hmso.gov.uk/si/si2000/20000258.htm
>
>[7] ruled against more firmly, perhaps.  There
>is nothing stopping a repudiation of the time,
>and presenting the reasons to the judge.  That's
>part of the process.

No, conclusive presumptions mean just what they say.

Regards

Nicholas
(Solicitor since 1968; member of the Law Society's Electronic Law Committee)

Salkyns, Great Canfield,
Takeley, Bishop’s Stortford CM22 6SX, UK

Phone   01279 871272    (+44 1279 871272)
Fax     020 7788 2198   (+44 20 7788 2198) - please note new fax number
Mobile  07715 419728 (+44 7715 419728)

PGP RSA 1024 bit public key ID: 0x08340015.  Fingerprint:
9E 15 FB 2A 54 96 24 37  98 A2 E0 D1 34 13 48 07
PGP DSS/DH 1024/3072 public key ID: 0x899DD7FF.  Fingerprint:
5248 1320 B42E 84FC 1E8B  A9E6 0912 AE66 899D D7FF 







--- End Message ---

Reply via email to