CDR: Re: Non-Repudiation in the Digital Environment (was Re: First Monday August 2000)
"Arnold G. Reinhold" wrote:
In public-key cryptography "Non-Repudiation" means that that the probability that a particular result could have been produced without access to the secret key is vanishingly small, subject to the assumption that the underlying public-key problem is difficult. If that property had be called "the key binding property" or "condition Z," or some other matheze name, we would all be able to look at this notion more objectively. "Non-repudiation," has too powerful a association with the real world.
Your definition is not standard. The Cryptography Handbook by Menezes defines non-repudiation as a service that prevents the denial of an act. The same is the current definition in PKIX, as well as in X.509. This does not mean, however as some may suppose, that the act cannot be denied -- for example, it can be denied by a counter authentication that presents an accepted proof. Thus, non-repudiation is not a stronger authentication -- neither a long lived authentication. Authentication is an assertion that something is true. Non- repudiation is a negation that something is false. Neither are absolute. And they are quite different when non-boolean variables (ie, real-world variables) are used. They are complementary concepts and *both* need to be used or we lose expressive power in protocols, contracts, etc.. Cheers, Ed Gerck
To transfer the cryptographic meaning of "non-repudiation" to a legal presumption against repudiation requires legislative acceptance four things:
1. the mathematically unproven assumptions in public key cryptography
2. the binding of a particular public key to a person
3. the ability of an ordinary individual to keep a private key secret
4. holding the individual responsible for failure to do so.
As for 1, note that at the moment there is not even consensus as to the long term security of , say, a 1024-bit RSA key. As to 2., read the Verisign certification practice statement. As to 4. not that in the US we do not presently hold individuals responsible for loss of a credit card.
The most problematic assumption is 3. McCullagh lists a couple of attacks, but there are many more. Here is my incomplete list:
1. Planting a program on the user's computer to capture their keyring and passphrase.
2. Replacing the users copy of the cryptographic program with a doctored version
3. Planting a bug in their keyboard to capture key strokes
4.* Using a microTV camera to capture passwords and PIN numbers
5.* Substituting documents. (You think you are buying a pizza but you are actually signing a deed to your house.
6. Public/private key pairs generated by a third party who's security is less than perfect
7. Poor or deliberately weak random number generation at key creation
8.* Algorithm substitution (e.g. multiprime) that weakens security to reduce computation times
9. Guessable passphrases and PINs
10.* Allowing someone else to use your key (does the president of World Wide Widget really hold the key token, or does he give it to his secretary?)
11.* Con artist techniques ("I'm an field agent from CyberSec -- here's my ID card -- and we'd like your help in tracking down child pornography dealers on the Internet. We'll need your key token and PIN. ")
12.* Finding ways to penetrate "tamper proof" mechanisms, e.g. power fluctuation attacks.
McCullagh believes that "trusted systems," which he defines as "at least Bl (TCSEC)/E3(ITSEC)/ or even possibly B2(TCSEC)/E4( ITSEC)" can provide a basis for non-repudiation in the legal sense. He is under the apprehension that "A trusted computing system performs in accordance with its documented specification and will prevent any unauthorised activity." Since Mr. McCullagh background is in law, let me provide an equivalent statement: "Laws reflect the public's consensus of what is right and wrong and the judicial system fairly and accurately enforces those laws." Both are statements of a lofty goal, not a reality that anyone has been able to achieve.
Well designed cryptographic tokens can counter some of the attacks I listed, but not all. The ones I marked with an asterisk are still applicable and there is still the problem of verifying and auditing the token manufacturer, a lucrative target for organized crime.
I can't address the legal arguments he makes since he is in Australia, but my understanding of the recently enacted electronic signature law in the US is that it attempts to put electronic signatures on exactly the same legal footing as paper signatures. It has no special status for PKC signatures. Clicking an http "I Accept" button is just as valid, as I understand the law.
The term "non-repudiation" should be retired. The best that one can say about public key signature systems for use by the general public is that they can make forgery much more difficult. That difficulty should result in reduced rates of attempted fraud, but should never be a valid pretext for changing the legal burden of proof.
Arnold Reinhold
Ed Gerck wrote:
"Arnold G. Reinhold" wrote:
In public-key cryptography "Non-Repudiation" means that that the probability that a particular result could have been produced without access to the secret key is vanishingly small, subject to the assumption that the underlying public-key problem is difficult. If that property had be called "the key binding property" or "condition Z," or some other matheze name, we would all be able to look at this notion more objectively. "Non-repudiation," has too powerful a association with the real world.
Your definition is not standard. The Cryptography Handbook by Menezes defines non-repudiation as a service that prevents the denial of an act. The same is the current definition in PKIX, as well as in X.509. This does not mean, however as some may suppose, that the act cannot be denied -- for example, it can be denied by a counter authentication that presents an accepted proof.
Thus, non-repudiation is not a stronger authentication -- neither a long lived authentication. Authentication is an assertion that something is true. Non- repudiation is a negation that something is false. Neither are absolute. And they are quite different when non-boolean variables (ie, real-world variables) are used. They are complementary concepts and *both* need to be used or we lose expressive power in protocols, contracts, etc..
Since we're in hair-splitting mode, I should point out that "prevents the denial of an act" is not equivalent to a "negation that something is false". Of course, logically, it comes to the same thing, but then, so does "assertion that something is true". Assuming you believe in excluded middles, that is (which, of course, you don't, as you have said). But the important point is that the mechanism could be (and usually is) entirely different. Blimey. I appear to be agreeing with Ed. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
On Sat, 7 Oct 2000, Ben Laurie wrote:
Since we're in hair-splitting mode, I should point out that "prevents the denial of an act" is not equivalent to a "negation that something is false". Of course, logically, it comes to the same thing, but then, so does "assertion that something is true".
Of course, the idea that you could 'prevent the denial of an act' is completely wrong. The explanation "All this fancy-schmancy crypto stuff is bullshit" is pretty much universally applicable. -Bram Cohen
The idea that you could prevent the denial of an act is neither an absolute truth nor provided only by cryptography. As I wrote before, " This does not mean, however as some may suppose, that the act cannot be denied -- for example, it can be denied by a counter authentication that presents an accepted proof." One way to do it is by policy or by contract, as banks do routinely in accepting checks -- and which is making its way into protocols by means of digital signatures as an extension of handwritten signatures. Further, it is clear that preventing the denial of an act is not equivalent to the "denial of a falsity" -- so, Ben's comment may help clarify this and I am thankful that he did so. However, understanding non-repudiation as a service that provides for the denial of a falsity is IMO a very general model that includes other notions of non-repudiation. Like authentication, non-repudiation comes in different flavors and it is IMO not a correct question to ask which one is correct -- it depends on the trust and threat models being used. Cheers, Ed Gerck Bram Cohen wrote:
On Sat, 7 Oct 2000, Ben Laurie wrote:
Since we're in hair-splitting mode, I should point out that "prevents the denial of an act" is not equivalent to a "negation that something is false". Of course, logically, it comes to the same thing, but then, so does "assertion that something is true".
Of course, the idea that you could 'prevent the denial of an act' is completely wrong. The explanation "All this fancy-schmancy crypto stuff is bullshit" is pretty much universally applicable.
-Bram Cohen
Bram Cohen wrote:
On Sat, 7 Oct 2000, Ben Laurie wrote:
Since we're in hair-splitting mode, I should point out that "prevents the denial of an act" is not equivalent to a "negation that something is false". Of course, logically, it comes to the same thing, but then, so does "assertion that something is true".
Of course, the idea that you could 'prevent the denial of an act' is completely wrong. The explanation "All this fancy-schmancy crypto stuff is bullshit" is pretty much universally applicable.
I have to agree that actually doing stuff with crypto is substantially more useful (and interesting) than trying to prove things with it. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/
At 12:12 PM -0700 10/7/2000, Ed Gerck wrote:
"Arnold G. Reinhold" wrote:
In public-key cryptography "Non-Repudiation" means that that the probability that a particular result could have been produced without access to the secret key is vanishingly small, subject to the assumption that the underlying public-key problem is difficult. If that property had be called "the key binding property" or "condition Z," or some other matheze name, we would all be able to look at this notion more objectively. "Non-repudiation," has too powerful a association with the real world.
Your definition is not standard. The Cryptography Handbook by Menezes defines non-repudiation as a service that prevents the denial of an act. The same is the current definition in PKIX, as well as in X.509. This does not mean, however as some may suppose, that the act cannot be denied -- for example, it can be denied by a counter authentication that presents an accepted proof.
Thus, non-repudiation is not a stronger authentication -- neither a long lived authentication. Authentication is an assertion that something is true. Non- repudiation is a negation that something is false. Neither are absolute. And they are quite different when non-boolean variables (ie, real-world variables) are used. They are complementary concepts and *both* need to be used or we lose expressive power in protocols, contracts, etc..
Cheers,
Ed Gerck
You may well be right about the accepted definition of non-repudiation, but if you are then I would amend my remarks to say that known cryptographic technology cannot provide non-repudiation service unless we are willing to create a new legal duty for individuals and corporations to protect their secret key or accept what ever consequences ensue. I don't think that is acceptable. I find the rest of your comment a tad too opaque. Could you give some examples of what you have in mind? Arnold Reinhold
"Arnold G. Reinhold" wrote:
You may well be right about the accepted definition of non-repudiation, but if you are then I would amend my remarks to say that known cryptographic technology cannot provide non-repudiation service unless we are willing to create a new legal duty for individuals and corporations to protect their secret key or accept what ever consequences ensue. I don't think that is acceptable.
Non-repudiation is, according to how myself and the PKIX WG consensus views it, a useful concept both in technical as well as in legal terms. Further, neither myself nor the specific discussion in the PKIX WG saw any need to require a specific legal framework to talk about technical applications of the non-repudiation concept. So, yes, technology can provide for non-repudiation services and the question whether or not these services are useful to provide evidences to a legal layer depends on many *other* considerations -- such as for example the legal regime (common law, civil law, statutes, contracts, etc.), which we do not control. What we can do on the technical side is provide protocols (with and without crypto -- for example, with timestamps that may be signed or made available in a tamperproof public record) that support non-repudiation as a service that prevents the denial of an act. This service is completely different from a service that proves an act, which is authentication. Neither of these services is absolute, though, and thus the notion of non-repudiation cannot be of an absolute answer. This is a common point between law and technology -- anything can be repudiated.
I find the rest of your comment a tad too opaque. Could you give some examples of what you have in mind?
You can check for example http://www.imc.org/draft-ietf-pkix-technr or ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-technr-01.txt Cheers, Ed Gerck
At 2:24 PM -0700 10/10/2000, Ed Gerck wrote:
"Arnold G. Reinhold" wrote:
You may well be right about the accepted definition of non-repudiation, but if you are then I would amend my remarks to say that known cryptographic technology cannot provide non-repudiation service unless we are willing to create a new legal duty for individuals and corporations to protect their secret key or accept what ever consequences ensue. I don't think that is acceptable.
Non-repudiation is, according to how myself and the PKIX WG consensus views it, a useful concept both in technical as well as in legal terms. Further, neither myself nor the specific discussion in the PKIX WG saw any need to require a specific legal framework to talk about technical applications of the non-repudiation concept. So, yes, technology can provide for non-repudiation services and the question whether or not these services are useful to provide evidences to a legal layer depends on many *other* considerations -- such as for example the legal regime (common law, civil law, statutes, contracts, etc.), which we do not control. What we can do on the technical side is provide protocols (with and without crypto -- for example, with timestamps that may be signed or made available in a tamperproof public record) that support non-repudiation as a service that prevents the denial of an act. This service is completely different from a service that proves an act, which is authentication. Neither of these services is absolute, though, and thus the notion of non-repudiation cannot be of an absolute answer. This is a common point between law and technology -- anything can be repudiated.
I find the rest of your comment a tad too opaque. Could you give some examples of what you have in mind?
You can check for example http://www.imc.org/draft-ietf-pkix-technr or ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-technr-01.txt
The Abstract of the draft-ietf-pkix-technr says
This document describes those features of a service which processes signed documents which must be present in order for that service to constitute a "technical non-repudiation" service. A technical non-repudiation service must permit an independent verifier to determine whether a given signature was applied to a given data object by the private key associated with a given valid certificate, at a time later than the signature. The features of a technical non- repudiation service are expected to be necessary for a full non- repudiation service, although they may not be sufficient.
My original point was the the technical definition of non-repudiation was much narrower that the legal definition. This draft seems to agree. It goes on to say:
The NR service is expected to provide evidence that a given object was signed by the private key corresponding to a given certificate which was valid at the time of signature. It is not anticipated that the use of the NR service will ordinarily constitute execution of a contract, or acceptance of any other legal obligation. It is anticipated that any use of this service in accepting legal obligations would be the subject of legislation or judicial decision in various jurisdictions, which are likely to lay additional technical burdens upon the provision of such a service to such an extent as to constitute another, larger service which need not be the same in all jurisdictions. It is outside the scope of the definition of this service to provide evidence that the signer and the subject of the signing certificate are the same, that the signer has been adequately informed of the content which is signed, that the signer is not acting under duress, etc.
My concern is that the vast majority of informed lay people, lawyers, judges, legislators, etc. will hear "non-repudiation" and hear "absolute proof." If you doubt this, read the breathless articles written recently about the new U.S. Electronic Signatures Act. I don't think technologists should be free to use evocative terms and then define away their common sense meaning in the fine print. Certainly a valid public key signature is strong evidence and services like that described in the draft can be useful. I simply object to calling them "non-repudiation services." I would not object to "anti-repudiation services," "counter-repudiation services" or "repudiation-resistant technology." Would the banking industry employ terms like "forgery-proof checks," "impregnable vaults" or "pick-proof locks" to describe conventional security measures that were known to be fallible? Arnold Reinhold
"Anti-repudiation" sounds good to me. ... even if does remind me of "antidisestablishmentarianism". Come to think of it, now even that term sounds appropriate here -- as our belief in the value of methods that deter key "dis-establishment". Pretty scary. -- dpj At 09:08 AM 10/11/00 -0400, Arnold G. Reinhold wrote:
My concern is that the vast majority of informed lay people, lawyers, judges, legislators, etc. will hear "non-repudiation" and hear "absolute proof." If you doubt this, read the breathless articles written recently about the new U.S. Electronic Signatures Act.
I don't think technologists should be free to use evocative terms and then define away their common sense meaning in the fine print. Certainly a valid public key signature is strong evidence and services like that described in the draft can be useful. I simply object to calling them "non-repudiation services." I would not object to "anti-repudiation services," "counter-repudiation services" or "repudiation-resistant technology." Would the banking industry employ terms like "forgery-proof checks," "impregnable vaults" or "pick-proof locks" to describe conventional security measures that were known to be fallible?
Arnold, Internet RFCs are technical specifications that use common English words in a strictly defined manner. To suggest that the use of names in computer code or Internet RFCs might have legal implications ... imagine lawyers examining some code and trying to attach meaning to variable names? Or to UNIX commands? For example, to kill or killall? Context dependent vocabulary can become highly amusing or disastrous if taken in a universal context, as was recently pointed out in the PKIX list by Peter Gien when someone complained about the legal implications of "good" as defined in RFC 2560. Non-repudiation is not different. In the crypto and RFC realm it means "a service that prevents the denial of an act" [Handbook of Cryptography, X.509, PKIX]. Different lawyers in different countries may define whatever they want but I note that the legal use of "non-repudiation" by banks worldwide is very similar to "a service that prevents the denial of an act". Cheers, Ed Gerck "Arnold G. Reinhold" wrote:
My concern is that the vast majority of informed lay people, lawyers, judges, legislators, etc. will hear "non-repudiation" and hear "absolute proof." If you doubt this, read the breathless articles written recently about the new U.S. Electronic Signatures Act.
I don't think technologists should be free to use evocative terms and then define away their common sense meaning in the fine print. Certainly a valid public key signature is strong evidence and services like that described in the draft can be useful. I simply object to calling them "non-repudiation services." I would not object to "anti-repudiation services," "counter-repudiation services" or "repudiation-resistant technology." Would the banking industry employ terms like "forgery-proof checks," "impregnable vaults" or "pick-proof locks" to describe conventional security measures that were known to be fallible?
At 10:20 PM -0700 10/15/2000, Ed Gerck wrote:
Arnold,
Internet RFCs are technical specifications that use common English words in a strictly defined manner. To suggest that the use of names in computer code or Internet RFCs might have legal implications ... imagine lawyers examining some code and trying to attach meaning to variable names? Or to UNIX commands? For example, to kill or killall?
I don't have to imagine it. I have been on the witness stand trying to explain terminology in technical documents that was quoted out of context by opposing council. (We won, but it cost a bundle in legal fees and management time.) I would also remind you of the _NSAKEY flap and countless product liability cases where minutia in engineering documents played a pivotal role. Also there is a big difference between comments in source code or Unix command names and a technical specification, like an RFC, that undergoes a formal review and approval process. The last will be given much more weight.
Context dependent vocabulary can become highly amusing or disastrous if taken in a universal context, as was recently pointed out in the PKIX list by Peter Gien when someone complained about the legal implications of "good" as defined in RFC 2560. Non-repudiation is not different. In the crypto and RFC realm it means "a service that prevents the denial of an act" [Handbook of Cryptography, X.509, PKIX]. Different lawyers in different countries may define whatever they want but I note that the legal use of "non-repudiation" by banks worldwide is very similar to "a service that prevents the denial of an act".
Even if your spec contained an explicit definition of "non-repudiation" that made clear its technical limitations, there is a high likelihood that the public and the legal system will be mislead. But the definition you cite dose not even do that. Here is what my "Random House Dictionary of the English Language" says about the meaning of "prevent:" "... Prevent, hamper, hinder, impede refer to different degrees of stoppage of action or progress. To prevent is to stop something effectually by forestalling action and rendering it impossible: 'to prevent the sending of a message'..." No cryptographic technology that I am aware of can fairly be said to render the denial of an act impossible. Arnold Reinhold
"Arnold G. Reinhold" wrote:
At 10:20 PM -0700 10/15/2000, Ed Gerck wrote:
Arnold,
Internet RFCs are technical specifications that use common English words in a strictly defined manner. To suggest that the use of names in computer code or Internet RFCs might have legal implications ... imagine lawyers examining some code and trying to attach meaning to variable names? Or to UNIX commands? For example, to kill or killall?
I don't have to imagine it. I have been on the witness stand trying to explain terminology in technical documents that was quoted out of context by opposing council. (We won, but it cost a bundle in legal fees and management time.) I would also remind you of the _NSAKEY flap and countless product liability cases where minutia in engineering documents played a pivotal role. Also there is a big difference between comments in source code or Unix command names and a technical specification, like an RFC, that undergoes a formal review and approval process. The last will be given much more weight.
Borrowing from a private comment from Bob Jueneman, whatever the technical community decides that non-repudiation means, it probably isn't what the legal community means. So be it. Certainly the legal profession uses ordinary English words to mean other than their ordinary meaning in a particular context, and so do other professions. BTW, consider the word "impregnable". Everyone knows what it means, right? Wrong! Consider the sentence "Alice is impregnable." It has two diametrically opposite meanings!
Context dependent vocabulary can become highly amusing or disastrous if taken in a universal context, as was recently pointed out in the PKIX list by Peter Gien when someone complained about the legal implications of "good" as defined in RFC 2560. Non-repudiation is not different. In the crypto and RFC realm it means "a service that prevents the denial of an act" [Handbook of Cryptography, X.509, PKIX]. Different lawyers in different countries may define whatever they want but I note that the legal use of "non-repudiation" by banks worldwide is very similar to "a service that prevents the denial of an act".
Even if your spec contained an explicit definition of "non-repudiation" that made clear its technical limitations, there is a high likelihood that the public and the legal system will be mislead. But the definition you cite dose not even do that. Here is what my "Random House Dictionary of the English Language" says about the meaning of "prevent:"
"... Prevent, hamper, hinder, impede refer to different degrees of stoppage of action or progress. To prevent is to stop something effectually by forestalling action and rendering it impossible: 'to prevent the sending of a message'..."
No cryptographic technology that I am aware of can fairly be said to render the denial of an act impossible.
Of course not, and we agree this much. That is why I wrote earlier that non-repudiation is not a "stronger" authentication or a long-lived one. In my view, a non-repudiation proof could be disqualifed by an authentication proof. Non-repudiation does NOT trump authentication -- which is what this original thread (First Monday article) proposed, based on some mythical "trusted systems". Regarding the word prevent, Merriam-Webster teaches that PREVENT implies taking advance measures against something possible or probable <measures taken to prevent leaks>. This is the first meaning -- after this comes ANTICIPATE and, at last, FORESTALL. So, while you say that Random House teaches that FORESTALL is the first meaning, I do not see as this as the rule. And, in this specific case it does not even make sense to use FORESTALL because there is nothing to be interrupted -- but it does make a lot of sense IMO to take advance measures against a probable or possible denial. So, non-repudiation is a service that take advance measures against a probable or possible denial of an act. In other words, PREVENTS the denial of an act. This is the standard meaning in cryptography applications. Maybe it is already similar or becomes similar to the meaning used by lawyers, or by banks. Good for them! OTOH, some lawyers and lawmakers are oftentimes the first ones to use the term "identifty theft" -- which simply is not a theft, it is impersonation. I hope we in crypto don't have to use "identity theft" as well. And, they can continue to use it. Cheers, Ed Gerck
On Mon, 16 Oct 2000, Ed Gerck wrote:
OTOH, some lawyers and lawmakers are oftentimes the first ones to use the term "identifty theft" -- which simply is not a theft, it is impersonation. I hope we in crypto don't have to use "identity theft" as well. And, they can continue to use it.
Speaking as a lawyer, one of "they,", they should not continue to use it. Identity theft might be accomplishable in some scenario, one in which I somehow induced amnesia in you, for example, but otherwise the use of the term to cover what you rightly point is simply impersonation, does a disservice to my profession as well as yours. As to "prevent," it seems to me that Random House has the better of Merriam-Webster here. Apparently what M-W really means in their first sense of the word is a combination, something like "anticipate and take measures to forestall or render impossible." Now, the anticipation may be brief, and the measures spontaneous, but that's what I gather they really wanted to say at M-W. If so, they're loading more on to "prevent" than it always has to carry. MacN
Oh and as to non-repudiation and lawyers throwing that term around loosely: Most lawyers would probably tell you that, for their purposes, whatever the parties *agree* to be non-repudiation *is* non-repudiation as between *them*. The hard cases are the ones where there's no agreement and the law must supply a default rule, or derive a rule from the conduct of the parties. Those are the instances you have in mind, I take it. In such cases, where "course of dealing" and "course of performance" between the parties sheds little or no light, the law often looks to "trade usage." To which the work of punks, among others, may be relevant. MacN
Mac Norton wrote:
Oh and as to non-repudiation and lawyers throwing that term around loosely: Most lawyers would probably tell you that, for their purposes, whatever the parties *agree* to be non-repudiation *is* non-repudiation as between *them*.
Yes.
The hard cases are the ones where there's no agreement and the law must supply a default rule, or derive a rule from the conduct of the parties. Those are the instances you have in mind, I take it. In such cases, where "course of dealing" and "course of performance" between the parties sheds little or no light, the law often looks to "trade usage." To which the work of punks, among others, may be relevant.
Yes. That is why it needs to be defined in technical terms, in order to avoid (but not forestall) overloading. From the previous discussion and hair-splitting on "prevent" I am inclined to use the definition of non-repudiation as "non-repudiation is a service that takes advance measures against a probable or possible denial of an act" if I want to be sloppy. If I want to be technically precise (but perhaps unavoidably obscure), I would continue to use "non-repudiation is the denial of a falsity." I am forwarding to you a comment by Tony Bartoletti, with the following ending: I don't think that it is worth debating whether toothpaste prevents, helps to prevent, serves to prevent, hampers, hinders, impedes or forestalls tooth decay. When theory meets the real world, some slippage will occur. and that is why I think such debates are interesting. We need to see the different sides of truth rather than believing that there is just one truth -- which is, of course, the one we have (invariably so, it seems) ;-) Cheers, Ed Gerck
Mac Norton said
Oh and as to non-repudiation and lawyers throwing that term around loosely: Most lawyers would probably tell you that, for their purposes, whatever the parties *agree* to be non-repudiation *is* non-repudiation as between *them*.
Ed Gerck said
Borrowing from a private comment from Bob Jueneman, whatever the technical community decides that non-repudiation means, it probably isn't what the legal community means. So be it.
Acknowledging the overwhelming victory of credit cards in B2C commerce, one could conclude that consumers prefer total wraparound repudiability to specific vendor warranties. Reading warranties takes so much time that the argument over definitions of non-repudation is academic. What's needed is a standard contract that emulates the protections provided by Visa and Mastercard --a virtual credit card. This would enable an unbundling of settlement services from "insurance" components. A diverse industry of payments and settlements providers, credit services, and risk underwriters would emerge. You need to achieve a plug-and-play environment to compete with banks and cc consortia, and equally bad "bundle propositions" emerging from alternative payments providers. SMBs and website operators are fed up with the cost of credit cards. Another industry is the webledger industry-- They would take immediate notice of such a contract, since any webledger can basically serve as a bank or settlement provider to its population of subscribers. For example, of the leading webledgers will soon announce an infrastructure for its users to submit intercompany transactions to each other; this makes the webledger a B2B host, and technically, enables any subscriber to offer settlement services to other subscribers. READ THIS: www.gldialtone.com/journalbus.htm In summary: what's missing from the payments environment isn't technology, but legal infrastructures, Todd
At 4:37 PM -0700 10/16/2000, Ed Gerck wrote:
Borrowing from a private comment from Bob Jueneman, whatever the technical community decides that non-repudiation means, it probably isn't what the legal community means. So be it. Certainly the legal profession uses ordinary English words to mean other than their ordinary meaning in a particular context, and so do other professions.
This is the nub of our argument. I believe the terms we use influence how our technology will be interpreted in a societal and legal context and we therefore have an obligation to be as clear as possible. This is particularly important with technology such as digital signatures and certs which may profoundly alter the way individuals interact with the economic system.
No cryptographic technology that I am aware of can fairly be said to render the denial of an act impossible.
Of course not, and we agree this much. That is why I wrote earlier that non-repudiation is not a "stronger" authentication or a long-lived one. In my view, a non-repudiation proof could be disqualifed by an authentication proof. Non-repudiation does NOT trump authentication -- which is what this original thread (First Monday article) proposed, based on some mythical "trusted systems".
To the extent we agree here, I would urge you to help insure that this message is crystal clear in all specs and documents whose content you can influence. And don't rely on which dictionary's definition of "protect" is correct.
OTOH, some lawyers and lawmakers are oftentimes the first ones to use the term "identifty theft" -- which simply is not a theft, it is impersonation. I hope we in crypto don't have to use "identity theft" as well. And, they can continue to use it.
The problem goes beyond simple impersonation in that the victims subsequently find it difficult to convince large institutions that they are who they say they are. My understanding is that the term comes from victims' statements that they felt as if their identities had been stolen. See http://www.consumer.gov/idtheft/. The question is relevant here, not as just another parallel question of semantics, but because exactly how the legal system treats "non-repudiation" can make the identity theft problem much better or much worse. For what it's worth, when Congress responded to this problem by passing the Identity Theft and Assumption Deterrence Act of 1998, it did not define "identity theft" as a new crime, but merely amended 18 U.S.C. ยง 1028 "Fraud and related activity in connection with identification documents and information." The act includes provisions that appear to protect private keys, though they are not explicitly mentioned, while biometrics are (see 1028(d)(3)(C)). Arnold Reinhold
"Arnold G. Reinhold" wrote:
To the extent we agree here, I would urge you to help insure that this message is crystal clear in all specs and documents whose content you can influence. And don't rely on which dictionary's definition of "protect" is correct.
Arnold, Yes. However, we live now in a post-modern society, where the emphasis is on local discourse and it is accepted that there are many truths and many ways of knowing. The cat is out of the bag and we need IMO to learn to cope with diversity rather than try to iron it out. Of course, there are many dictionaries and many languages and computer technology has not solved this problem -- in the contrary, we have maybe dozens of "computer languages" being born every year and a handful of them actually being used. So, if we look to the real world, what do we see? Do we see a uniform law rule, a uniform government and a uniform language? No, we see multiple relationships, multiple actors, heavy overload, intersubjective contexts. As Tony Bartoletti wrote, apologies for what seems a rant, but the "solid mathematical foundations" underlying digital signatures, "Qualified Certificates", unmistakable IDs, biometrics and so forth create in me a degree of "psychic and social backlash" as well. We create these instruments in the hope of ascertaining better measures of the constancy of authentication and identities. The central question that comes to mind is "to what degree we are artificially creating the constancy we intend these instruments to measure."
Ed Gerck wrote:
OTOH, some lawyers and lawmakers are oftentimes the first ones to use the term "identifty theft" -- which simply is not a theft, it is impersonation. I hope we in crypto don't have to use "identity theft" as well. And, they can continue to use it.
The problem goes beyond simple impersonation in that the victims subsequently find it difficult to convince large institutions that they are who they say they are. My understanding is that the term comes from victims' statements that they felt as if their identities had been stolen. See http://www.consumer.gov/idtheft/. The question is relevant here, not as just another parallel question of semantics, but because exactly how the legal system treats "non-repudiation" can make the identity theft problem much better or much worse.
No. The fact that people like to talk in dumbed down soundbites like "identity theft", instead of using well-established words like "impersonation", does not mean that any legally relevant conclusions can be drawn from the misuse of technical terms like "theft" in the soundbite. Otherwise, we seem to agree. Cheers, Ed Gerck
The problem goes beyond simple impersonation in that the victims subsequently find it difficult to convince large institutions that they are who they say they are. My understanding is that the term comes from victims' statements that they felt as if their identities had been stolen. See http://www.consumer.gov/idtheft/. The question is relevant here, not as just another parallel question of semantics, but because exactly how the legal system treats "non-repudiation" can make the identity theft problem much better or much worse.
No. The fact that people like to talk in dumbed down soundbites like "identity theft", instead of using well-established words like "impersonation", does not mean that any legally relevant conclusions can be drawn from the misuse of technical terms like "theft" in the soundbite.
Other choices?
Identity Theft
Identity Pollution
Identity Vandalism
Identity Assault
Identity Misappropriation
(Slander in the First Person :)
Would it matter if we substitute "reputation" for "identity". Is my identity
(to others) any different than the reputation with which it is associated?
Call it what you will. If institutions that once recognized me fail now
to do so, I have lost something-in-general.
Name that something-in-general.
Cheers!
___tony___
Tony Bartoletti 925-422-3881
At 11:21 AM -0700 10/17/2000, Ed Gerck wrote:
"Arnold G. Reinhold" wrote:
To the extent we agree here, I would urge you to help insure that this message is crystal clear in all specs and documents whose content you can influence. And don't rely on which dictionary's definition of "protect" is correct.
Arnold,
Yes. However, we live now in a post-modern society, where the emphasis is on local discourse and it is accepted that there are many truths and many ways of knowing. The cat is out of the bag and we need IMO to learn to cope with diversity rather than try to iron it out. Of course, there are many dictionaries and many languages and computer technology has not solved this problem -- in the contrary, we have maybe dozens of "computer languages" being born every year and a handful of them actually being used.
So, if we look to the real world, what do we see? Do we see a uniform law rule, a uniform government and a uniform language? No, we see multiple relationships, multiple actors, heavy overload, intersubjective contexts.
The legal and societal significance of this technology is open to debate, and will be decided differently in different places, based on local values, economic interests and raw political power. All I am asking is that the debate be informed by accurate statements of what this stuff can and cannot do.
As Tony Bartoletti wrote, apologies for what seems a rant, but the "solid mathematical foundations" underlying digital signatures, "Qualified Certificates", unmistakable IDs, biometrics and so forth create in me a degree of "psychic and social backlash" as well.
As well it should. There is a big difference between "can we do it?" and "should we do it?" One other point, and let me shift to upper case for this one: THERE ARE NO "SOLID MATHEMATICAL FOUNDATIONS" FOR ANY OF THIS STUFF!!!!! THE DIFFICULTY OF BREAKING PUBLIC KEY SYSTEMS HAS NEVER BEEN PROVEN MATHEMATICALLY. It is all hypothesis and empirical argument. A lone mathematician working in his attic could come up with an algorithm that would blow some or all of the existing systems out of the water. Who get to cover that financial risk?
We create these instruments in the hope of ascertaining better measures of the constancy of authentication and identities. The central question that comes to mind is "to what degree we are artificially creating the constancy we intend these instruments to measure."
Well said. Arnold Reinhold
"Arnold G. Reinhold" wrote:
At 11:21 AM -0700 10/17/2000, Ed Gerck wrote:
As Tony Bartoletti wrote, apologies for what seems a rant, but the "solid mathematical foundations" underlying digital signatures, "Qualified Certificates", unmistakable IDs, biometrics and so forth create in me a degree of "psychic and social backlash" as well.
As well it should. There is a big difference between "can we do it?" and "should we do it?"
One other point, and let me shift to upper case for this one: THERE ARE NO "SOLID MATHEMATICAL FOUNDATIONS" FOR ANY OF THIS STUFF!!!!! THE DIFFICULTY OF BREAKING PUBLIC KEY SYSTEMS HAS NEVER BEEN PROVEN MATHEMATICALLY.
Yes, that is why Tony's remark was somewhat tongue-in-cheek and used "solid mathematical foundations" within quotes.
It is all hypothesis and empirical argument. A lone mathematician working in his attic could come up with an algorithm that would blow some or all of the existing systems out of the water. Who get to cover that financial risk?
The buyer. CAs (read Verisign's CPS or any CA's CPS, or bank contracts and -- above all -- see the US UCC) are not responsible for producing correct results but just for using correct methods. Where "correct methods" are what others consider correct -- even if they are proved wrong later on by a one mathematician working in his attic.
We create these instruments in the hope of ascertaining better measures of the constancy of authentication and identities. The central question that comes to mind is "to what degree we are artificially creating the constancy we intend these instruments to measure."
Well said.
This paragraph was also Tony's contribution, not mine. It reflects a case I often make -- to what extent are we ironing out diversity and thus creating an artificial and useless model rather than a real-world model that would have real-world significance? "The emperor is nude", needs to be heard more often IMO, in e-commerce. Before, if possible, more of our economy and even lives depend on it. Cheers, Ed Gerck
At 10:23 AM -0700 10/18/2000, Ed Gerck wrote:
"Arnold G. Reinhold" wrote:
At 11:21 AM -0700 10/17/2000, Ed Gerck wrote:
As Tony Bartoletti wrote, apologies for what seems a rant, but the "solid mathematical foundations" underlying digital signatures, "Qualified Certificates", unmistakable IDs, biometrics and so forth create in me a degree of "psychic and social backlash" as well.
As well it should. There is a big difference between "can we do it?" and "should we do it?"
One other point, and let me shift to upper case for this one: THERE ARE NO "SOLID MATHEMATICAL FOUNDATIONS" FOR ANY OF THIS STUFF!!!!! THE DIFFICULTY OF BREAKING PUBLIC KEY SYSTEMS HAS NEVER BEEN PROVEN MATHEMATICALLY.
Yes, that is why Tony's remark was somewhat tongue-in-cheek and used "solid mathematical foundations" within quotes.
Eye twinkle doesn't come across in e-mail, I'm afraid. My apologies to Tony. This is obviously one of my hot buttons.
It is all hypothesis and empirical argument. A lone mathematician working in his attic could come up with an algorithm that would blow some or all of the existing systems out of the water. Who get to cover that financial risk?
The buyer. CAs (read Verisign's CPS or any CA's CPS, or bank contracts and -- above all -- see the US UCC) are not responsible for producing correct results but just for using correct methods. Where "correct methods" are what others consider correct -- even if they are proved wrong later on by a one mathematician working in his attic.
I'm not sure those contracts would stand up in court if there were massive public losses due to a collapse of the PKI. (Anyway CA CPS's stretch to notion of a "mutual agreement" pretty far. I purchase a $10 cert and am bound by over 100 pages of gobbldygook that only a handful of people on the planet can be expected to fully understand?) But I am less concerned with CA legal liability then with who is left holding the bag when a massive subversion of the banking system is perpetrated, and how big that could be. Arnold Reinhold
At 04:58 PM 10/19/00 -0400, Arnold G. Reinhold wrote:
Yes, that is why Tony's remark was somewhat tongue-in-cheek and used "solid mathematical foundations" within quotes.
Eye twinkle doesn't come across in e-mail, I'm afraid. My apologies to Tony. This is obviously one of my hot buttons.
No problem. I often employ a quoted "x" to convey "so-called x", a shortcut that can lead to misunderstandings.
It is all hypothesis and empirical argument. A lone mathematician working in his attic could come up with an algorithm that would blow some or all of the existing systems out of the water. Who get to cover that financial risk?
The buyer. CAs (read Verisign's CPS or any CA's CPS, or bank contracts and -- above all -- see the US UCC) are not responsible for producing correct results but just for using correct methods. Where "correct methods" are what others consider correct -- even if they are proved wrong later on by a one mathematician working in his attic.
I'm not sure those contracts would stand up in court if there were massive public losses due to a collapse of the PKI. (Anyway CA CPS's stretch to notion of a "mutual agreement" pretty far. I purchase a $10 cert and am bound by over 100 pages of gobbldygook that only a handful of people on the planet can be expected to fully understand?)
But I am less concerned with CA legal liability then with who is left holding the bag when a massive subversion of the banking system is perpetrated, and how big that could be.
I'll wager the taxpayer/consumer will foot the bill, one way or another.
Derivative to the Second Law of Thermodynamics, it is easier to destroy wealth
than it is to create it. So, on average, work/energy is required to create
or recreate wealth. The collapse of a future global PKI, or of the integrity
of banking transactions, would represent a huge shift from order into chaos,
a decoherence of identities and orderliness amounting to a huge destruction
of wealth. Recovery thus will require the recreation of wealth, in one form
or another. This will require a correspondingly huge input of work. So, who
does most of the work, in general? You know the answer ;)
___tony___
Tony Bartoletti 925-422-3881
"Arnold G. Reinhold" wrote:
Eye twinkle doesn't come across in e-mail, I'm afraid. My apologies to Tony. This is obviously one of my hot buttons.
Bullshit: ;-) or ;) or ;^) would have done just fine. >8^D -- ----------------------Kaos-Keraunos-Kybernetos--------------------------- + ^ + :Surveillance cameras|Passwords are like underwear. You don't /|\ \|/ :aren't security. A |share them, you don't hang them on your/\|/\ <--*-->:camera won't stop a |monitor, or under your keyboard, you \/|\/ /|\ :masked killer, but |don't email them, or put them on a web \|/ + v + :will violate privacy|site, and you must change them very often. --------_sunder_@_sunder_._net_------- http://www.sunder.net ------------
At 07:37 PM 10/16/00 -0400, Ed Gerck wrote:
Borrowing from a private comment from Bob Jueneman, whatever the technical community decides that non-repudiation means, it probably isn't what the legal community means. So be it.
For instance, the "acceptable" PK key length for non-refutability may have a legal defintion which is either liberal or conservative by e.g. cryptographic standards. Like the FBI's 12 coincidence (of topological feature) points on a fingerprint or N matches of polymorphic genes..
At 09:08 AM 10/11/00 -0400, Arnold G. Reinhold wrote:
My concern is that the vast majority of informed lay people, lawyers, judges, legislators, etc. will hear "non-repudiation" and hear "absolute proof." If you doubt this, read the breathless articles written recently about the new U.S. Electronic Signatures Act.
I think it would be more sensible to worry that lawyers and judges will hear "non-repudiation" and stop paying attention to anything else the speaker has to say about law or evidence, as the concept of "non-repudiation" as discussed by technologists is fundamentally incompatible with the rules of civil & criminal procedure, the Constitution, and the rules of evidence, at least in the United States. If it were possible to reduce questions about facts to the results of math problems, we wouldn't need courts at all. That suggests two things to me - (a) that's a very, very difficult problem to solve, and we certainly won't solve it by handwaving away important questions like security of keying material, and (b) even if it were solved, it's very likely the established legal system would declare it unsolved in order to protect its continued existence. -- Greg Broiles gbroiles@netbox.com
participants (12)
-
Arnold G. Reinhold -
Ben Laurie -
Bram Cohen -
David Honig -
David Jablon -
Ed Gerck -
Ed Gerck -
Greg Broiles -
Mac Norton -
sunder -
Todd Boyle -
Tony Bartoletti