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]
Re: Non-repudiation (was RE: The PAIN mnemonic)
At 06:24 PM 12/23/03 -0700, Richard Johnson wrote: ... In my eperience, the terminology has more often been confidentiality, integrity, and authentication. Call it CIA if you need an acronym easy to memorize, if only due to its ironic similarity with that for the name of a certain US government agency. :-) Surely a better government-related TLA for this would be derived from Non-changeability, Secrecy, and Authentication :) Richard --John Kelsey, [EMAIL PROTECTED] PGP: FA48 3237 9AD5 30AC EEDD BBC8 2A80 6948 4CAA F259 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Non-repudiation (was RE: The PAIN mnemonic)
At 18:02 29/12/2003, Ben Laurie wrote: Amir Herzberg wrote: ... specifications, I use `non-repudiation` terms for some of the requirements. For example, the intuitive phrasing of the Non-Repudiation of Origin (NRO) requirement is: if any party outputs an evidence evid s.t. valid(agreement, evid, sender, dest, message, time-interval, NRO), then either the sender is corrupted or sender originated message to the destination dest during the indicated time-interval. Notice of course that sender here is an entity in the protocol, not the human being `behind` it. Also notice this is only intuitive description, not the formal specifications. What you have here is evidence of origin, not non-repudiation. Ben, thanks, I'll change to this term (`evidence` instead of `non-repudiation`) since it appears from this thread that it may avoid confusion (at least for some people). Best regards, Amir Herzberg Computer Science Department, Bar Ilan University Homepage (and lectures in applied cryptography, secure communication and commerce): http://amir.herzberg.name - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Non-repudiation (was RE: The PAIN mnemonic)
Amir Herzberg wrote: Ian proposes below two draft-definitions for non-repudiation - legal and technical. Lynn also sent us a bunch of definitions. Let's focus on the technical/crypto one for now - after all this is a crypto forum (I agree the legal one is also somewhat relevant to this forum). In my work on secure e-commerce, I use (technical, crypto) definitions of non-repudiation, and consider these as critical to many secure e-commerce problems/scenarios/requirements/protocols. Having spent considerable time and effort on appropriate definitions and analysis (proofs), I was/am a bit puzzled and alarmed to find that others in our community seem so vehemently against non-repudiation. Of course, like other technical terms, there can be many variant definitions; that is not really a problem (the community will gradually focus on few important and distinct variants). Also it's an unavoidable fact of life (imho) that other communities (e.g. legal) use the same term in somewhat different meaning. So my question is only to people like Ben and Carl who have expressed, if I understood correctly, objection to any form of technical, crypto definition of non-repudiation. I repeat: do you really object and if so why? I object because its not a technical, crypto concept. It doesn't matter what you do to try to achieve non-repudiation technically, I can always repudiate it - all I have to do is say I didn't sign that or it wasn't me that initiated that transaction. What of applications/scenarios that seem to require non-repudiation, e.g. certified mail, payments, contract signing,...? These do not require non-repudiation in the existing world, why do they suddenly need it when they become electronic? What I presume you are trying to get at is to distinguish the use of a key with an intent to bind you rather than with an intent to provide authentication (or some other service signing can provide). This is not non-repudiation, it's something else, and it only confuses matters to use the wrong word for it. 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: Non-repudiation (was RE: The PAIN mnemonic)
Carl Ellison wrote: If you want to use cryptography for e-commerce, then IMHO you need a contract signed on paper, enforced by normal contract law, in which one party lists the hash of his public key (or the whole public key) and says that s/he accepts liability for any digitally signed statement that can be verified with that public key. One of the things my paper discusses is that under UK law a signature on an email is just as binding as on paper, because contracts are all about intent to be bound and not the medium in which they are captured. Of course, if you want to repudiate an email it is probably easier, especially if you signed it by typing your name at the bottom (yes, this is a valid signature under UK law), but that's a judgement call on the part of the relying party. Any attempt to just assume that someone's acceptance of a PK certificate amounts to that contract is extremely dangerous, and might even be seen as an attempt to victimize a whole class of consumers. Agreed - as I say, its all about intent and reliance. Nothing is automatic. 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: Non-repudiation (was RE: The PAIN mnemonic)
Carl Ellison wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Kelm Sent: Tuesday, December 23, 2003 1:44 AM To: [EMAIL PROTECTED] Subject: Re: Non-repudiation (was RE: The PAIN mnemonic) Ah. That's why they're trying to rename the corresponding keyUsage bit to contentCommitment then: http://www.pki-page.info/download/N12599.doc :-) Cheers, Stefan. Maybe, but that page defines it as: -- contentCommitment: for verifying digital signatures which are intended to signal that the signer is committing to the content being signed. The precise level of commitment, e.g. with the intent to be bound may be signaled by additional methods, e.g. certificate policy. Since a content commitment signing is considered to be a digitally signed transaction, the digitalSignature bit need not be set in the certificate. If it is set, it does not affect the level of commitment the signer has endowed in the signed content. Note that it is not incorrect to refer to this keyUsage bit using the identifier nonRepudiation. However, the use this identifier has been deprecated. Regardless of the identifier used, the semantics of this bit are as specified in this standard. -- Which still refers to the signer having an intent to be bound. One can not bind a key to anything, legally, so the signer here must be a human or organization rather than a key. It is that unjustifiable linkage from the actions of a key to the actions of one or more humans that needs to be eradicated from the literature. This is going a little far, isn't it? If the human controls the setting of the bit, then it is signalling their intent. 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: Non-repudiation (was RE: The PAIN mnemonic)
Amir Herzberg wrote: At 04:20 25/12/2003, Carl Ellison wrote: ... If you want to use cryptography for e-commerce, then IMHO you need a contract signed on paper, enforced by normal contract law, in which one party lists the hash of his public key (or the whole public key) and says that s/he accepts liability for any digitally signed statement that can be verified with that public key. Of course! I fully agree; in fact the first phase in the `trusted delivery layer` protocols I'm working on is exactly that - ensuring that the parties (using some external method) agreed on the keys and the resulting liability. But when I define the specifications, I use `non-repudiation` terms for some of the requirements. For example, the intuitive phrasing of the Non-Repudiation of Origin (NRO) requirement is: if any party outputs an evidence evid s.t. valid(agreement, evid, sender, dest, message, time-interval, NRO), then either the sender is corrupted or sender originated message to the destination dest during the indicated time-interval. Notice of course that sender here is an entity in the protocol, not the human being `behind` it. Also notice this is only intuitive description, not the formal specifications. What you have here is evidence of origin, not non-repudiation. 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: Non-repudiation (was RE: The PAIN mnemonic)
Ian proposes below two draft-definitions for non-repudiation - legal and technical. Lynn also sent us a bunch of definitions. Let's focus on the technical/crypto one for now - after all this is a crypto forum (I agree the legal one is also somewhat relevant to this forum). In my work on secure e-commerce, I use (technical, crypto) definitions of non-repudiation, and consider these as critical to many secure e-commerce problems/scenarios/requirements/protocols. Having spent considerable time and effort on appropriate definitions and analysis (proofs), I was/am a bit puzzled and alarmed to find that others in our community seem so vehemently against non-repudiation. Of course, like other technical terms, there can be many variant definitions; that is not really a problem (the community will gradually focus on few important and distinct variants). Also it's an unavoidable fact of life (imho) that other communities (e.g. legal) use the same term in somewhat different meaning. So my question is only to people like Ben and Carl who have expressed, if I understood correctly, objection to any form of technical, crypto definition of non-repudiation. I repeat: do you really object and if so why? What of applications/scenarios that seem to require non-repudiation, e.g. certified mail, payments, contract signing,...? Best regards, Amir Herzberg Computer Science Department, Bar Ilan University Lectures: http://www.cs.biu.ac.il/~herzbea/book.html Homepage: http://amir.herzberg.name Enclosed: At 21:33 23/12/2003, Ian Grigg wrote: Amir Herzberg wrote: Ben, Carl and others, At 18:23 21/12/2003, Carl Ellison wrote: and it included non-repudiation which is an unachievable, nonsense concept. Any alternative definition or concept to cover what protocol designers usually refer to as non-repudiation specifications? For example non-repudiation of origin, i.e. the ability of recipient to convince a third party that a message was sent (to him) by a particular sender (at certain time)? Or - do you think this is not an important requirement? Or what? I would second this call for some definition! FWIW, I understand there are two meanings: some form of legal inability to deny responsibility for an event, and cryptographically strong and repeatable evidence that a certain piece of data was in the presence of a private key at some point. Carl and Ben have rubbished non-repudiation without defining what they mean, making it rather difficult to respond. Now, presumably, they mean the first, in that it is a rather hard problem to take the cryptographic property of public keys and then bootstrap that into some form of property that reliably stands in court. 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). So, as a point of clarification, are we saying that non-repudiability is ONLY the first of the above meanings? And if so, what do we call the second? Or, what is the definition here? From where I sit, it is better to term these as legal non-repudiability or cryptographic non-repudiability so as to reduce confusion. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Non-repudiation (was RE: The PAIN mnemonic)
Yes, the term non-repudiation has been badly misused in old PKIX WG drafts (in spite of warnings by myself and others) and some crypto works of reference -- usually by well-intentioned but otherwise misguided people trying to add value to digital certificates. However, IMO non-repudiation refers to a useful and essential cryptographic primitive. It does not mean the affirmation of a truth (which is authentication). It means the denial of a falsity -- such as: (1) the ability to prevent the effective denial of an act (in other words, denying the act becomes a falsity); or (2) the ability to prevent the denial of the origin or delivery of transactions. Note that, except for a boolean system, the affirmation of a truth is not the same as the denial of a falsity. Hence, the usefulness of non-repudiation as a primitive. Take away non-repudiation and you end up with a lesser language with which to describe security processes. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Non-repudiation (was RE: The PAIN mnemonic)
Amir, my objection is to the word sender which, in definitions I've read, refers to the human being associated with a particular key. As long as we refer to a private key with no implication that this in any way incurs liability for a human being, then I'm happy -- but e-commerce folks are not. It is important to be able to authenticate a message origin and verify its integrity - the things that a dsig or MAC give you. When you use a public-key dsig, you have the added security advantage that the key capable of forming that signature does not need to be used to verify it. This is the original technical meaning of the term we're struggling over. However, in Diffie and Hellman's original paper, (which referred to this as undeniable, if I remember correctly), the confusion had already set in. A key would never deny or repudiate anything. That's an action by a human being. However, the use of public key cryptography does not imply anything about the human being to whom that key pair was assigned. So, I would use the terms authentication and integrity verification and avoid the term non-repudiation, since that one refers to human behavior and invokes liability on human beings. Since we have no idea how to make computer systems that capture proof of a human being's behavior and intentions, we can not claim to have any evidence that could be presented in court to show that a particular human being made a particular commitment, just based on some digital signature. We can prove that a given private key (to wit, the one private key corresponding to a public key that is entered into evidence) formed a signature over some message or file. However, any attempt to infer more than that is fallacious. If you want to use cryptography for e-commerce, then IMHO you need a contract signed on paper, enforced by normal contract law, in which one party lists the hash of his public key (or the whole public key) and says that s/he accepts liability for any digitally signed statement that can be verified with that public key. Any attempt to just assume that someone's acceptance of a PK certificate amounts to that contract is extremely dangerous, and might even be seen as an attempt to victimize a whole class of consumers. - Carl +--+ |Carl M. Ellison [EMAIL PROTECTED] http://theworld.com/~cme | |PGP: 75C5 1814 C3E3 AAA7 3F31 47B9 73F1 7E3C 96E7 2B71 | +---Officer, arrest that man. He's whistling a copyrighted song.---+ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Amir Herzberg Sent: Tuesday, December 23, 2003 1:18 AM To: [EMAIL PROTECTED] Subject: Re: Non-repudiation (was RE: The PAIN mnemonic) Ben, Carl and others, At 18:23 21/12/2003, Carl Ellison wrote: and it included non-repudiation which is an unachievable, nonsense concept. Any alternative definition or concept to cover what protocol designers usually refer to as non-repudiation specifications? For example non-repudiation of origin, i.e. the ability of recipient to convince a third party that a message was sent (to him) by a particular sender (at certain time)? Or - do you think this is not an important requirement? Or what? Best regards, Amir Herzberg Computer Science Department, Bar Ilan University Lectures: http://www.cs.biu.ac.il/~herzbea/book.html Homepage: http://amir.herzberg.name - 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: Non-repudiation (was RE: The PAIN mnemonic)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Kelm Sent: Tuesday, December 23, 2003 1:44 AM To: [EMAIL PROTECTED] Subject: Re: Non-repudiation (was RE: The PAIN mnemonic) Ah. That's why they're trying to rename the corresponding keyUsage bit to contentCommitment then: http://www.pki-page.info/download/N12599.doc :-) Cheers, Stefan. Maybe, but that page defines it as: -- contentCommitment: for verifying digital signatures which are intended to signal that the signer is committing to the content being signed. The precise level of commitment, e.g. with the intent to be bound may be signaled by additional methods, e.g. certificate policy. Since a content commitment signing is considered to be a digitally signed transaction, the digitalSignature bit need not be set in the certificate. If it is set, it does not affect the level of commitment the signer has endowed in the signed content. Note that it is not incorrect to refer to this keyUsage bit using the identifier nonRepudiation. However, the use this identifier has been deprecated. Regardless of the identifier used, the semantics of this bit are as specified in this standard. -- Which still refers to the signer having an intent to be bound. One can not bind a key to anything, legally, so the signer here must be a human or organization rather than a key. It is that unjustifiable linkage from the actions of a key to the actions of one or more humans that needs to be eradicated from the literature. - Carl +--+ |Carl M. Ellison [EMAIL PROTECTED] http://theworld.com/~cme | |PGP: 75C5 1814 C3E3 AAA7 3F31 47B9 73F1 7E3C 96E7 2B71 | +---Officer, arrest that man. He's whistling a copyrighted song.---+ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Non-repudiation (was RE: The PAIN mnemonic)
Amir, I am glad to see that you are treating this seriously. It is always possible to use the term non-repudiation for some legitimately defined thing - but I personally would prefer not to use the term because it has been tarred by over a decade of misuse (implying some presumption of liability on the part of a human being as a result of the behavior of a cryptographic key). I wish you luck with your protocols and look forward to seeing them. - Carl +--+ |Carl M. Ellison [EMAIL PROTECTED] http://theworld.com/~cme | |PGP: 75C5 1814 C3E3 AAA7 3F31 47B9 73F1 7E3C 96E7 2B71 | +---Officer, arrest that man. He's whistling a copyrighted song.---+ -Original Message- From: Amir Herzberg [mailto:[EMAIL PROTECTED] Sent: Thursday, December 25, 2003 2:47 AM To: Carl Ellison; [EMAIL PROTECTED] Subject: RE: Non-repudiation (was RE: The PAIN mnemonic) At 04:20 25/12/2003, Carl Ellison wrote: ... If you want to use cryptography for e-commerce, then IMHO you need a contract signed on paper, enforced by normal contract law, in which one party lists the hash of his public key (or the whole public key) and says that s/he accepts liability for any digitally signed statement that can be verified with that public key. Of course! I fully agree; in fact the first phase in the `trusted delivery layer` protocols I'm working on is exactly that - ensuring that the parties (using some external method) agreed on the keys and the resulting liability. But when I define the specifications, I use `non-repudiation` terms for some of the requirements. For example, the intuitive phrasing of the Non-Repudiation of Origin (NRO) requirement is: if any party outputs an evidence evid s.t. valid(agreement, evid, sender, dest, message, time-interval, NRO), then either the sender is corrupted or sender originated message to the destination dest during the indicated time-interval. Notice of course that sender here is an entity in the protocol, not the human being `behind` it. Also notice this is only intuitive description, not the formal specifications. Best regards, Amir Herzberg Computer Science Department, Bar Ilan University Lectures: http://www.cs.biu.ac.il/~herzbea/book.html Homepage: http://amir.herzberg.name - 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: Non-repudiation (was RE: The PAIN mnemonic)
Carl Ellison wrote: From where I sit, it is better to term these as legal non-repudiability or cryptographic non-repudiability so as to reduce confusion. To me, repudiation is the action only of a human being (not of a key) and therefore there is no such thing as cryptographic non-repudiability. Ah. Now I understand. The verb is wrong, as it necessarily implies the act of the human who is accused of the act. (And, thus, my claim that it is possible, was also wrong.) Whereas the cryptographic property implies no such thing, and a cryptographic actor can only affirm or not, not repudiate. I.e., it's a meaningless term. We need a different, more precise term for that - Would irrefutable be a better term? Or non- refutability, if one desires to preserve the N? The advantage of this verb is that it has no actor involved, and evidence can be refuted on its own merits, as it were. As a test, if one were to replace repudiate with refute in the ISO definition, would it then stand? and we need to rid our literature and conversation of any reference to the former - except to strongly discredit it if/when it ever appears again. I think more is needed. A better definition is required, as absence is too easy to ignore. People and courts will use what they have available, so it is necessary to do more; indeed it is necessary to actively replace that term with another. Generally, the way the legal people work is to create simple tests. Such as: A Document was signed by a private key if: 1. The signature is verifiable by the public key, 2. the public key is paired with the private key, 3. the signature is over a cryptographically strong message digest, 4. the Message Digest was over the Document. Now, this would lead to a definition of irrefutable evidence. How such evidence would be used would be of course dependent on the circumstances; it then becomes a further challenge to tie a human's action to that act / event. iang PS: Doing a bit of googling, I found the ISO definition to be something like: http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999OctDec/0149.html ... The ISO 10181-4 document (called non repudiation Framework) starts with: The goal of the non-repudiation service is to collect, maintain, make available and validate irrefutable evidence concerning a claimed event or action in order to solve disputes about the occurrence of the event or action. But, the actual standard costs money (!?) so it is not surprising that it is the subject of much controversy :) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Non-repudiation (was RE: The PAIN mnemonic)
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. Now, presumably, they mean the first, in that it is a rather hard problem to take the cryptographic property of public keys and then bootstrap that into some form of property that reliably stands in court. 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). So, as a point of clarification, are we saying that non-repudiability is ONLY the first of the above meanings? And if so, what do we call the second? Or, what is the definition here? From where I sit, it is better to term these as legal non-repudiability or cryptographic non-repudiability so as to reduce confusion. Read my paper (it was co-authored with a lawyer, so I believe we've got both the crypto and legal versions covered). 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: Non-repudiation (was RE: The PAIN mnemonic)
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. 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? 3. Nothing in either the definition 2.7 or the proper section of 6. tells us above why the claim is unintelligable. 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]. (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]. 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. Only once it is possible to move on from the fallacy embodied in the term repudiation itself, 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... 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? In practice, the process of
Re: Non-repudiation (was RE: The PAIN mnemonic)
On Sun, Dec 21, 2003 at 09:45:54AM -0700, Anne Lynn Wheeler wrote: note, however, when I did reference PAIN as (one possible) security taxonomy i tended to skip over the term non-repudiation and primarily made references to privacy, authentication, and integrity. In my eperience, the terminology has more often been confidentiality, integrity, and authentication. Call it CIA if you need an acronym easy to memorize, if only due to its ironic similarity with that for the name of a certain US government agency. :-) Richard - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Non-repudiation (was RE: The PAIN mnemonic)
At 01:34 AM 12/24/2003 -0800, Ed Gerck wrote: However, IMO non-repudiation refers to a useful and essential cryptographic primitive. It does not mean the affirmation of a truth (which is authentication). It means the denial of a falsity -- such as: (1) the ability to prevent the effective denial of an act (in other words, denying the act becomes a falsity); or (2) the ability to prevent the denial of the origin or delivery of transactions. so another way of looking at it ... is that somebody repudiates, refutes, and/or disavovs ... typically after the fact. non-repudiation would be those things that would support countering claims of repudiation, refuting, and/or disavowing. authentication is typically demonstrating that an entity is allowed to do something. authentication can include having a passphrase that is known by everybody in the organization. knowing the passphrase is sufficient to authenticate that somebody is allowed to do something. however, if somebody refutes that they had done something showing that they knew the passphrase (known by everybody in the organization) isn't sufficient to counter the repudiation claim. an infrastructure that requires a unique passphrase for every person would help counter repudiation claims public/private asymmetric cryptography systems where the infrastructure requires that a single person only has access to a particular private key would help counter repudiation claims. In that sense public/private key system can be seen as addressing both privacy and non-repudiation issues. the policies governing the determination of private key in a asymmetric cryptography infrastructure can influence whether it just pertains to just privacy and authentication and/or whether it can also be used to counter repudiation claims. while making sure that one only one person has knowledge of a specific private key, in no way impacts the asymmetric cryptography operations ... the process can be used to countering repudiation claims. while repudiation tends to be a human act it is entirely possible to have infrastructure and organizational implementation features that support countering claims of repudiation when they occur. say dozens of people know (the same) vault combination lock (authentication) which doesn't do anything to counter a particular person's claim that they didn't enter the vault, however video surveillance and door badge access logs could be considered as part of security taxonomy for countering repudiation claims. -- 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: Non-repudiation (was RE: The PAIN mnemonic)
Carl Ellison [EMAIL PROTECTED] writes: Ah. That's why they're trying to rename the corresponding keyUsage bit to contentCommitment then: Maybe, but that page defines it as: contentCommitment: for verifying digital signatures which are intended to signal that the signer is committing to the content being signed. The precise level of commitment, e.g. with the intent to be bound may be signaled by additional methods, e.g. certificate policy. This refers to the second (and IMHO more sensible) use of the X.509 nonRepudiation bit, which uses digitalSignature for short-term signing (e.g. user authentication) and nonRepudiation for long-term signing (e.g. signing a document). The other definition uses digitalSignature for everything, and nonRepudiation as an additional service on top of digitalSignature. The problem with that definition is that no two people in the X.509 world can agree on what nonRepudiation actually signifies. The best suggestion I've seen for the nonRepudiation bit is that CAs should set it to random values to disabuse users of the notion that it has any meaning. For the additional-service definition of nonRepudiation, the X.509 Style Guide says: Although everyone has their own interpretation, a good practical definition is Nonrepudiation is anything which fails to go away when you stop believing in it. Put another way, if you can convince a user that it isn't worth trying to repudiate a signature then you have nonrepudiation. This can take the form of having them sign a legal agreement saying they won't try to repudiate any of their signatures, giving them a smart card and convincing them that it's so secure that any attempt to repudiate a signature generated with it would be futile, threatening to kill their kids, or any other method which has the desired effect. One advantage (for vendors) is that you can advertise just about anything as providing nonrepudiation, since there's sure to be some definition which matches whatever it is you're doing (there are nonrepudiation schemes in use today which employ a MAC using a secret shared between the signer and the verifier, which must be relying on a particularly creative definition of nonrepudiation). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Non-repudiation (was RE: The PAIN mnemonic)
Amir Herzberg wrote: Ben, Carl and others, At 18:23 21/12/2003, Carl Ellison wrote: and it included non-repudiation which is an unachievable, nonsense concept. Any alternative definition or concept to cover what protocol designers usually refer to as non-repudiation specifications? For example non-repudiation of origin, i.e. the ability of recipient to convince a third party that a message was sent (to him) by a particular sender (at certain time)? Or - do you think this is not an important requirement? Or what? I would second this call for some definition! FWIW, I understand there are two meanings: some form of legal inability to deny responsibility for an event, and cryptographically strong and repeatable evidence that a certain piece of data was in the presence of a private key at some point. Carl and Ben have rubbished non-repudiation without defining what they mean, making it rather difficult to respond. Now, presumably, they mean the first, in that it is a rather hard problem to take the cryptographic property of public keys and then bootstrap that into some form of property that reliably stands in court. 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). So, as a point of clarification, are we saying that non-repudiability is ONLY the first of the above meanings? And if so, what do we call the second? Or, what is the definition here? From where I sit, it is better to term these as legal non-repudiability or cryptographic non-repudiability so as to reduce confusion. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Non-repudiation (was RE: The PAIN mnemonic)
At 11:18 AM 12/23/2003 +0200, Amir Herzberg wrote: Any alternative definition or concept to cover what protocol designers usually refer to as non-repudiation specifications? For example non-repudiation of origin, i.e. the ability of recipient to convince a third party that a message was sent (to him) by a particular sender (at certain time)? there is some reference in old posting in pkix thread: http://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudation possibly more than you want to know ... but merged security taxonomy and glossary ... sources at: http://www.garlic.com/~lynn/index.html#glosnote has definitions for: non-repudiation non-repudiation exchange non-repudiation information non-repudiation of creation non-repudiation of delivery non-repudiation of knowledge non-repudiation of origin non-repudiation of receipt non-repudiation of sending non-repudiation of submission non-repudiation of transport non-repudiation policy non-repudiation service non-repudiation token plus: NRD token NRO token NRS token NRT token -- 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: Non-repudiation (was RE: The PAIN mnemonic)
Ben, Carl and others, At 18:23 21/12/2003, Carl Ellison wrote: and it included non-repudiation which is an unachievable, nonsense concept. Any alternative definition or concept to cover what protocol designers usually refer to as non-repudiation specifications? For example non-repudiation of origin, i.e. the ability of recipient to convince a third party that a message was sent (to him) by a particular sender (at certain time)? Or - do you think this is not an important requirement? Or what? Best regards, Amir Herzberg Computer Science Department, Bar Ilan University Lectures: http://www.cs.biu.ac.il/~herzbea/book.html Homepage: http://amir.herzberg.name - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Non-repudiation (was RE: The PAIN mnemonic)
Let's just leave the term non-repudiation to be used by people who don't understand security, but rather mouth things they've read in books that others claim are authoritative. There are lots of those books listing non-repudiation as a feature of public key cryptography, for example, and many listing it as an essential security characteristic. All of that is wrong, of course, but it's a test for the reader to see through it. Ah. That's why they're trying to rename the corresponding keyUsage bit to contentCommitment then: http://www.pki-page.info/download/N12599.doc :-) Cheers, Stefan. --- Dipl.-Inform. Stefan Kelm Security Consultant Secorvo Security Consulting GmbH Albert-Nestler-Strasse 9, D-76131 Karlsruhe Tel. +49 721 6105-461, Fax +49 721 6105-455 E-Mail [EMAIL PROTECTED], http://www.secorvo.de --- PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Non-repudiation (was RE: The PAIN mnemonic)
At 08:23 AM 12/21/2003 -0800, Carl Ellison wrote: That's an interesting definition, but you're describing a constraint on the behavior of a human being. This has nothing to do with cryptosystem choice or network protocol design. What mechanisms do you suggest for enforcing even the constraint you cite? Of course, that constraint isn't enough. In order to achieve non-repudiation, the way it is defined, you need to prove to a third party (the judge) that a particular human being knowingly caused a digital signature to be made. A signature can be made without the conscious action of the person to whom that key has been assigned in a number of ways, none of which includes negligence by that person. total aside ... i just did jury duty in criminal case last week a mammal taxonomy can have * humans * horses * mice which doesn't mean that all mammal's have hooves, and correspondingly, all security doesn't have to have non-repudiation. if the authorizations and/or permissions require for somebody to be an employee ... it is possible to authenticate somebody as being an employee w/o having to authenticate who they are ... just sufficient to authenticate them as whether or not they are allowed to do what they are allowed to do. now, if you have 10,000 people that are authorized to do something ... and you have no tracking about what any specific person does then if some fraud takes place you may have no grounds whether to suspect any of the 10,000 over any of the others. However, if you have a policy that employees are strictly not suppose to share passwords and can get fired if they do and some fraud process takes placed ... done by an entity entering a specific password there would possibly be at least sufficient grounds to at least get a search warrant. The password by itself might not be sufficient to convict beyond a reasonable doubt ... but the audit trail might at least help point the investigation in the correct direction and also be admitted as circumstantial evidence. The defense attorneys in their opening statements said something about the prosecution showing means, motive, opportunity and misc. other things. in any case, I would claim that both human and non-repudiation issues are part of security. I wouldn't go so far as to say that just because a certification authority turned on a non-repudiation bit in a certificate and had no means at all of influencing human behavior, that just because the bit was turned on ... it, in anyway had anything to do with non-repducation. there is recent thread in pkx mailing list about the name of the non-repudiation bit in a certificate being depreciated. There seems to be two separate issues ... 1) calling the bit non-repudiation isn't consistent with the meaning of the bit and 2) the semantics of what the bit supposedly controls. -- 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]
Non-repudiation (was RE: The PAIN mnemonic)
-Original Message- From: Anne Lynn Wheeler [mailto:[EMAIL PROTECTED] Sent: Sunday, December 21, 2003 6:42 AM To: Carl Ellison Cc: 'Anne Lynn Wheeler'; [EMAIL PROTECTED] Subject: Re: The PAIN mnemonic At 11:20 PM 12/20/2003 -0800, Carl Ellison wrote: and it included non-repudiation which is an unachievable, nonsense concept. one could look at one aspect of non-repudiation as the requirement for everybody having a unique pin/password with guidelines never to share pin/passwords ... which could be considered across a broad range of security activities. That's an interesting definition, but you're describing a constraint on the behavior of a human being. This has nothing to do with cryptosystem choice or network protocol design. What mechanisms do you suggest for enforcing even the constraint you cite? Of course, that constraint isn't enough. In order to achieve non-repudiation, the way it is defined, you need to prove to a third party (the judge) that a particular human being knowingly caused a digital signature to be made. A signature can be made without the conscious action of the person to whom that key has been assigned in a number of ways, none of which includes negligence by that person. Let's just leave the term non-repudiation to be used by people who don't understand security, but rather mouth things they've read in books that others claim are authoritative. There are lots of those books listing non-repudiation as a feature of public key cryptography, for example, and many listing it as an essential security characteristic. All of that is wrong, of course, but it's a test for the reader to see through it. - Carl +--+ |Carl M. Ellison [EMAIL PROTECTED] http://theworld.com/~cme | |PGP: 75C5 1814 C3E3 AAA7 3F31 47B9 73F1 7E3C 96E7 2B71 | +---Officer, arrest that man. He's whistling a copyrighted song.---+ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Non-repudiation (was RE: The PAIN mnemonic)
At 08:23 AM 12/21/2003 -0800, Carl Ellison wrote: That's an interesting definition, but you're describing a constraint on the behavior of a human being. This has nothing to do with cryptosystem choice or network protocol design. What mechanisms do you suggest for enforcing even the constraint you cite? Of course, that constraint isn't enough. In order to achieve non-repudiation, the way it is defined, you need to prove to a third party (the judge) that a particular human being knowingly caused a digital signature to be made. A signature can be made without the conscious action of the person to whom that key has been assigned in a number of ways, none of which includes negligence by that person. Let's just leave the term non-repudiation to be used by people who don't understand security, but rather mouth things they've read in books that others claim are authoritative. There are lots of those books listing non-repudiation as a feature of public key cryptography, for example, and many listing it as an essential security characteristic. All of that is wrong, of course, but it's a test for the reader to see through it. I mentioned PAIN as a (in-use) security taxonomy ... not a cryptosystem taxonomy or network protocol taxonomy ... and there is nothing precluding human factors in a security paradigm (like human factors issues of requiring unique shared-secret for every security domain leading to humans having to fumble around with scores of shared-secrets). i agreee that non-repudiation has been seriously mis-used especially with regard to crypto systems. I've even made the assertion that possibly some of it can be contributed to having the word signature occur in both the term digital signature and legal signature even tho the two may have nothing at all to do with each other. note, however, when I did reference PAIN as (one possible) security taxonomy i tended to skip over the term non-repudiation and primarily made references to privacy, authentication, and integrity. sample of some past posts in various venues on the subject. http://www.garlic.com/~lynn/aepay7.htm#nonrep0 non-repudiation, was Re: crypto flaw in secure mail standards http://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re: crypto flaw in secure mail standards http://www.garlic.com/~lynn/aepay7.htm#nonrep2 non-repudiation, was Re: crypto flaw in secure mail standards http://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards http://www.garlic.com/~lynn/aepay7.htm#nonrep4 non-repudiation, was Re: crypto flaw in secure mail standards http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage http://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm12.htm#37 Legal entities who sign http://www.garlic.com/~lynn/aadsm12.htm#38 Legal entities who sign http://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI not working http://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards http://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards http://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature standards (slight addenda) http://www.garlic.com/~lynn/aadsm15.htm#35 VS: On-line signature standards http://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation practicalities
