Subject: RE: Non-repudiation (was RE: The PAIN mnemonic) -
msg#00210

Previous Message by Date:

RE: Non-repudiation (was RE: The PAIN mnemonic)

Ian, re. your two definitions: > -----Original Message----- > From: iang@xxxxxxxxxxxxxxxxxx > [mailto:iang@xxxxxxxxxxxxxxxxxx] On Behalf Of Ian Grigg > Sent: Tuesday, December 23, 2003 11:34 AM > To: Amir Herzberg; cme@xxxxxxx; Ben Laurie > Cc: cryptography@xxxxxxxxxxxx > Subject: Re: Non-repudiation (was RE: The PAIN mnemonic) > > FWIW, I understand there are two meanings: > > some form of legal inability to deny > responsibility for an event, and This one has no place in either technology or law because we do not know how to make computer systems that are honest witnesses to a person's behavior (incapable of being misused, infected by hostile S/W, etc.). > cryptographically strong and repeatable > evidence that a certain piece of data > was in the presence of a private key at > some point. > This might apply, as long as the thing that is in the presence of the private key is a hash value. However, this is not what I read in the ISO definitions of "non-repudiation". Those definitions refer to human beings and their behavior. > 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). I reject assumptions (e.g., that a home user has kept his computer locked away so that no one else could get to its keyboard and has kept it free of all hostile software) that are required to map from the cryptographic action back to the human action. > > 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? I believe that the standard definitions (e.g., in ISO documents) refer to the first. This is certainly what the PKI community refers to. That definition is not only wrong, technically, it is a violation of consumer rights if it were ever to be enforced. As a cryptographic community we should make sure that no one in the world still believes such nonsense. What we call the property of public-key cryptography is an interesting problem. Spelled out, the only property here is that we can do the same kind of MAC we've always done with symmetric keys, only the verifier doesn't need to know the key capable of making the signature. This is a security advantage - and nothing more. The logical fallacy that start with Diffie-Hellman is to say: 1. with symmetric key MACs, the verifier needed to know the secret key 2. therefore, the verifier could forge a MAC 3. therefore, you could not take a MAC into court to prove a claim against the other party 4. with public key signatures, you don't need to know the secret key (flawed step) 5: therefore, you can take a PK signature into court. All these improper assumptions about the behavior of the keyholder are back-peddling to cover up all the other ways that a PK signature could be made without the express consent of the alleged keyholder. That is not appropriate. We do not have step 5. We should rid our texts of any reference to that notion - and work with what we do have. It's good, but it's not magic. - Carl > > >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". We need a different, more precise term for that - 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. > iang > +------------------------------------------------------------------+ |Carl M. Ellison cme@xxxxxxx 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 majordomo@xxxxxxxxxxxx

Next Message by Date:

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 > majordomo@xxxxxxxxxxxx > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@xxxxxxxxxxxx

Previous Message by Thread:

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 kelm@xxxxxxxxxx, http://www.secorvo.de ------------------------------------------------------- PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@xxxxxxxxxxxx

Next Message by Thread:

Re: Non-repudiation (was RE: The PAIN mnemonic)

Carl Ellison wrote: -----Original Message----- From: owner-cryptography@xxxxxxxxxxxx [mailto:owner-cryptography@xxxxxxxxxxxx] On Behalf Of Stefan Kelm Sent: Tuesday, December 23, 2003 1:44 AM To: cryptography@xxxxxxxxxxxx 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 majordomo@xxxxxxxxxxxx