Talk:Non-repudiation

Grammatical Awkwardness

We really need a better word for this concept. Although the use non-repudiation is widespread in the literature it is remarkably awkward and hard to use. By itself non-repudiation is a noun but what we often want is an adjective. Following usual English practice for turning a noun into an adjective we get non-repudiate-ability which is about as awkward and unpronounceable as it could be. I would be thankful for something that wouldn't make the listener grimace. — Preceding unsigned comment added by Hkc30 (talk • contribs) 04:56, 26 January 2021 (UTC)

Untitled

In today's global economy, where face-to-face agreements are often not possible, non-repudiation is becoming extremely important to commerce.

I don't think that's true. Credit card transactions are very repudiable, and that repudiability is an asset to the global economy.

Removing the statement - place it back with support if you want.

A chargeback is not repudiation. Repudiation is about saying "that charge was never made at all", not "that charge was not authorized". But adding back a crap comment into a crap article even if it was removed for crap reasons, doesn't amount to anything but more crap, so out it stays.

What's with the MASSIVE final paragraph? Did some female lawyer date an engineer and get dumped and decided to just stream-of-consciousness dump her angst on engineers in general? Someone needs to show that second paragraph how to be two paragraphs, and cut out the engineer-bashing. —Preceding unsigned comment added by 130.102.71.38 (talk) 04:26, 5 September 2007 (UTC)

Lets not stereotype. Could have been a female engineer and a mail lawyer. Or many other combination. But I agree it could use some cleanup. —Preceding unsigned comment added by Egret (talk • contribs) 21:12, 2 October 2007 (UTC)

15-Jan-2008: I got here from Public-key encryption and decided to take a whack at it. I added a real-world description using signatures on a contract, removed the confusing words about secrecy and what appeared to be guaranteed delivery (which is not non-repudiation), and deleted the final, rambling paragraph mentioned above. I pasted it below in case somebody cares. Chester320 (talk) 22:41, 15 January 2008 (UTC)

When engineers use the term ‘non-repudiation’ in an engineering sense, they mean that there is a high (and specifiable) degree of probability that the protocol can demonstrate a document or message was sent or received by a particular computer. Many extend this logic from the engineering domain into the legal domain, by arguing that if the system can demonstrate a message or document was sent or received, then it should be for the recipient to demonstrate it was not sent or received by them. The technical purpose is to bind users to specific actions in such a way that if they deny taking the action, they either demonstrate an intention to deceive, or they have been negligent in failing to secure the use of their private key adequately. In legal terms, the meaning of ‘non-repudiation’ is different from that used in the engineering sense. A manuscript signature can be repudiated for a number of reasons, including that the signature is a forgery, or that, although not a forgery, the signature was obtained as a result of unconscionable conduct by a party to a transaction, fraud instigated by a third party or undue influence exerted by a third party. It is important to ensure the technical meaning does not override the need to restrain the meaning within a legal context. Where engineers use the term, it should not be mistaken that they are using it in a legal context, despite their misunderstanding that the term, in their view, should have a legal meaning. The term ‘non-repudiation’ in the engineering sense for technical purposes is a property, probably attained through cryptographic methods, which demonstrates the message was sent from a particular computer.

Detailed Errors and Concept Confusions

This entire page is unreliable. It includes many errors in detail and mixes concepts up in inappropriate ways.

The page implies that there is some legal foundation to the concept of non-repudiation. There is not. Although the concept may have been attempted in some mid-1990s digsig laws, it has not really met with any success. In engineering, the concept is idealistic, not practical, relies on digital signing (itself problematic) and has not succeeded in practice. The result is babble.

The word non-repudation itself is an invention of engineers, and is at odds with legal practice.

According to traditional legal practice, a signature on a paper contract or memorandum may always be repudiated by the signatory.

Appropriate words are dispute, rebut, defence depending on the circumstances; repudiation is not a usual term in law. The sentence should say something like A signature can be disputed by establishing a number of defences, including forgery, conditionality, misrepresentation, wrong party, incapacity, mistake, unilateral change, lack of understanding, unfairness, etc. Ref: Stephen Mason (2007), _Electronic Signatures in Law_ §1.15.

"Non-repudiation is the concept of ensuring that a party in a dispute cannot repudiate, or refute the validity of a statement or contract."

This is apparently a statement concerning legal ramifications but the concept is an engineering one. In law, a party can always dispute, and is encouraged to do so. Ref. Repudiating non-repudiation.

2nd para is an engineer's description and is full of hope that disputing a signature is a simple thing and a thing that is addressable cryptographically. It is not.

"It is important to note that the legal burden of proof differs depending upon the repudiation reason."

This statement appears at odds with practice in law. The legal burden of proof traditionally rests with the relying party, to use a PKI term, and it shifts according to processes in law, not according to types of defence. Ref: Stephen Mason (2007), Electronic Signatures in Law, §1.4. The statement would appear to be similar to attempts made by banks attempting to shift burden by various methods, cloaked with legal blah blah.

Non-repudiation in digital security

...the cryptological meaning and application of non-repudiation shifts...

This implies there are two meanings. If there is a meaning outside cryptology, it should be referred and cited. If there is a meaning in law, case law or statutes should be cited. In any dispute, a word with two meanings is problematic.

A service that provides proof of the integrity and origin of data.

Proof might be useful in the mathematical domain, but the contract/law domain uses the word evidence. If we are sticking to the technical domain, then integrity might be plausible as per the following paragraph, but origin is not because it takes us into the world of parties.

An authentication that with high assurance can be asserted to be genuine.

This is confused. Anything can be asserted to be genuine, that's what the process is about. High assurance might make the claim more solid, but it is still subject to dispute.

Even with this safeguard, it is still possible to tamper with data in transit, either through a man-in-the-middle attack or phishing.

This implies that there is a protocol in mind, which has not been described. Data can be changed on a machine without any other parties, and without a technical networking protocol, so mentioning MITM/phishing is out of place. However, the para could be saved, once we are sure that the technical term non-repudiation has a useful meaning that includes integrity.

The most common method of asserting the digital origin of data is through digital certificates, a form of public key infrastructure to which digital signatures belong.

This is simply not true. Case law demonstrates that the most common form of origin of digital data is IP#s, statements found in documents (explicitly), implicit metadata, forensics, lack of dispute, etc. There have been a few cases in Europe using public key certificate signing, but common isn't exactly how anyone would describe it.

...with reasonable certainty, trusted to be from somebody who possesses the private key corresponding to the signing certificate.

This is the engineer's hope. In a world of phishing and virally-infected PCs, it is unreliable.

Trusted third parties (TTPs) The link to non-repudiation is vague.

TTPs are a concept in cryptography, yet the content is written as if in law. E.g:

The two most common TTPs are forensic analysts and notaries...

if we are talking about law, there might be courts, expert witnesses, witnesses, barristers & solicitors, notaries public and civil notaries, JPs, etc etc. But, it hardly makes sense to take a cryptographic nickname and apply it to a separate discipline. It is not as if the lawyers has been sitting around for thousands of years waiting for the mathematicians to tell them how to increase reliability, they have their methods already.

On the digital side, the only TTP is the repository for public key certificates.

In PKI, the certificate is its own evidence, the repository adds nothing unless it re-signs. OpenPGP key servers are not a TTP in any sense, anyone can do one, and people often stuff them with useless keys. The rest of that para is not about TTPs and should be struck.

The whole section on TTPs is out of place.

Iangfc (talk) 12:44, 23 July 2008 (UTC)

I generally agree with Iangfc's concerns. However, judging the prevalance of a technique by the number of court cases may not be fair; it is quite possible that transactions using poor techniques generate a greater proportion of court cases than good techniques. In terms of sheer numbers, I suspect the weak techniques used to allow individuals to electronicallly file national tax returns may be the most popular techniques. --Gerry Ashton (talk) 13:44, 23 July 2008 (UTC)

The legal burden of proof differs depending upon the repudiation reason. In the former scenario the burden of proof typically rests on the party claiming validity, while in the latter it shifts to the signatory claiming lack thereof.

This paragraph does not make sense. It seems to be claiming that in a dispute about the validity of a signature where one party claims forgery, the burden of proof lies with the party claiming that the signature is valid. But in a dispute where one party claims coercion, the burden of proof lies with the party claiming the signature is not valid. If that is what is meant, perhaps it could be clarified. However, even if clarified, it doesn't seem to make much sense, and I'm not sure what it has to do with non-repudiation. I came here looking for clarification of the difference between digital authentication (i. e., this message came from this sender because it is signed with the sender's public key) and non-repudiation, which as far as I can tell means the same thing (the sender can't claim not to have sent the message because it is signed with the sender's public key). Cburkitt (talk) 21:48, 26 April 2010 (UTC)

I agree with Cburkitt's reading of the statement, and agree the wording could be better. I think there is nothing obvious about where the burden of proof falls in various situations, and a citation is required to resolve this, so I have added a {{fact}} template.

As for non-repudiation, wording is critical. The phrase used by Cburkitt, "digital authentication", is not usually used in publications on this topic. In the absence of discussion in the literature, and possibly have it come up in some court of appeals cases, it is hard to decide what the phrase means. A message might contain, for example, a PKA signature with a certificate from a recognized certificate authority. Nevertheless, the purported signatory could repudiate the message for many reasons. For example, the purported signatory might claim that the message differs significantly from what appeared on the screen when the purported signatory clicked an "I agree" button. Jc3s5h (talk) 22:56, 26 April 2010 (UTC)

This artical only addresses the issue of non-repudiation of a document/file sent from one user to another (sender/recipient). It does not address the content of that document and non-repudiation of individual data content elements. This is particularly important when data withing the document is authored by multiple people. —Preceding unsigned comment added by Nathanlake (talk • contribs) 16:06, 14 June 2010 (UTC)

Repudiation as a desirable feature

Without citing sources for now, I'll mention that there's a recognized use for repudiation (and therefore repudiability) in computer systems: the need to repudiate buggy or insecure code once a superior version has been introduced. This means both non-repudiability and repudiability are potentially valuable in the same machine.

A corollary here is that the repudiation of an inferior code object must itself be non-repudiable so that a bad actor can't induce a system to resume using code that has known vulnerabilities. This introduces the concept of irreversibility (used here in a different sense than the "reversibility" of most bulk/two-way cryptographic algorithms). Once a system is informed that a code object has been repudiated, it should be impractical to make the system forget that it has been so informed.

A new section addressing these points would be useful, but I don't have the time or the domain knowledge to do justice to it. 2603:3024:182A:6200:5C95:966F:647:F4B5 (talk) 21:58, 6 August 2018 (UTC)

You're talking about support for updating broken code, which should not be confused with repudiation. Repudiation is also distinct from the sort of rollback attack you note. See a range of related topics at https://theupdateframework.io/overview/ Repudiation would be demonstrating that you didn't create some bad code which has been tied to your name, but distributed maliciously by someone else. To protect users, the code should come with non-repudiable evidence of who provided the code, e.g. via digital signatures combined with good identity proofing, software bill-of-materials, and the like. That way honorable providers can build a good reputation, and malware distributors will have a harder time. ★NealMcB★ (talk) 21:05, 31 October 2022 (UTC)

Non-repudiation and MACs

Generally, MACs are not said to provide non-repudiation. See e.g.

• Message_authentication_code#Security: "For the same reason, MACs do not provide the property of non-repudiation offered by signatures specifically in the case of a network-wide shared secret key: any user who can verify a MAC is also capable of generating MACs for other messages."
• https://crypto.stackexchange.com/questions/66225/message-authentication-vs-entity-authentication

This article says otherwise: Non-repudiation#In_digital_security: "Common methods to provide non-repudiation in the context of digital communications or storage are Message Authentication Codes (MAC), useful when the communicating parties have arranged to use a shared secret that they both possess, [...]"

Mebuege (talk) 18:56, 19 September 2020 (UTC)