Senses

non-repudiation service · SynAc

TERM

non-repudiation service

A security service that provide protection against false denial of involvement in an association (especially a communication association that transfers data). (See: repudiation, time stamp.)

Updated

Jan 06, 2026

Senses

1 (I)

A security service that provide protection against false denial of involvement in an association (especially a communication association that transfers data). (See: repudiation, time stamp.) Tutorial: Two separate types of denial are possible an entity can deny that it sent a data object, or it can deny that it received a data object and, therefore, two separate types of non repudiation service are possible. (See: non repudiation with proof of origin, non repudiation with proof of receipt.)

A security service that provide protection against false denial of involvement in an association (especially a communication association that transfers data). (See: repudiation, time stamp.)

Tutorial: Two separate types of denial are possible -- an entity can deny that it sent a data object, or it can deny that it received a data object -- and, therefore, two separate types of non-repudiation service are possible. (See: non-repudiation with proof of origin, non-repudiation with proof of receipt.)

IETF RFC 4949 (Internet Security Glossary)

Bibliography

IETF RFC 4949 (Internet Security Glossary)
Accessed Jan 06, 2026Quoted
RFC 4949 — Internet Security Glossary (Version 2)
https://www.rfc-editor.org/rfc/rfc4949.txt
RFC 4949 is published by the IETF Trust and marked as "Distribution of this memo is unlimited". Verify IETF Trust copyright/licensing terms for reuse.
Source: IETF RFC 4949 (rfc-editor.org).

2 (D)

"Assurance [that] the sender of data is provided with proof of delivery and the recipient is provided with proof of the sender's identity, so neither can later deny having processed the data." [C4009] Deprecated Definition: IDOCs SHOULD NOT use definition 2 because it bundles two security services non repudiation with proof of origin, and non repudiation with proof of receipt that can be provided independently of each other. Usage: IDOCs SHOULD distinguish between the technical aspects and the legal aspects of a non repudiation service: "Technical non repudiation": Refers to the assurance a relying party has that if a public key is used to validate a digital signature, then that signature had to have been made by the corresponding private signature key. [SP32] "Legal non repudiation": Refers to how well possession or control of the private signature key can be established. [SP32] Tutorial: Non repudiation service does not prevent an entity from repudiating a communication. Instead, the service provides evidence that can be stored and later presented to a third party to resolve disputes that arise if and when a communication is repudiated by one of the entities involved. Ford describes the six phases of a complete non repudiation service and uses "critical action" to refer to the act of communication that is the subject of the service [For94, For97]: . Phase 1: Phase 2: Phase 3: Phase 4: Phase 5: . Phase 6: Request Generate Transfer Verify Retain . Resolve Service Evidence Evidence Evidence Evidence . Dispute . Service Critical Evidence Evidence Archive . Evidence Request = Action = Stored = Is = Evidence . Is Is Made Occurs For Later Tested In Case . Verified and Use | ^ Critical . ^ Evidence v | Action Is . | Is + + Repudiated . | Generated |Verifiable Evidence| ... . + + + Phase / Explanation 1. Request service: Before the critical action, the service requester asks, either implicitly or explicitly, to have evidence of the action be generated. 2. Generate evidence: When the critical action occurs, evidence is generated by a process involving the potential repudiator and possibly also a trusted third party. 3. Transfer evidence: The evidence is transferred to the requester or stored by a third party, for later use (if needed). 4. Verify evidence: The entity that holds the evidence tests it to be sure that it will suffice if a dispute arises. 5. Retain evidence: The evidence is retained for possible future retrieval and use. 6. Resolve dispute: In this phase, which occurs only if the critical action is repudiated, the evidence is retrieved from storage, presented, and verified to resolve the dispute.

Deprecated Definition: IDOCs SHOULD NOT use definition 2 because it bundles two security services -- non-repudiation with proof of origin, and non-repudiation with proof of receipt -- that can be provided independently of each other.

Usage: IDOCs SHOULD distinguish between the technical aspects and the legal aspects of a non-repudiation service:

"Technical non-repudiation": Refers to the assurance a relying party has that if a public key is used to validate a digital signature, then that signature had to have been made by the corresponding private signature key. [SP32]
"Legal non-repudiation": Refers to how well possession or control of the private signature key can be established. [SP32]

Tutorial: Non-repudiation service does not prevent an entity from repudiating a communication. Instead, the service provides evidence that can be stored and later presented to a third party to resolve disputes that arise if and when a communication is repudiated by one of the entities involved.

Ford describes the six phases of a complete non-repudiation service and uses "critical action" to refer to the act of communication that is the subject of the service [For94, For97]:

-------- -------- -------- -------- -------- . -------- Phase 1: Phase 2: Phase 3: Phase 4: Phase 5: . Phase 6: Request Generate Transfer Verify Retain . Resolve Service Evidence Evidence Evidence Evidence . Dispute -------- -------- -------- -------- -------- . --------

Service Critical Evidence Evidence Archive . Evidence Request => Action => Stored => Is => Evidence . Is Is Made Occurs For Later Tested In Case . Verified and Use | ^ Critical . ^ Evidence v | Action Is . | Is +-------------------+ Repudiated . | Generated |Verifiable Evidence|------> ... . ----+ +-------------------+

Phase / Explanation

Request service: Before the critical action, the service requester asks, either implicitly or explicitly, to have evidence of the action be generated.
Generate evidence: When the critical action occurs, evidence is generated by a process involving the potential repudiator and possibly also a trusted third party.
Transfer evidence: The evidence is transferred to the requester or stored by a third party, for later use (if needed).
Verify evidence: The entity that holds the evidence tests it to be sure that it will suffice if a dispute arises.
Retain evidence: The evidence is retained for possible future retrieval and use.
Resolve dispute: In this phase, which occurs only if the critical action is repudiated, the evidence is retrieved from storage, presented, and verified to resolve the dispute.