Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
At 11:42 07/01/2004 -0800, Ed Gerck wrote: Jerrold Leichter wrote: > Now that we've trashed non-repudiation ... Huh? Processes that can be conclusive are useful and do exist, I read here, in the legal domain. It may not be so clear how such processes can exist in the technical domain and that's why I'm posting ;-) > just how is it different from authentication? Using an information theory model, it's clear that authentication needs one channel of information (e.g., the CA's public key, the password list) in addition to the signal (e.g., a signed message, a username/password entry). Authentication rests on the information channel being trusted (i.e., independently verifiable). In this model, non-repudiation is different because it needs at least one additional out-of-band signal (where authenticated absence of the signal is also effective). BTW, that's why digital signatures per se are repudiable -- there's no second, out-of-band signal. An additional technical difference is that authentication promotes "strength of evidence" while non-repudiation promotes "lack of repudiation of evidence". The latter is intuitively recognized to be stronger because a single, effective denial of an act can rebuke any number of strong affirmations. This also means, intuitively, that another difference exists. Non-repudiation should be harder to accomplish than authentication (you want more, you need to pay more). However, to the extent that the process *can be* conclusive, non-repudiation may be worth it. Imagine the added costs, time and hassle (going back to a real-world comparison) if your bank would have to call you to confirm payment for every check you sign? This would be the case if paying a check could not be cast as a conclusive process for the bank (i.e., without the possibility of an irrebuttable presumption of payability). In the UK, but not in other countries, there is a statutory rule which prevents a bank from debiting a customer's account with a forged cheque (if you will forgive the British spelling), with only very limited exceptions. If the customer repudiates a signature, it is for the bank to prove the genuineness of the signature, or suffer the loss. My bank has once or twice telephoned to check the genuineness of an unusual transaction, though this over a period of many years. This is not to disagree with your comments, but to observe that existing paper systems can work satisfactorily without non-repudiation rules. There are obvious advantages to some parties in such systems if it adopts a non-repudiation rule, probably matched with corresponding disadvantages for others. The change from paper to electronic systems of course also alters the balance of risks and the approach of banks to non-repudiation rules. I and colleagues have written about this at: http://elj.warwick.ac.uk/jilt/00-3/bohm.html Regards Nicholas Bohm Salkyns, Great Canfield, Takeley, Bishops 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
Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
I did a Google search on "irrebuttable presumption" and found a lot of interesting material. One research report on the State of Connecticut web site http://www.cga.state.ct.us/2003/olrdata/ph/rpt/2003-R-0422.htm says: "The Connecticut Supreme Court and the U. S. Supreme Court have held that irrebuttable presumptions are unconstitutional when they are not necessarily or universally true and the state has reasonable alternative means of making the determination." The comment appears to apply to statutes and regulations (as opposed to contracts). Still the two tests mentioned seem very appropriate to a discussion of non-repudiation as used in cryptography. In deciding whether the existence of a verified signature should automatically lead to some real world action, we should consider both the adequacy of the technology and the nature of the application. So, for example, the military might adopt an irrebuttable presumption that a cryptographically signed order comes from the registered owner of a cryptographic key, because it has vetted all the technology employed, it can't tolerate delay, and is willing to impose a duty on a key holders to protect their key or suffer the consequences. On the other end of the scale, anti-spam software might accept a signature validated by a public key that is included in a user's white list as conclusive proof that the message should be transmitted to that user because the consequences of doing so with a forged message are so minute. In the case of ordinary consumer transactions, an irrebuttable presumption for public key signatures would not seem to pass muster. There are too many problems with the technology (its not just a question of protecting the private key, but also of insuring the the document actually signed is the one the user thought he was signing) and there are usually other forms of evidence (e.g. delivery records) to substantiate the transaction. This is apparently a very complex area of law. Another paper http://www.law.nyu.edu/clppt/program2003/readings/Franck.doc includes these quotes: "Every writer of sufficient intelligence to appreciate the difficulties of the subject matter has approached the topic of presumptions with a sense of hopelessness and left it with a feeling of despair."5 Commenting on the law of presumptions, Judge Learned Hand has commented: "Judges have mixed it up until nobody can tell what on earth it means."6 It sounds like the legal profession long ago recognized the difficulties the cryptographic community is now grappling with regard to "non-repudiation." We should be very wary of assuming mathematical constructs naturally transform into the legal arena. Arnold Reinhold (who is not a lawyer) 5 Edmund M. Morgan, "Presumptions," 12 Wash. L. Rev. 255, 255 (1937). 6 L. Hand, 18 ALI Proceedings 217-18 (1941). At 5:32 PM -0800 1/5/04, Ed Gerck wrote: > In business, when repudiation of an act is anticipated we're reminded by Nicholas Bohm (whose clear thinking I know and appreciate for 6 years) that some lawyers find it useful to define "irrebuttable presumptions" -- a technique known to the law and capable of being instantiated in statute or contract. For example, a legal "irrebuttable presumption" can take the form of a bank check contract stating that a check (even though it can be *proven* a posteriori to be a forgery) is payable by the bank if the account holder did not notify the bank to repudiate the check *before* the check was presented to the bank for payment. The requirement can be seen an "out-of-band" signal from the account holder to the bank, which absence makes the check's payability an irrebuttable presumption by the bank. In this case, as long as the check's signature does not look like a (obvious) forgery and there is enough balance in the account, the bank has no liability to that customer in paying the check. Note also that the effectiveness of this method relies on an "indirect proof" -- the absence of a previous communication makes the check payable. Likewise, in a communication process, when repudiation of an act by a party is anticipated, some system security designers find it useful to define "non-repudiation" as a service that prevents the effective denial of an act. Thus, lawyers should not squirm when we feel the same need they feel -- to provide for processes that *can be* conclusive. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
Non-repudiation is really very simple in concept. "The ability to prove to a third party that you (or someone else) was party to a transaction". There are a lot of problems regarding who the third party must be, what constitutes "proof", etc., etc. In the English common-law system, this is applied in various ways and times. It all comes down to concepts of "reasonableness", "intent", "care" and so on. Can you say "convince the judge or jury of your peers" ? The same is true for authentication. John On 1/7/04 15:06, "Anton Stiglic" <[EMAIL PROTECTED]> wrote: > > - Original Message - > From: "Jerrold Leichter" <[EMAIL PROTECTED]> > Cc: "Cryptography" <[EMAIL PROTECTED]> > Sent: Wednesday, January 07, 2004 7:14 AM > Subject: Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)] > > >> Now that we've trashed non-repudiation ... just how is it different from >> authentication? > > I don't think the word "authentication" has the same problem as > "non-repudiation", > but you do need to be careful how you define it. > > So here we are talking about entity authentication (as opposed to data > authentication, > the latter really has a unambiguous definition, at least I hope it does!). > > The way you should define entity authentication > is by stating that it is a process of verifying that an entity possesses the > authentication > credentials associated to a user that entity claims to be. This entity > might be the rightful > user, or it might be someone who stole the credentials from the rightful > user. If someone > stole my ATM card and my PIN, he/she can successfully authenticate > him/herself to an > ATM and withdraw money. The word "authenticate" is appropriate in this last > phrase. > > But I see that most definitions that have been collected here: > http://www.garlic.com/~lynn/secgloss.htm#t523 > are not careful about this. > > The thing about non-repudiation is that it is something that even most laws > do not > permit. See for example: > http://www.firstmonday.dk/issues/issue5_8/mccullagh/ > > Non-repudiation applied to digital signatures implies that the definition > states that > only one person possibly had possession of the private signing key and was > conscious > about the fact that it was used to sign something. > > In most jurisdictions a person has the right to repudiate a signature > (had-written > or electronic), and thus non-repudiation does not work. People have the > right to > repudiate signatures since it might be the result of a forgery, fraud, the > signer might have > been drunk or something at the time of signing or forced to sign (like with > a gun to his > head).Repudiation is possible but non-repudiation is not. > > I know some people who use the term "accountability" instead of > "non-repudiation" > to express the property needed in certain systems (commercial > infrastructures where > users login and need to be accountable for their acts). This seems like a > better term > to be used in certain contexts, but I'm still thinking about it... > > --Anton > > > > > > > > - > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
Ed Gerck wrote: > Likewise, in a communication process, when repudiation of an act by a party is > anticipated, some system security designers find it useful to define > "non-repudiation" > as a service that prevents the effective denial of an act. Thus, lawyers should > not squirm when we feel the same need they feel -- to provide for processes > that *can be* conclusive. The problem with this is that the squirms happen at many levels. It seems unlikely that we can provide for conclusive processes when it comes to mixing humans and tech and law. If we try, we end up with the Ross Anderson scenario - our work being trashed in front of the courts. Hence the need for a new framework. Talk of non- repudiation has gone to the extent of permitting law makers to create new presumptions which - I suggest - aren't going to help anyone. For example, the law that Pelle posted recently said one thing to me: no sane person wants to be caught dead using these things: Pelle wrote: The real meat of the matter is handled in Article 31 (Page 10). "Guarantees derived from the acceptance of a Certificate": "The subscriber, at the time of accepting a certificate, guarantees all the people of good faith to be free of fault, and his information contained within is correct, and that: 1. The authenticated electronic company/signature verified by means of this certificate, was created under his exclusive control. 2. No person has had access to the procedure of generation of the electronic signature. 3. The information contained in the certificate is true and corresponds to the provided one by this one to the certification organization." Is that for real? Would you recommend that to your mother? I wouldn't be embarrassed to predict that there will be no certificate systems in Panama that rely upon that law. I think aiming at conclusivity might be a noble goal for protocol designers and others lower down in the stack. When humans are involved, the emphasis should switch to reduction in costs: strength of evidence, fast surfacing of problems, sharing of information, crafting humans' part in the protocol. When I design financial systems, I generally think in these terms: what can I do to reduce the cost and frequency of disputes? I don't aim for any sort of conclusivity at any costs, because that can only be done by by setting up assumptions that are later easily broken by real life. Instead, I tend to examine the disputes that might occur and examine their highest costs. One of the easiest ways to deal with them is to cause them to occur frequently, and thus absorb them into the protocol. For example, a TCP connection breaks - did the packet get there or not? Conclusion: connections cannot be relied upon. Protocol response: use a datagram + request-reply + replay paradigm, and lose a lot of connections, deliberately. Conclusivity is achieved, at the cost of some efficiency. Another example - did the user sign the message? We can't show what the user did with the key. So, make the private key the agent, and give it the legal standing. Remove the human from the loop. Make lots of keys, and make the system psuedonymous. We can conclusively show that the private key signed the message, and that agent is to whom our contractual obligations are directed. Technical conclusivity is achieved, at the expense of removing humans. The dispute that occurs then is when humans enter the loop without fully understanding how they have delegated their rights to their software agent (a.k.a. private key). We don't deny his repudiating, we simply don't accept his standing - only the key has standing. Which brings us full circle to Panama :-) Except, we've done it on our own contract terms, not on the terms of the legislature, so we can craft it with appropriate limits rather than their irrebuttable presumptions. >From this pov, the mistake that CAs make is to presume one key and one irrebuttable presumption. It's a capabilities thing; there should be a squillion keys, each with tightly controlled and surfaced rights. iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
Jerrold Leichter wrote: > Now that we've trashed non-repudiation ... Huh? Processes that can be conclusive are useful and do exist, I read here, in the legal domain. It may not be so clear how such processes can exist in the technical domain and that's why I'm posting ;-) > just how is it different from authentication? Using an information theory model, it's clear that authentication needs one channel of information (e.g., the CA's public key, the password list) in addition to the signal (e.g., a signed message, a username/password entry). Authentication rests on the information channel being trusted (i.e., independently verifiable). In this model, non-repudiation is different because it needs at least one additional out-of-band signal (where authenticated absence of the signal is also effective). BTW, that's why digital signatures per se are repudiable -- there's no second, out-of-band signal. An additional technical difference is that authentication promotes "strength of evidence" while non-repudiation promotes "lack of repudiation of evidence". The latter is intuitively recognized to be stronger because a single, effective denial of an act can rebuke any number of strong affirmations. This also means, intuitively, that another difference exists. Non-repudiation should be harder to accomplish than authentication (you want more, you need to pay more). However, to the extent that the process *can be* conclusive, non-repudiation may be worth it. Imagine the added costs, time and hassle (going back to a real-world comparison) if your bank would have to call you to confirm payment for every check you sign? This would be the case if paying a check could not be cast as a conclusive process for the bank (i.e., without the possibility of an irrebuttable presumption of payability). - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
| Non-repudiation applied to digital signatures implies that the definition | states that only one person possibly had possession of the private signing | key and was conscious about the fact that it was used to sign something. There is absolutely *no* cryptographic or mathematical content to this definition! It could as well apply to key locks, to signatures on paper, or whatever. It's in no way a property of a cryptographic system, or of *any* system. Nor, as written, is there even any possible set of evidence that could be adduced to prove this: After all, someone might, just by chance, have guessed the private key. Granted, there are significant issues with non-repudiation - so significant that it probably isn't a very useful concept. But it there *is* some cryptographic content behind it! Otherwise, what are we to make, for example, of the various "evolving signature key" schemes that detect stolen keys? -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
At 10:14 AM 1/7/2004 -0500, Jerrold Leichter wrote: Now that we've trashed non-repudiation ... just how is it different from authentication? In both cases, there is a clear technical meaning (though as with anything in mathematics, when you get right down to it, the details are complex and may be important): To produce an authenticator/non-repudiable signature, you must have access to the secret. There isn't, at this level, even any difference between the requirements for the two. Where we get into trouble is in attempting to bind the real world to the mathematics. In each case, the receiver wants to be able to say: lets say they are somewhat different threat models (but may have some partial overlap). it would be possible to give a dozen people the same passprhase and have some degree of confidence that only the permitted entities entitled to do something were authenticated. however, if one of them claimed that they didn't do some specific thing ... there would be difficult to differentiate between the different entities as to which entity had been authenticated at any specific time. some of the best practices security guidelines for authentication (like not sharing passwords) have more to do with non-repudiation ... than straight authentication. key-escrow can be considered mandatory for encryption keys under the non-single-point-of-failure and availability best practices. At the same time there may be mandatory requirements for NOT having key-escrow for authentication keys under non-repudiation best practices (even when the cryptographic technology is identical ... the issue of key-escrow policy is exactly opposite depending on whether the business use is encryption of authentication). a straight-forward authentication issue might be whether a particular message originated from a specific entity. That would not necessarily include the sense that the entity agreed with the terms and conditions described in the body of the message (say a financial transaction). This is somewhat akin to various EULA agreements that have people clicking on various buttons which is not an issue of authentication but of agreement; aka *repudiation* can include things that are outside the scope of authentication (not whether the message originated from me ... but do i fully agree with what is included in the body of the message). neither identification nor authentication by itself can necessarily include the concept of agreement. repudiation can include a number of items outside the sense of identification and authentication (like aggreement). -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
- Original Message - From: "Jerrold Leichter" <[EMAIL PROTECTED]> Cc: "Cryptography" <[EMAIL PROTECTED]> Sent: Wednesday, January 07, 2004 7:14 AM Subject: Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)] > Now that we've trashed non-repudiation ... just how is it different from > authentication? I don't think the word "authentication" has the same problem as "non-repudiation", but you do need to be careful how you define it. So here we are talking about entity authentication (as opposed to data authentication, the latter really has a unambiguous definition, at least I hope it does!). The way you should define entity authentication is by stating that it is a process of verifying that an entity possesses the authentication credentials associated to a user that entity claims to be. This entity might be the rightful user, or it might be someone who stole the credentials from the rightful user. If someone stole my ATM card and my PIN, he/she can successfully authenticate him/herself to an ATM and withdraw money. The word "authenticate" is appropriate in this last phrase. But I see that most definitions that have been collected here: http://www.garlic.com/~lynn/secgloss.htm#t523 are not careful about this. The thing about non-repudiation is that it is something that even most laws do not permit. See for example: http://www.firstmonday.dk/issues/issue5_8/mccullagh/ Non-repudiation applied to digital signatures implies that the definition states that only one person possibly had possession of the private signing key and was conscious about the fact that it was used to sign something. In most jurisdictions a person has the right to repudiate a signature (had-written or electronic), and thus non-repudiation does not work. People have the right to repudiate signatures since it might be the result of a forgery, fraud, the signer might have been drunk or something at the time of signing or forced to sign (like with a gun to his head).Repudiation is possible but non-repudiation is not. I know some people who use the term "accountability" instead of "non-repudiation" to express the property needed in certain systems (commercial infrastructures where users login and need to be accountable for their acts). This seems like a better term to be used in certain contexts, but I'm still thinking about it... --Anton - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
Now that we've trashed non-repudiation ... just how is it different from authentication? In both cases, there is a clear technical meaning (though as with anything in mathematics, when you get right down to it, the details are complex and may be important): To produce an authenticator/non-repudiable signature, you must have access to the secret. There isn't, at this level, even any difference between the requirements for the two. Where we get into trouble is in attempting to bind the real world to the mathematics. In each case, the receiver wants to be able to say: 1. I can rely on the fact that X sent me this data, because it came with a signature that could be calculated only by X. What he *really* needs to say is: 2. I can rely on the fact that X sent me this data, because it came with a signature that could be calculated only by someone knowing X's secret. To go from 2 to 1, the receiver must also have: 3. I can rely on the fact that only X knows X's secret. In ordinary English usage, there is little difference between "I've authenti- cated this message as coming from X" and "X can't deny that he wrote this message." We've learned that "non-repudiation" is a concept with relatively little use in the legal system. However, authentication (of a signature, document, whatever) is quite common (even if for the usual kinds of objects that need authentication, there is generally little to discuss). If the ultimate question is whether, as a legal matter, X is bound by some writing or whatever, authentication gets at the same basic question (which is only part, usually a small part, of the relevant legal issues). The problems that we've been discussion here are clear from 2 and 3: - "Rely on" is inherently outside of the cryptography or mathematics. It's only meaningful to the extent that there is some recourse (generally through agreements, but ultimately through the legal system) if you rely on something that turns out not be what you thought it was. - We identify "X" with an individual, but in fact "X" rarely knows the secret personally, and never does the actual calculations - some code running in some real physical machine does the work. So in fact we can't even begin to get 3; at best, we have: 3'. I can rely on the fact that, if X has shared his secret with Y (where Y is typically some equipment), then I can rely on X to be bound by whatever Y does. This is now so bizarre and removed from ordinary notions that it should be clear why it's unlikely be of much real-world use! -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
> In business, when repudiation of an act is anticipated we're reminded by Nicholas Bohm (whose clear thinking I know and appreciate for 6 years) that some lawyers find it useful to define "irrebuttable presumptions" -- a technique known to the law and capable of being instantiated in statute or contract. For example, a legal "irrebuttable presumption" can take the form of a bank check contract stating that a check (even though it can be *proven* a posteriori to be a forgery) is payable by the bank if the account holder did not notify the bank to repudiate the check *before* the check was presented to the bank for payment. The requirement can be seen an "out-of-band" signal from the account holder to the bank, which absence makes the check's payability an irrebuttable presumption by the bank. In this case, as long as the check's signature does not look like a (obvious) forgery and there is enough balance in the account, the bank has no liability to that customer in paying the check. Note also that the effectiveness of this method relies on an "indirect proof" -- the absence of a previous communication makes the check payable. Likewise, in a communication process, when repudiation of an act by a party is anticipated, some system security designers find it useful to define "non-repudiation" as a service that prevents the effective denial of an act. Thus, lawyers should not squirm when we feel the same need they feel -- to provide for processes that *can be* conclusive. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
Ian Grigg wrote: Which leaves the issue of what we call the property that differentiates a private key signature from a MAC or MD? A private key signature can only be produced by the holder of the private key, and can be verified by anyone (who has the public key). That is, it is asymmetric, just like PK encryption is. MACs and MDs (if keyed at all) use a shared secret, and thus behave like symmetric crypto. 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 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
Ben Laurie wrote: > > My co-author (a lawyer) responds in detail to Ian Grigg's criticisms. Thanks for that! As I'm not clear whether the status of the paper is searching of (more, further) detailed criticisms, I've not commented directly on Mr Bohm's remarks. For the most part, we are in agreement. Rather, I'll just quickly mention where I find one large difference of opinion: It's pretty apparent that what passes for common sense and knowledge of the meaning of words in the legal fraternity doesn't necessarily translate to our world of techies. I found the key to this debate was in understanding the full meaning of the word "repudiate" and that involved careful scrutiny of several dictionaries. The same goes for legal concepts such as presumptions, application of law, and so forth - Mr Bohm nailed me on my woeful understanding of rebuttals, and he'd have no trouble nailing the average techie who asserts that private key signatures prove this or that: they do no such thing, they provide evidence, yet, we still face a decade-old obsession with constructing cryptographic systems that purport to prove away all risks. So, I personally don't accept the argument that common sense can fill in the gaps. If common sense and ordinary knowledge had been available in such liberal doses, we wouldn't have spent the last decade or so working with non-repudiation. But, it is only by going through these discussions that I feel I now have a much firmer understanding of why non- repudiation is a crock. So thank you all! Which leaves the issue of what we call the property that differentiates a private key signature from a MAC or MD? iang PS: to refresh: http://www.apache-ssl.org/tech-legal.pdf - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
[Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
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 system
