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 Phone01279 871272(+44 1279 871272) Fax020 7788 2198(+44 20 7788 2198) - please note new fax number Mobile07715 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)]
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)]
| 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)]
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)]
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)]
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)]
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)]
- 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]
