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.)

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.)

"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|------> ... . ----+ +-------------------+

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.