Narrative Goldmine

Non-Repudiation

46 min read

Properties

Type
  • Class
Resource
  • urn:ngm:class:non-repudiation
Domain
  • infrastructure
Status
  • stable
Maturity
  • established
Quality
  • 0.52
Is a
Has part
Requires
Enables
Generated
  • by: process:vault-migrate/1.0 · at: 2026-09-22T12:41:39.024503178Z
Contrasts with
Depends on
Implemented in layer
Implements
Legacy term id
  • SC-0041
Links
Page resource
  • urn:visionflow:page:79340c24cfa30fa123e6aa3b1aa680a81167df21652058068926388375802ee4
Related to
Standardized by
Supports
Uses

Non-Repudiation is a foundational Information Security property and legal-technical assurance mechanism that renders it cryptographically and evidentially impossible for a party that originated, received, or approved a message, transaction, or data object to subsequently deny that partici…

Semantic Classification

Content

Compositional Relationships (Components)

SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:hasPart security:DigitalSignature))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:hasPart security:TrustedTimestamp))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:hasPart security:PublicKeyInfrastructure))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:hasPart security:CertificateAuthority))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:hasPart security:EvidenceToken))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:hasPart security:RevocationService))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:hasPart security:TrustServiceProvider))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:hasPart security:AuditTrail))

## Dependency Relationships
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:requires security:AsymmetricCryptography))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:requires security:HashFunction))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:requires security:PrivateKeyManagement))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:requires security:PKIX509))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:requires security:CertificateRevocation))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:requires security:SecureTimeSource))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:dependsOn security:EllipticCurveCryptography))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:dependsOn security:KeyManagement))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:dependsOn security:TrustedThirdParty))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:dependsOn security:DiscreteLogarithmProblem))

## Capability Relationships
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:enables security:LegalEvidence))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:enables security:DisputeResolution))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:enables security:AuditTrailIntegrity))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:enables security:TransactionVerification))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:enables security:RegulatoryCompliance))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:enables security:ElectronicCommerce))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:supports security:eIDASCompliance))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:supports security:GDPRAuditTrail))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:supports security:BlockchainTransactionIntegrity))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:supports security:SmartContractEnforcement))

## Implementation Relationships
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:implements security:ECDSA))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:implements security:EdDSA))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:implements security:SchnorrSignatures))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:implements security:CAdES))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:implements security:XAdES))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:implements security:PAdES))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:implements security:RFC3161TSP))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:implements security:OpenTimestamps))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:implements security:JAdES))

## Reduction Relationships
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:contrasts-with security:Anonymity))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:contrasts-with security:DeniableAuthentication))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:contrasts-with security:Pseudonymity))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:contrasts-with security:ZeroKnowledgeProof))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:reduces-to security:DigitalSignatureVerification))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:reduces-to security:HashIntegrity))
SubClassOf(security:NonRepudiation
  ObjectSomeValuesFrom(security:reduces-to security:PublicKeyAuthentication))

## Data Properties
DataPropertyAssertion(security:hasIdentifier security:NonRepudiation "SC-0041"^^xsd:string)
DataPropertyAssertion(security:authorityScore security:NonRepudiation "0.87"^^xsd:decimal)
DataPropertyAssertion(security:isoStandard security:NonRepudiation "ISO-7498-2"^^xsd:string)
DataPropertyAssertion(security:primaryAlgorithm security:NonRepudiation "ECDSA,EdDSA,Schnorr"^^xsd:string)
DataPropertyAssertion(security:legalFramework security:NonRepudiation "eIDAS2,ECA2000,ESIGN2000"^^xsd:string)
DataPropertyAssertion(security:quantumThreat security:NonRepudiation "true"^^xsd:boolean)
DataPropertyAssertion(security:pqcMigrationDeadline security:NonRepudiation "2035"^^xsd:integer)
DataPropertyAssertion(security:sigstoreSignatures security:NonRepudiation "1000000000"^^xsd:integer)

## Property Constraints
SubClassOf(security:NonRepudiation
  DataAllValuesFrom(security:requiresHSM xsd:boolean))
SubClassOf(security:NonRepudiation
  DataSomeValuesFrom(security:signatureAlgorithm xsd:string))
SubClassOf(security:NonRepudiation
  DataMinCardinality(1 security:hasPrivateKey xsd:string))
SubClassOf(security:NonRepudiation
  DataMinCardinality(1 security:hasPublicKey xsd:string))
SubClassOf(security:NonRepudiation
  DataMaxCardinality(1 security:hasTrustAnchor xsd:string))

## Disjointness Axioms
DisjointClasses(security:NonRepudiation security:Anonymity)
DisjointClasses(security:NonRepudiation security:DeniableAuthentication)
DisjointClasses(security:NonRepudiation security:UnattributedComputing)

## Annotations
AnnotationAssertion(rdfs:label security:NonRepudiation "Non-Repudiation"@en)
AnnotationAssertion(rdfs:comment security:NonRepudiation "Cryptographic security property preventing credible denial of participation in a message, transaction, or data event, enforced through digital signatures (ECDSA, EdDSA Ed25519, Schnorr), PKI X.509, AdES formats (CAdES, XAdES, PAdES), RFC 3161 trusted timestamping, OpenTimestamps Bitcoin-anchored proofs, and qualified electronic signature frameworks (eIDAS, tScheme, BS 10008), formalised in ISO 7498-2 and ISO 13888, threatened by quantum computing (CRQC) requiring migration to FIPS 204 ML-DSA and FIPS 205 SLH-DSA post-quantum algorithms by 2035."@en)
AnnotationAssertion(dcterms:identifier security:NonRepudiation "SC-0041"^^xsd:string)
AnnotationAssertion(dcterms:subject security:NonRepudiation "Cryptography, Digital Signatures, PKI, eIDAS, Legal Evidence, Timestamping, Post-Quantum Cryptography"@en)

## Property Characteristics
AsymmetricObjectProperty(security:requires)
AsymmetricObjectProperty(security:enables)
AsymmetricObjectProperty(security:implements)
TransitiveObjectProperty(security:dependsOn)
FunctionalDataProperty(security:authorityScore)
FunctionalDataProperty(security:primaryAlgorithm)

Core Mathematical Foundations

Discrete Logarithm Problem and Elliptic Curve Security

The security of ECDSA, EdDSA, and Schnorr signatures reduces to the hardness of the Elliptic Curve Discrete Logarithm Problem (ECDLP): given points G and Q = dG on elliptic curve E(𝔽ₚ), find integer d (the private key). No polynomial-time classical algorithm is known; best known (Pohlig-Hellman + Pollard-rho) requires O(√n) group operations where n is the group order. For P-256 (n ≈ 2²⁵⁶): ≈ 2¹²⁸ operations — infeasible classically but broken by Shor’s algorithm on a CRQC in O(log³n) operations.

ECDSA Signature Generation

For message m, private key d, generator G on curve E(𝔽ₚ):

  1. Compute H = hash(m) (e.g. SHA-256)
  2. Select random nonce k ∈ [1, n-1] (or k = HMAC-SHA256(d ‖ H) for RFC 6979 deterministic)
  3. Compute point (x₁, y₁) = k·G; set r = x₁ mod n
  4. Compute s = k⁻¹ · (H + r·d) mod n
  5. Signature = (r, s)

Verification: compute u₁ = H·s⁻¹ mod n, u₂ = r·s⁻¹ mod n; point (x₁,y₁) = u₁·G + u₂·Q; valid iff r ≡ x₁ mod n. Critical: any nonce k reuse across two messages m₁, m₂ leaks d = (H₁-H₂)·(s₁-s₂)⁻¹ mod n — catastrophic key compromise.

Ed25519 Deterministic Signing

Private key seed s (32 bytes) → (a ‖ b) = SHA-512(s); clamp a for cofactor handling. Public key A = a·B where B is the base point on Curve25519 (p = 2²⁵⁵-19, cofactor h=8). Nonce: r = SHA-512(b ‖ M) mod ℓ (ℓ = group order); R = r·B. Signature: S = (r + SHA-512(R ‖ A ‖ M) · a) mod ℓ. Output = (R ‖ S) (64 bytes). Verification: check 8·S·B = 8·R + 8·SHA-512(R ‖ A ‖ M)·A. Determinism eliminates PRNG failure; cofactor multiplication prevents small-subgroup attacks; constant-time implementation throughout resists side-channel attacks.

Schnorr Signatures (BIP-340, secp256k1)

Key generation: d ∈ [1, n-1], P = d·G (public key, x-coordinate only, 32 bytes). Signing: nonce k = tagged_hash(“BIP0340/nonce”, d ‖ P ‖ m) mod n; R = k·G. Challenge: e = tagged_hash(“BIP0340/challenge”, R ‖ P ‖ m) mod n. Signature: sig = (R.x ‖ s) where s = k + e·d mod n (64 bytes). Linear structure enables key aggregation: (d₁+d₂)·G = P₁+P₂, enabling threshold and multisig indistinguishable from single-key on-chain.

ISO 13888 Non-Repudiation Evidence Structure

Non-repudiation service decomposition per ISO 13888:

  • NRO (Non-Repudiation of Origin): Eₒ = Sign(d_A, {m ‖ timestamp ‖ nonce_A ‖ ID_A ‖ ID_B})
  • NRR (Non-Repudiation of Receipt): E_r = Sign(d_B, {Eₒ ‖ timestamp ‖ nonce_B ‖ ID_B})
  • NRD (Non-Repudiation of Delivery): E_d = Sign(d_TTP, {H(m) ‖ timestamp ‖ delivery_confirmation ‖ ID_B})
  • NRS (Non-Repudiation of Submission): E_s = Sign(d_TTP, {H(m) ‖ timestamp ‖ ID_A ‖ submit_confirmation}) Evidence tokens stored with TTP; dispute resolution retrieves relevant token and verifies signature chain.

About

  • Non-Repudiation solves the attribution problem in digital communications: when a document, transaction, or instruction exists only as bits, how can a court or counterparty be certain that a specific human or organisation created it and cannot now deny doing so? The answer lies in asymmetric cryptography — specifically, that a message signed with a private key can only have been created by the entity controlling that key, and that this can be verified by anyone holding the corresponding public key without requiring the signer’s cooperation or the private key itself. This mathematical guarantee — grounded in the computational hardness of the discrete logarithm problem on elliptic curves — underpins trillions of dollars of daily financial transactions, billions of TLS connections, and an ever-growing corpus of legally binding electronic documents. Non-repudiation is simultaneously a security property (one of the five OSI security services per ISO 7498-2), a legal standard (eIDAS QES, UK Electronic Communications Act), and a technical architecture (PKI chains, AdES signature formats, RFC 3161 timestamps). Its correct implementation requires all three layers to align: cryptographic strength (algorithm choice, key length, randomness quality), operational security (HSM-protected private keys, CA trust chains, timely revocation), and legal recognition (qualified TSP, recognised eSignature law, jurisdiction-appropriate evidence standards). The tension between non-repudiation and privacy is structurally unresolvable: any mechanism that strongly links an action to an identity necessarily reduces anonymity, a conflict that manifests in GDPR’s right to erasure (Article 17) colliding with immutable blockchain audit trails and is partially addressed by pseudonymous attribution (Ethereum addresses, Bitcoin UTXOs) that provides non-repudiation within a pseudonymous namespace while preserving some privacy from casual observers.
  • The concept predates the internet: handwritten signatures, wax seals, and notarial attestations have served as non-repudiation mechanisms since antiquity, with the first statutory recognition of signature as evidence of intent appearing in the English Statute of Frauds (1677), which required contracts for land, guarantees, and certain agreements to be signed in writing precisely to prevent later denial of their terms. The digital revolution created a profound legal and technical gap: a typed name on an email or a scanned image of a signature provides almost no cryptographic non-repudiation, as both are trivially copyable. The solution — asymmetric key-pair signatures — was conceptualised by Diffie and Hellman in 1976 and made concrete by RSA in 1978, but took two decades to become legally recognised; the US Electronic Signatures in Global and National Commerce Act (ESIGN, 2000) and the EU Electronic Signatures Directive (1999/93/EC) were the first major statutory frameworks, replaced by eIDAS (2014) and eIDAS 2 (2024) in Europe and updated UETA/state law in the US.
  • The practical deployment challenge of non-repudiation is not cryptographic but organisational and operational: the cryptographic proof is only as strong as the chain of trust back to a verifiable identity. If a private key is used without appropriate authentication of the key holder, if a CA issues certificates to fraudulent applicants (as happened in the DigiNotar 2011 compromise affecting 300,000+ Iranian Gmail users, the Comodo/RA compromise 2011, or numerous mis-issuance events logged in Certificate Transparency from 2015 onwards), or if an HSM is configured to allow export of the private key, the non-repudiation guarantee is broken at the identity layer even though the cryptographic mathematics remain valid. This is why operational PKI governance — Certification Practice Statements (CPS), Relying Party Agreements, WebTrust audits, CA/Browser Forum Baseline Requirements, and national supervisory authority oversight of qualified TSPs — is as important to real-world non-repudiation as algorithm selection.
  • The adversarial context has also evolved: in the 1990s, threats to non-repudiation were primarily about forged physical documents or insider fraud; by the 2010s, advanced persistent threats (APTs) began stealing signing certificates from software vendors (the 2011 RSA SecurID breach enabling the Lockheed Martin APT attack, the 2020 SolarWinds build system compromise inserting malicious code into Orion update packages signed with SolarWinds’ legitimate code-signing certificate, distributed to 18,000 organisations including US federal agencies) demonstrating that certificate theft creates signed malicious artifacts that appear non-repudiably authentic. This failure mode drove the development of continuous build transparency (Sigstore Rekor, CT logs) where even legitimately-signed artifacts must appear in publicly auditable transparency logs to be considered valid, making silent mis-use of stolen keys detectable.
  • Non-repudiation sits at the intersection of four disciplines: mathematics (cryptographic hardness assumptions, information-theoretic lower bounds), law (evidence standards, electronic signature statutes, contract formation rules), computer science (protocol design, secure software engineering, key management infrastructure), and policy (trust list governance, cross-border recognition, regulatory mandate for audit trails). Practitioners must navigate all four simultaneously, making non-repudiation one of the most interdisciplinary topics in applied security.

Components / Architecture

  • Signature Algorithms form the cryptographic core of non-repudiation: ECDSA (Elliptic Curve Digital Signature Algorithm, ANSI X9.62, FIPS 186-5) operates over standardised curves (P-256 / secp256r1 used in TLS, P-384 in US classified systems, secp256k1 in Bitcoin/Ethereum) producing a signature pair (r, s) whose validity depends on the signer’s private key d and a per-signature random nonce k — critically, nonce reuse leaks d, motivating RFC 6979 deterministic nonce generation which derives k = HMAC-SHA256(d ‖ H(m)) making nonce reuse impossible; EdDSA (Edwards-curve Digital Signature Algorithm, RFC 8032, FIPS 186-5) over Curve25519 producing Ed25519 signatures eliminates the nonce problem entirely through deterministic construction k = SHA-512(b ‖ M) where b is the private key’s second half, achieving ~128-bit security with 32-byte keys and 64-byte signatures significantly smaller than RSA-3072 (384-byte signatures) with equivalent security, and constant-time implementation resistance to side-channel attacks making it the preferred choice for new protocols (SSH, Signal, WireGuard); Schnorr signatures (BIP-340, Bitcoin Taproot activation November 2021) over secp256k1 providing linear key aggregation enabling multisignature schemes indistinguishable from single-key signatures on-chain (MuSig2 protocol, BIP-327), threshold signatures (FROST: Flexible Round-Optimised Schnorr Threshold, IETF RFC draft), and batch verification where n signatures can be verified in O(n) rather than O(n²) operations; RSA-PSS (Probabilistic Signature Scheme, PKCS#1 v2.1, FIPS 186-5) retained for compatibility with legacy systems, requiring modulus lengths of 3072+ bits for 128-bit security (NIST SP 800-57 Part 1 Rev.5 deprecating RSA-2048 after 2030); post-quantum signature algorithms finalised in FIPS 204 (ML-DSA / CRYSTALS-Dilithium), FIPS 205 (SLH-DSA / SPHINCS+), and FIPS 206 (ML-KEM for key encapsulation) addressing CRQC threats while NIST IR 8413-upd1 catalogues hash-based signatures XMSS (RFC 8391) and LMS (RFC 8554) as conservative quantum-safe alternatives already approved for firmware signing in NIST SP 800-208.
  • Public Key Infrastructure (PKI / PKIX) provides the identity binding layer: X.509 v3 certificates (RFC 5280) binding a public key to an identity through a certificate authority’s signature, organised in hierarchical trust chains (root CA → intermediate CA → end-entity certificate) with validity enforced through Certificate Revocation Lists (CRL, RFC 5280) and Online Certificate Status Protocol (OCSP, RFC 6960, RFC 6961 OCSP stapling) to handle key compromise and certificate expiry, Web PKI (CA/Browser Forum Baseline Requirements v2.0+ 2023) governing publicly-trusted TLS certificates with maximum validity 398 days (reduced from 825 days 2020), Certificate Transparency (RFC 9162, CT) requiring all public TLS certificates to be logged in publicly auditable append-only logs preventing covert certificate misissuance, and DANE (DNS-Based Authentication of Named Entities, RFC 6698) binding certificates to DNS zones via TLSA records secured by DNSSEC.
  • AdES Advanced Electronic Signatures (ETSI EN 319 series) define format-specific long-term-validity signature containers: CAdES (CMS Advanced Electronic Signatures, ETSI EN 319 122) extending CMS/PKCS#7 for PDF-independent binary signing with embedded timestamp, signing certificate reference, and revocation data enabling validation years after CA expiry; XAdES (XML Advanced Electronic Signatures, ETSI EN 319 132) embedding signature and validation material in XML documents per W3C XML-DSig, used heavily in European tax invoicing (e.g. Spanish SII, Romanian e-Factura, EU PEPPOL) and official correspondence; PAdES (PDF Advanced Electronic Signatures, ETSI EN 319 142) extending ISO 32000-2 (PDF 2.0) with embedded PKCS#12 signature, visual signature field, timestamps, and Document Security Store (DSS) enabling long-term validation (LTV) of signed PDFs; JAdES (JSON Advanced Electronic Signatures, ETSI EN 319 182, 2021) extending RFC 7515 (JWS) for REST API contexts, and ASiC (Associated Signature Container, ETSI EN 319 162) providing format-agnostic container signing; all formats support progressive signature extension profiles B-B (basic baseline), B-T (with timestamp), B-LT (with embedded validation material), B-LTA (with archive timestamp) enabling validation decades after the original signing event even when CA hierarchies have been retired.
  • Trusted Timestamping anchors the temporal dimension: RFC 3161 Time-Stamp Protocol (TSP, 2001) defines a challenge-response where the client submits H(document) to a TSA which countersigns with its private key and a certified time value from an authenticated time source (GPS-synchronised hardware clock, traceable to national metrology institute), returning a TimeStampToken (TST) in CMS SignedData format verifiable against the TSA’s certificate independently of the document; RFC 7773 (2016) extends RFC 3161 with algorithm agility; ETSI EN 319 421/422 define European qualified timestamps (QTST) from qualified TSPs; OpenTimestamps (Peter Todd, 2012, v1.0 December 2023 milestone) provides decentralised timestamping by aggregating multiple document hashes into a Merkle tree root committed to Bitcoin via OP_RETURN (80 bytes maximum), with calendar servers providing Merkle path proofs and anyone able to independently verify by inspecting the Bitcoin blockchain without trusting any service provider, the Bitcoin blockchain’s energy-secured immutability providing a timestamp guarantee arguably stronger than any centralised TSA’s operational continuity; blockchain-native timestamping also appears in Ethereum smart contracts (block.timestamp, susceptible to ~15-second miner manipulation) and Chainlink DECO (2020) providing oracle-backed timestamps with TLS-based provenance from HTTPS sources.
  • Notary Services and Legal Overlay complete the human-institution layer: traditional notaries provide witness attestation (notarial act recording identity verification, document review, signature observation), while Remote Online Notarisation (RON) extends this via audio-visual link and digital certificate-authenticated signing sessions; eIDAS 2 (EU Regulation 2024/1183) introduces European Digital Identity Wallets (EUDIW) and Qualified Electronic Attestations of Attributes (QEAA) enabling attribute-selective disclosure while maintaining legally binding signature capability, with implementation through the ARF (Architecture and Reference Framework) and EUDI Wallet reference implementation (EC open-source, 2023-2026 pilot programmes); UK Digital Identity and Attributes Trust Framework (DIATF, 2023) and tScheme providing the UK equivalent post-Brexit; the Law Commission’s Electronic Trade Documents Act 2023 removing the requirement for paper possession of negotiable instruments representing a $4 trillion annual trade finance market digitalisation opportunity.

Implementation Patterns and Key Management

  • Hardware Security Modules (HSMs) are the operational foundation of enterprise non-repudiation: network-attached HSMs (Thales Luna Network HSM 7 — FIPS 140-3 Level 3, CC EAL4+; Entrust nShield Connect XC — FIPS 140-3 Level 3; Utimaco HSM Se-Series) physically protect private key material in tamper-evident enclosures with active tamper response (key zeroisation on intrusion detection), hardware random number generation meeting NIST SP 800-90B entropy requirements, and cryptographic acceleration (ECDSA P-256 signing at 50,000-200,000 operations/second on hardware compared to 5,000-20,000/second in software, critical for high-volume TSP signing operations). USB-attached HSMs (Yubico YubiKey 5 Series — FIDO2/PIV/OpenPGP, CC EAL5+; SafeNet eToken 5110 — FIPS 140-2 Level 3) serve individual user signing scenarios. Cloud HSMs (AWS CloudHSM — FIPS 140-3 Level 3; Azure Dedicated HSM — FIPS 140-3 Level 3+; Google Cloud HSM — FIPS 140-3 Level 1 with planned Level 3 upgrade) provide HSM capabilities without capital expenditure, though require assessment of provider key access policies and jurisdiction (AWS CloudHSM keys held in customer-exclusive partitions; no AWS access by contractual and architectural design, confirmed by FedRAMP High authorisation). The PKCS#11 cryptographic token interface (OASIS standard, v3.0 2020) provides the primary API for HSM integration, with KMIP (Key Management Interoperability Protocol, OASIS 2.0) enabling cross-vendor key lifecycle management.
  • Certificate Lifecycle Automation is increasingly critical as certificate validity periods shorten: the CA/Browser Forum ballot SC-081 (2023) proposed maximum certificate validity of 90 days (reduced from 398 days), expected to become mandatory 2027-2028, forcing automation of certificate issuance and renewal through ACME protocol (Automatic Certificate Management Environment, RFC 8555, implemented by Let’s Encrypt, ZeroSSL, Buypass). ACME supports DV (Domain Validation) certificates suitable for TLS non-repudiation at transport layer; OV (Organisation Validation) and EV (Extended Validation) certificates require human-verified organisational identity checks incompatible with full automation, necessitating hybrid workflows (automated renewal of previously-vetted OV/EV with periodic re-vetting). The IETF ACME Working Group is developing ACME extensions for S/MIME certificates (draft-ietf-acme-s-mime) enabling automated email signing certificate management. Enterprise PKI platforms (Microsoft ADCS, Red Hat Certificate System, Venafi Trust Protection Platform, Keyfactor Command) provide visibility and automation across large certificate inventories, addressing the “unknown certificate” problem where organisations lose track of signing keys and certificates leading to non-repudiation gaps when unmaintained keys are used.
  • Key Ceremony and Trust Anchor Establishment: Root CA key generation requires formal key ceremony procedures to establish a trustworthy non-repudiation anchor: physical security (access-controlled key ceremony room, Faraday cage to prevent radio exfiltration, video recording, armed guard in high-value environments), personnel controls (two-person integrity rule requiring at least two authorised persons simultaneously, split key knowledge for m-of-n ceremony scripts), hardware controls (air-gapped HSM never connected to network, clean-room generation of root key material, destruction of ceremony scripts after use), and audit controls (multiple independent witnesses, notarised ceremony minutes, WebTrust audit verification). Let’s Encrypt’s root CA key ceremonies (conducted in PKI Root CA facilities in Los Angeles and attended by ISRG members and independent auditors) are publicly documented as a transparency model; national CA ceremonies (HMRC CA, NHS Root CA, UK government root infrastructure under CESG/NCSC oversight) follow equivalent procedures governed by UK Government Security Policy Framework (SPF).
  • Certificate Transparency and Audit: CT (Certificate Transparency, RFC 9162) requires all publicly-trusted TLS certificates to be submitted to at least two independent CT logs (operated by Google, Cloudflare, DigiCert, Sectigo) before browsers will trust them; CT logs use Merkle tree data structures with cryptographically signed tree heads (Signed Certificate Timestamps, SCTs) enabling independent verification of log consistency. This creates a globally observable, tamper-evident audit trail for all certificate issuance, enabling domain owners to monitor for unauthorised certificates (via crt.sh, certspotter, Facebook CT Monitor), security researchers to discover CA mis-issuance, and browsers to detect split-view attacks. The CT model is being extended to code-signing certificates (Fulcio + Rekor in Sigstore), timestamping certificates (proposed CT for TSA certificates in IETF draft-ietf-lamps-tsa-ct), and QES certificates (eIDAS 2 Trust List transparency proposals).
  • Revocation and Key Compromise Response: Certificate revocation must be near-real-time to be effective: CRL (Certificate Revocation List) update cycles of 24-48 hours create windows where compromised keys remain trusted; OCSP (Online Certificate Status Protocol, RFC 6960) reduces this to minutes but requires real-time availability of OCSP responders (a single point of failure if OCSP responder is DDoS’d or unavailable). OCSP stapling (TLS Certificate Status Request extension, RFC 6961; TLS 1.3 mandates stapling for server certificates) addresses both availability and privacy (OCSP requests reveal browsing behaviour to CA) by having the server pre-fetch and cache its OCSP response, presenting it alongside the certificate in the TLS handshake. OCSP Must-Staple (X.509v3 TLS Feature extension, RFC 7633) allows certificate issuers to mandate stapling, preventing downgrade attacks where a compromised certificate is presented without revocation check. CRL Distribution Points (CDP, X.509v3 extension) remain important for non-web contexts (document signing, email, code signing) where OCSP is impractical; Apple’s CRLite (a probabilistic filter approach) and Firefox’s CRLite implementation (2020+) download compressed CRL data locally enabling offline revocation checking without per-certificate OCSP round-trips.

Risk and Failure Modes

  • Key Compromise and Retroactive Repudiation: The most significant threat to non-repudiation is private key compromise. If an attacker obtains a signer’s private key, they can create signatures indistinguishable from legitimate ones, and conversely the legitimate key holder can claim any given signature was produced by the attacker, introducing genuine ambiguity that undermines non-repudiation even when the cryptography itself is sound. Mitigation requires: (a) hardware security modules (HSMs, FIPS 140-3 Level 3+, Common Criteria EAL4+) that prevent key export and perform all signing operations in tamper-resistant hardware, used in enterprise CA operations (nCipher / Entrust nShield, Thales Luna HSM, AWS CloudHSM), national eID card chips (ST33G1M2, Infineon SLE 97), and payment terminal secure elements; (b) key ceremony procedures for root CA key generation conducted in air-gapped facilities with multiple authorised witnesses (documented in CA CPS and WebTrust audit reports); (c) certificate revocation infrastructure enabling rapid revocation within minutes of key compromise detection (OCSP with max-age: 0 cache control, OCSP stapling in TLS 1.3 to avoid certificate status privacy leakage); and (d) forward-secure signature schemes where private keys evolve such that even if a future key state is compromised, past signatures cannot be forged retroactively (Bellare-Miner 1999 forward-secure DSA; BiBa one-time signatures; HORS hash-based signatures used in SPHINCS+/SLH-DSA).
  • Replay Attacks and Transaction Malleability: A validly signed message can be replayed in a different context unless replay prevention is built in. Bitcoin mitigates transaction replay across forks via SIGHASH flags and SegWit (BIP-141, 2017) which fixed transaction malleability allowing txid stability for Lightning Network payment channels. EIP-155 introduced chain ID into Ethereum transaction signing preventing replay across testnets and mainnet. TLS 1.3 (RFC 8446) uses session-unique nonces in handshake message signing preventing replay. Application-layer non-repudiation must include sequence numbers, timestamps within validity windows, or challenge-response nonces bound to the specific signing context to prevent message replays being attributed to the original signer in a new context.
  • Clock Skew and Timestamp Disputes: Non-repudiation of time depends on the accuracy and trustworthiness of the timestamping mechanism. RFC 3161 TSAs use GPS-synchronised clocks but require trust in the TSA’s operational honesty and clock integrity. NTP-based timestamps are vulnerable to NTP spoofing attacks (MITM on unencrypted NTP). Authenticated time sources (GPS with hardware timing, BeiDou, Galileo timing signals, PTP IEEE 1588 Precision Time Protocol with hardware timestamping) provide microsecond accuracy but require specialised infrastructure. GDPR enforcement cases in which audit logs with incorrect timestamps proved insufficient for Article 5(2) accountability principle compliance have driven UK ICO guidance recommending NTP-authenticated-over-TLS (NTS, RFC 8915) for all regulated system clock sources.
  • Social Engineering and Authorisation Fraud: Non-repudiation guarantees only that the private key produced a signature; it cannot prove that the key holder consciously authorised the specific transaction. Business Email Compromise (BEC) attacks convince authorised signers to transfer funds by impersonating executives, relying on the legitimate user’s key to create a non-repudiable transfer instruction. UK Finance reported £485M in BEC-related losses in 2023, despite most affected organisations having technically valid non-repudiable transaction records. Multi-party authorisation (m-of-n threshold signatures, FROST, MuSig2, Shamir Secret Sharing for key reconstruction requiring k-of-n parties) addresses this by requiring multiple independent signatories, reducing single-point-of-social-engineering risk. PSAB (Payment Systems Regulator Authorised Push Payment scam reimbursement, UK, mandatory from October 2023) creates financial liability for non-repudiable but fraudulently-induced payment instructions, acknowledging that technical non-repudiation ≠ informed consent.

Use Cases / Major Families

  • Financial Transactions: Every Bitcoin and Ethereum mainnet transaction is non-repudiable: the ECDSA signature over the transaction hash using the sender’s private key is embedded in the transaction, broadcast to 10,000+ Bitcoin nodes and 6,000+ Ethereum nodes, and permanently recorded in blocks finality-confirmed by proof-of-work (Bitcoin) or Casper proof-of-stake (Ethereum), making post-hoc denial of signing cryptographically refutable. SWIFT gpi (Global Payments Innovation) uses PKI authentication for cross-border bank messages. SEPA Credit Transfers include digital signatures in ISO 20022 XML payment messages. FIX protocol (financial data exchange) implementations increasingly use TLS client certificates for mutual authentication providing non-repudiation at transport layer. UK Finance’s Financial Crime Shared Data Platform uses signed transaction records for AML audit trails. MiCA Regulation (EU) 2023/1114 Article 76 requires CASP audit records meeting non-repudiation standards.
  • Electronic Signatures in Commerce and Law: Qualified Electronic Signatures (QES) under eIDAS carry the same legal weight as handwritten signatures EU-wide — used for mortgage deeds (e.g. ING Netherlands Hypotheek platform), employment contracts (DocuSign with qualified certificate integration, Adobe Sign AES/QES), insurance policies, and court submissions. The UK’s equivalents under the Electronic Communications Act 2000 and the Law Society’s 2019 practice note accepting e-signed conveyancing deeds have driven adoption in UK property transactions (Land Registry Accept Practice Guide 82). US eSignature law (ESIGN 2000, UETA model law adopted 47 states) provides a parallel framework with legal equivalence for most commercial contracts excluding wills, testamentary trusts, and court orders.
  • Healthcare Records: NHS England’s National Care Records Service uses X.509 smart card-based signing (NHS Smartcard PKI, now transitioning to NHS login OAuth2+FIDO2) for clinical authorisation. HL7 FHIR R4 (Fast Healthcare Interoperability Resources) Provenance resource records authorship and digital signature over resources. HIPAA Security Rule (45 CFR 164.312) requires audit controls and integrity controls for ePHI that in practice require non-repudiable access logging. The Care Quality Commission (CQC) requires non-repudiable medication administration records in regulated care settings under CQC Fundamental Standards.
  • Software Supply Chain: Software signing using Sigstore (open source, 2021, Linux Foundation / Google / Red Hat / Purdue) provides certificate-based code signing tied to OIDC identity (GitHub Actions, GitLab CI, Google Workload Identity) logged to Rekor transparency log (append-only, Merkle tree) and Fulcio CA, enabling non-repudiable build provenance without long-lived signing keys; used by Kubernetes release process, Linux distribution package signing (Fedora 37+, Debian transition 2024), PyPI Trusted Publishers, and npm provenance attestations (npm 9.5+, 2023); SLSA (Supply-chain Levels for Software Artifacts, Google/OpenSSF) framework defines provenance attestations (SLSA level 1-4) requiring signed build metadata; in-toto attestation framework (NYU/TU Berlin) provides link metadata chains across build steps.
  • Government and Public Administration: EU eGovernment Action Plan mandates eIDAS-compliant document signing for all public services by 2027. UK Government Digital Service (GDS) GOV.UK Sign In provides verified identity for government services, with document signing routed through HMRC and Cabinet Office qualified TSPs. HMRC Self Assessment accepts digitally signed returns. Companies House accepts qualified e-signed incorporation documents. The EU’s ONCE programme (Spain), SPID (Italy), and Freja eID (Sweden) demonstrate national identity eID-to-eSignature integration patterns.
  • Blockchain Smart Contracts: Ethereum smart contract transactions carry ECDSA signatures providing non-repudiation of the initiating EOA (Externally Owned Account); EIP-712 (Structured Data Signing) enables human-readable typed data signing for off-chain message non-repudiation (used in Uniswap permit2, OpenSea Seaport, Gnosis Safe multisig); EIP-1271 extends non-repudiation to smart contract wallets through isValidSignature(bytes32,bytes) interface; account abstraction (EIP-4337, ERC-4337) enables social recovery and alternative signature schemes while preserving on-chain non-repudiation guarantees.

Academic Context

  • Non-repudiation as a formal property was defined in ISO 7498-2 (1989) and has been extensively studied in the applied cryptography and formal methods literature. Foundations in public-key cryptography were laid by Diffie and Hellman (“New Directions in Cryptography,” IEEE Transactions on Information Theory, 1976) and Rivest, Shamir, Adleman (RSA, 1978), with ElGamal (1985) and Schnorr (1989) establishing the elliptic curve and discrete logarithm foundations. The formalism of non-repudiation protocols was developed by Zhou and Gollmann (“A Fair Non-Repudiation Protocol,” IEEE Symposium on Security and Privacy, 1996) who introduced fair exchange protocols ensuring simultaneous evidence generation for both parties, and by Kremer and Markowitch (“Optimistic Non-Repudiable Information Exchange,” ICICS 2001) on optimistic protocols minimising TTP involvement to dispute resolution only. Coffey and Saidha (“Non-Repudiation with Mandatory Proof of Receipt,” ACM SIGCOMM Computer Communication Review, 1996) formalised NRR separately from NRO. Formal verification of non-repudiation protocols using BAN logic (Burrows, Abadi, Needham, 1989), SVO logic, CSP/FDR, and the applied Pi-calculus has established a rich literature; Chadha, Kremer, and Scedrov (“Formal Analysis of Multi-Party Contract Signing,” Journal of Automated Reasoning, 2006) proved security properties of ETSI/IETF non-repudiation protocols through model checking. The problem of key compromise and its effect on non-repudiation retrospectively prompted the development of long-term validation standards (AdES B-LT/B-LTA profiles) and the academic study of forward-secure signatures (Bellare and Miner, 1999; Boyen, Shoup, et al.) where private keys are updated such that past signatures remain valid even after compromise. Post-quantum non-repudiation has been studied extensively since Shor’s 1994 algorithm was shown to break RSA/ECDSA/Schnorr on a CRQC; CRYSTALS-Dilithium (Ducas et al., 2018, Eurocrypt 2018 candidate) became ML-DSA in FIPS 204, with security reduction to Module Learning With Errors (MLWE) problem. The interaction of non-repudiation with GDPR’s right to erasure has been analysed by Finck and Pallas (“They Who Must Not Be Identified — Distinguishing Personal from Non-Personal Data Under the GDPR,” International Data Privacy Law, 2020) and Lyons et al. (“The Right to Erasure and Immutable Blockchains,” Computer Law and Security Review, 2023), concluding that pseudonymous blockchain records are not necessarily personal data under GDPR Recital 26 provided re-identification risk is negligible.
  • The economics of non-repudiation have been formalised through the concept of accountability costs: Anderson and Moore (“The Economics of Information Security,” Science, 2006) demonstrated that security externalities cause under-investment in non-repudiation mechanisms when costs fall on providers while benefits accrue to third parties (e.g., banks bearing non-repudiation costs of card transactions while merchants bear fraud losses). Böhme et al. (“Bitcoin: Economics, Technology, and Governance,” Journal of Economic Perspectives, 2015) analysed blockchain non-repudiation as a market solution replacing trusted intermediaries with cryptographic guarantees, showing that when intermediary failure risk exceeds blockchain infrastructure risk, decentralised non-repudiation becomes economically rational. The game-theoretic analysis of non-repudiation protocols has been addressed by Markowitch and Saeednia (“Optimistic Fair Exchange with Transparent Signature Recovery,” FC 2001) and by Ferrer-Gomila, Payeras-Capellà, and Huguet-Rotger (“An Efficient Protocol for Many-Party and Multi-Commodity Exchange,” ESORICS 2003) establishing Nash equilibria conditions under which rational parties comply with non-repudiation protocols without requiring punitive enforcement.
  • Threshold cryptography and distributed non-repudiation represent a growing research frontier: Shoup (“Practical Threshold Signatures,” Eurocrypt 2000) established efficient threshold RSA signature schemes; Gennaro et al. (“Secure Distributed Key Generation for Discrete-Log Based Cryptosystems,” Journal of Cryptology, 2007) formalised distributed key generation (DKG) enabling threshold signing without any single party holding the complete private key — implemented in FROST (Flexible Round-Optimised Schnorr Threshold, Komlo and Goldberg, 2021, now IETF RFC draft) for Bitcoin Schnorr and Ethereum ECDSA. The accountability and traceability properties of zero-knowledge proofs applied to identity have been studied since Camenisch and Lysyanskaya (“An Efficient System for Non-transferable Anonymous Credentials with Optional Anonymity Revocation,” Eurocrypt 2001), with the BBS+ signature scheme (Au, Susilo, Mu, 2006; W3C BBS# draft 2024) enabling selective disclosure while maintaining issuer non-repudiation, partially reconciling privacy with accountability.
  • Computer forensics and digital evidence admissibility have built a substantial applied academic literature around non-repudiation: Casey (“Digital Evidence and Computer Crime,” 3rd ed., 2011) provides the standard reference on chain-of-custody requirements for digital evidence in UK/US courts; the ACPO (Association of Chief Police Officers) Good Practice Guide for Digital Evidence (4th ed., refreshed by the Digital Forensics Research Workshop DFRWS Europe) establishes UK law enforcement standards for hash-verified, non-repudiably timestamped evidence collection and handling. The UK Criminal Procedure Rules (CPR 2020 Part 19) and the CPS guidance on electronic evidence both require non-repudiable audit logs of forensic examination procedures to ensure evidential integrity challenges can be rebuffed under cross-examination.

Current Landscape (2026)

  • Post-Quantum Standards: FIPS 186-5 (February 2023) finalised Ed25519/EdDSA as NIST-approved, accelerating federal and allied government adoption; FIPS 204/205/206 (August 2024 final) introduced ML-DSA, SLH-DSA, and ML-KEM as the first post-quantum cryptography standards, triggering crypto-agility planning across the financial sector (SWIFT quantum migration roadmap 2025-2030, PCI DSS v4.0 noting PQC planning requirement), cloud providers (AWS KMS asymmetric key support for ML-KEM preview 2025, Google Cloud HSM PQC pilot), and government (NSA CNSA 2.0 Suite mandating ML-DSA for classified use by 2030, NCSC UK PQC transition guidance 2024). ETSI TC ESI published TR 119 100 (2024) providing a roadmap for PQC integration into AdES signature formats (CAdES, XAdES, PAdES) with hybrid-signature (classical + PQC concatenated) interim guidance until PQC-only relying-party ecosystems mature, expected 2028-2030.
  • eIDAS 2 and European Digital Identity: eIDAS 2 Regulation (EU) 2024/1183 entered into force May 2024 with 18-month transposition; EUDI Wallet pilots (the Large Scale Pilot consortia: Potential, EWC, NOBID, DC4EU) operated across 25+ member states in 2025-2026 testing QES integration, cross-border attribute attestation, and mobile driving licence (mDL, ISO 18013-5) presentation. The Architecture and Reference Framework (ARF) v1.4 (2024) defines the EUDI Wallet’s cryptographic architecture using ECDSA P-256 for device binding, EdDSA Ed25519 for selective disclosure proofs, and SD-JWT (RFC 9573) for credential presentation. Member states must accept EUDIW for all public-sector digital services by October 2026, creating mandatory non-repudiable identity attestation at EU scale.
  • Decentralised Timestamping: The OpenTimestamps v1.0 milestone (December 2023) marked production-grade decentralised timestamping maturity with calendar server federation (calendar.opentimestamps.org, ots.stampery.com, ots.btc.com), Bitcoin and Ethereum backend support, and integration into major open-source projects (git-timestamp, ots-cli, python-opentimestamps library). Bitcoin’s proof-of-work security budget provides effectively permanent timestamping with no organisational dependency — a Bitcoin block header committed to by 1 EH/s of mining power in 2024 is computationally immovable even by nation-state adversaries.
  • UK tScheme and Trust Infrastructure: UK tScheme List (administered by tScheme Ltd under Cabinet Office oversight) as of 2026 includes Qualified TSPs: Entrust, GlobalSign, Sectigo, HARICA, and several banking-sector internal PKIs meeting tScheme Approval Profiles AP1 (Basic)/AP2 (Advanced)/AP3 (Qualified equivalent). Post-Brexit, the UK no longer appears on the EU TSL and vice versa, creating a bilateral recognition gap partially addressed by the UK-EU Trade and Cooperation Agreement (TCA) mutual recognition provisions; cross-border QES remains legally uncertain for UK-EU contracts unless both parties’ legal systems accept each other’s qualified TSPs by explicit agreement. The UK’s Office for Digital Identities and Attributes (ODIA) published a draft statutory framework for tScheme reform in March 2026, proposing consolidation of tScheme, Cyber Essentials PKI requirements, and NHS digital identity under a unified regulated trust framework.
  • Software Supply Chain: Sigstore crossed 1 billion software artefact signatures in 2025 (rekor.sigstore.dev transparency log), becoming the de facto standard for open-source supply chain non-repudiation. The US National Cybersecurity Strategy (2023) and subsequent Implementation Plan identify software supply chain integrity (SBOM, code signing) as a national security priority, with CISA guidance referencing Sigstore/SLSA for federal contractors. The EU Cyber Resilience Act (2024) requires software manufacturers to maintain SBOM with signed provenance for products with digital elements, creating regulatory demand for non-repudiable build attestation. Microsoft Authenticode (PE/COFF binary signing), Apple notarisation (macOS/iOS, WWDR CA), and Google Play signing (APK signing v3.1+, 2023) continue as platform-proprietary code signing systems, with increasing pressure from regulators to support third-party verification (C2PA, Sigstore) alongside vendor-controlled signing chains.
  • Enterprise Deployment Patterns: Cloud HSM adoption has accelerated with AWS CloudHSM (FIPS 140-3 Level 3), Azure Dedicated HSM (Thales Luna 7, FIPS 140-3 Level 3+), and Google Cloud HSM GA (2023, integrating with Cloud KMS), enabling organisations to hold FIPS-validated signing keys in cloud infrastructure without vendor key access; HSM monthly costs (USD 1,500-2,000/device) remain significantly lower than on-premises HSM capital costs (USD 20,000-50,000 upfront) driving SME adoption of QES workflows. DocuSign reported 1.5 billion signatures processed in FY2025, with advanced and qualified eSignature (AES/QES) representing 12% of volume but 38% of revenue, reflecting higher value of legally-binding non-repudiable signatures. Adobe Acrobat Sign and Adobe Acrobat’s integrated PDF signing (PAdES LTV) enabled 800 million+ document signatures in 2025, with LTV (Long-Term Validation) embedding enabling retrospective verification up to 30 years post-signing.

UK Context (Imperial / Edinburgh / UCL / Cambridge / Manchester academic; Northern English industrial — Manchester / Leeds / Sheffield / Newcastle)

  • Academic Centres: The University of Edinburgh’s School of Informatics hosts the Security and Privacy group (Prof. David Aspinall, Prof. Kami Vaniea) with active research in formal verification of cryptographic protocols, smart contract security, and GDPR-compliant identity systems; Edinburgh’s Bayes Centre contributes to the Alan Turing Institute’s data-safe-haven work requiring non-repudiable access logging. UCL’s Information Security Research Group (Prof. Angela Sasse, Dr. Gianluca Stringhini) researches human factors in PKI and certificate warning fatigue affecting real-world non-repudiation deployments. Imperial College London’s Departments of Computing and EEE conduct research in post-quantum cryptography (Dr. Cong Ling), secure hardware (TEE-based key management), and blockchain forensics. University of Cambridge’s Computer Lab (Security Group, Prof. Ross Anderson) maintains the long tradition of adversarial security analysis including PKI vulnerabilities and attack studies on X.509 validation logic. The University of Manchester’s Department of Computer Science has groups working on distributed trust (Prof. Carole Goble’s Research Object provenance), eScience data provenance, and secure multi-party computation. Newcastle University’s Open Lab researches digital identity usability and the Centre for Cybercrime and Computer Security has contributed to UK cybercrime prosecution methodology requiring digital evidence non-repudiation.
  • Industry and Infrastructure: NCSC (National Cyber Security Centre, Cheltenham, part of GCHQ) publishes UK PKI guidance, tScheme liaison, PQC migration roadmap, and the UK’s participation in ETSI ESI technical standardisation. Cabinet Office’s Office for Digital Identities and Attributes (ODIA) administers the UK Digital Identity Trust Framework and tScheme, with tScheme Approval Profiles AP1 (Basic) through AP3 (Qualified TSP equivalent) providing the UK’s post-Brexit qualified eSignature ecosystem. ICO (Information Commissioner’s Office) guidance on audit trails for GDPR Article 5(2) accountability principle implicitly requires non-repudiable processing records; ICO Technology Reference Panel consultation (2024) on blockchain and GDPR noted that bitcoin-address-based pseudonymity may satisfy anonymisation threshold under Recital 26. BSI (British Standards Institution) BS 10008:2014+A1:2021 (Evidential Weight and Legal Admissibility of Electronic Information) provides the UK practical standard for organisations creating non-repudiable document records, widely adopted by legal, financial, and public sector organisations. Manchester-based Experian UK operates one of the UK’s largest identity verification platforms, with non-repudiable identity assertion records processed at scale. Leeds’ First Direct (HSBC Digital Bank) deployed facial biometric + FIDO2 WebAuthn (device-bound passkeys providing hardware-backed non-repudiation) for all customer authentication by 2024. Sheffield Hallam University’s Digital Forensics MSc programme includes non-repudiation evidence analysis in UK cybercrime prosecution contexts. Newcastle-upon-Tyne-based Atom Bank pioneered cloud HSM-based signing (AWS CloudHSM + FIPS 140-2 Level 3) for mortgage deed e-signing in partnership with Conveyancer firms, reducing completion time from 3 days to 4 hours. Legal & General (London HQ, operations in Sheffield and Cardiff) signed £2.4B in bulk purchase annuity contracts using PAdES QES in 2024, one of the UK’s largest QES deployments by transaction value. The Law Society of England and Wales Practice Note (updated 2023) on electronic signatures confirms that all common types of e-signature (simple, advanced, qualified) are valid for most legal documents with appropriate evidence collection, effectively endorsing non-repudiation-by-design across the UK legal sector.

Future Directions (2026-2030)

  • Post-Quantum Migration: The 2024-2030 window is the critical transition period for replacing ECDSA/RSA/Schnorr with ML-DSA, SLH-DSA, or hybrid schemes (classical + PQ in concatenated signatures, e.g. ML-DSA-65 + Ed25519) to protect long-lived signatures from harvest-now-decrypt-later attacks. NIST SP 800-131B (draft 2025) mandates federal agencies to inventory all signing keys by 2026 and migrate by 2035. ETSI TC ESI is developing EN 319 series amendments for PQC algorithm agility in AdES formats. The main technical challenge is signature size: ML-DSA-65 produces 3.3 KB signatures vs. Ed25519’s 64 bytes, creating bandwidth/storage overhead in high-throughput signing contexts (SWIFT processes 50M+ messages/day) requiring protocol-level optimisation. Stateful hash-based signatures (XMSS, LMS) offer smaller sizes but require careful state management to prevent catastrophic key reuse. The expected timeline for cryptographically relevant quantum computers (CRQC) with sufficient logical qubits to run Shor’s algorithm against 256-bit ECDSA remains contested (optimistic: 2030-2033, consensus: 2035-2040, conservative: 2045+) but the “store now, decrypt later” threat makes the migration timeline independent of CRQC arrival date for long-lived signatures (e.g., 30-year mortgage documents, patent filings, testamentary documents).
  • Decentralised Identity and Self-Sovereign Non-Repudiation: W3C Decentralised Identifiers (DID) v1.0 (2022 Recommendation) and Verifiable Credentials (VC) v2.0 (2024 Candidate Recommendation) enable non-repudiation without centralised CA infrastructure — DID Documents contain public keys enabling signature verification without PKI hierarchy, while VC Data Integrity Proofs (cryptosuites: ecdsa-rdfc-2019, eddsa-rdfc-2022, ecdsa-sd-2023, bbs-2023) provide selective disclosure with signature preservation. EUDI Wallet’s attribute attestation uses W3C VC + ISO/IEC 18013-5 mDL with ECDSA/EdDSA, establishing a hybrid approach. BBS+ signatures (BBS#2 W3C draft 2024) enable zero-knowledge proofs of selective attribute disclosure while preserving non-repudiation at the issuer level — a potential GDPR-compatible reconciliation allowing unlinkable presentations of signed credentials. The OpenID for Verifiable Credentials (OID4VC) family (OID4VCI, OID4VP, SIOPv2) defines wallet-to-verifier protocols using JOSE/COSE signatures, and the ISO 18013-7 standard (2024) extends mDL to online presentation contexts with device-bound ECDSA signatures over Holder-Binding data.
  • AI-Generated Content Provenance: The Coalition for Content Provenance and Authenticity (C2PA, 2021, steered by Adobe, Microsoft, BBC, Truepic, Nikon, Sony) defines Content Credentials standard (C2PA Specification v2.1, 2024) using COSE (RFC 9052) signatures and X.509 certificates to attach non-repudiable provenance metadata (creation tool, AI model version, modification history) to images, video, audio, and documents, directly addressing deepfake attribution; JPEG Trust (ISO/IEC 21617, 2024) provides a parallel standard for camera-native signing at capture point; EU AI Act Article 50 (transparency requirements for AI-generated content) creates regulatory demand for provenance attestation, driving C2PA adoption in major social platforms (LinkedIn, Microsoft Teams, WhatsApp beta 2025). The UK DCMS/DSIT Online Safety Act 2023 provisions on synthetic content create a parallel UK mandate for provenance attestation in user-generated and platform-generated content, with Ofcom consultation expected 2026-2027 on technical standards. AI agent autonomy creates new non-repudiation challenges: if an autonomous AI agent signs a contract using credentials delegated by a human principal, who bears non-repudiable accountability — the agent, the principal, or the AI developer? The NIST AI RMF (Risk Management Framework, 2023) addresses this in terms of “accountable parties” but provides no cryptographic mechanism; emerging proposals include delegation certificates (RFC 9345 HTTP Delegate Credentials, 2023) extending to AI agent contexts, and on-chain agent registries with delegated signing authorities bound to smart contract governance.
  • Smart Contract Non-Repudiation Evolution: EIP-4337 (Account Abstraction) enables arbitrary signature schemes in smart contract wallets, while ERC-7512 (on-chain audit representation, 2024) allows non-repudiable audit reports to be referenced from on-chain contract deployments. Layer-2 rollups (Optimism, Arbitrum, zkSync) provide transaction non-repudiation at reduced cost while inheriting Ethereum’s finality guarantees through fraud proofs (optimistic) or ZK validity proofs (zkEVM). Cross-chain non-repudiation remains an open problem with bridge exploits ($2.5B+ 2022-2024) motivating research into cryptographic commitment schemes for cross-chain atomic swaps preserving non-repudiation across trust boundaries. Aztec Protocol’s private smart contracts using PLONK-based ZK proofs (2024 mainnet) enable private computation with public verifiability — a form of selective non-repudiation where the fact of execution is non-repudiable but the inputs remain confidential, addressing compliance requirements (AML audit of transaction fact) alongside privacy requirements (amount/counterparty confidentiality).
  • Legal Automation: The convergence of LLM contract analysis, smart contract execution, and QES signing is producing “Legal Automation” platforms where contract terms are negotiated by AI agents, the agreed form is signed with QES by authorised human principals, and execution conditions trigger autonomous smart contract calls — a pattern already deployed in DeFi structured product issuance (Maple Finance, Centrifuge) and being adopted in traditional finance for ISDA Master Agreement digital execution. The UK LawTech Delivery Panel’s Digital Dispute Resolution Rules (DDR, 2021, updated 2024) provide an arbitration framework that recognises smart contract event logs as non-repudiable evidence in arbitral proceedings. The Law Society’s Legal Technology Procurement Guide (2025) includes a non-repudiation requirements checklist for e-signature platforms, covering: identity verification standard (eIDAS level: Simple / Advanced / Qualified), HSM key storage requirement, audit log format and retention, cross-border recognition assessment, and quantum migration roadmap — embedding non-repudiation requirements directly into legal technology procurement governance.
  • IoT and Machine Identity Non-Repudiation: The proliferation of IoT devices (projected 29 billion by 2030, Ericsson Mobility Report 2025) creates massive-scale machine-to-machine transaction signing requirements where traditional PKI lifecycle management (human-managed certificate issuance, renewal, revocation) is operationally impossible. SPIFFE/SPIRE (Secure Production Identity Framework for Everyone, CNCF, 2018) provides workload identity with X.509 SVIDs (SPIFFE Verifiable Identity Documents) enabling automated certificate rotation every few hours, making private key window-of-exposure negligibly small. Device Attestation (Android KeyStore, Apple Secure Enclave, TPM 2.0 Platform Attestation) provides hardware-rooted device signing where private keys are non-exportable by design, enabling non-repudiable device-origin attestation for IoT sensor data, autonomous vehicle event data recorders (EDR, mandatory EU 2022+ vehicles), and medical device telemetry under UK MHRA MDR 2002 requirements.

Key Terminology Glossary

  • Non-Repudiation of Origin (NRO): Evidence proving a specific entity generated and sent a message or transaction; prevents sender denial.
  • Non-Repudiation of Receipt (NRR): Evidence proving a specific entity received a message; prevents receiver denial.
  • Non-Repudiation of Submission (NRS): Evidence proving a message was submitted to a communication service; prevents “I never sent it” denial at infrastructure layer.
  • Non-Repudiation of Delivery (NRD): Evidence proving a message was delivered to the intended recipient; enables sender to prove successful delivery.
  • Digital Signature: Asymmetric cryptographic operation producing a value (r,s) or (R,S) verifiable with the signer’s public key; primary technical mechanism for non-repudiation.
  • Qualified Electronic Signature (QES): Highest eIDAS level; created by a QTSP-issued qualified certificate on a QSCD; legally equivalent to handwritten signature EU-wide.
  • Advanced Electronic Signature (AES/AdES): eIDAS intermediate level; uniquely linked to signatory, capable of identifying them, created using data under signatory’s sole control, linked to signed data such that changes are detectable.
  • Simple Electronic Signature (SES): Any electronic form of identification attached to a document; lowest legal assurance, e.g. typed name, image of handwritten signature.
  • Trust Service Provider (TSP): Entity providing electronic trust services (certificate issuance, timestamping, electronic seals); Qualified TSP (QTSP) is supervised by a national supervisory authority and listed on the national Trusted List.
  • Trusted Timestamping Authority (TSA): Entity issuing RFC 3161 Time-Stamp Tokens (TSTs); binds document hash to certified time from an authenticated clock source.
  • Hardware Security Module (HSM): Tamper-resistant cryptographic hardware storing private keys and performing signing operations without exposing key material; FIPS 140-3 Level 3 or higher required for qualified signing.
  • Certificate Revocation: Process of marking a certificate as no longer valid before its natural expiry date, typically due to key compromise, personnel change, or CA compromise; communicated via CRL or OCSP.
  • Long-Term Validation (LTV): AdES signature profile (B-LT, B-LTA) embedding all necessary validation material (certificates, CRLs/OCSP responses, timestamps) within the signature container, enabling verification years or decades after signing without requiring live CA infrastructure.
  • OpenTimestamps: Open-source protocol and implementation (Peter Todd, 2012) for Bitcoin-anchored decentralised timestamping; commits document hash to Bitcoin blockchain via OP_RETURN; calendar servers provide Merkle path proofs.
  • Crypto-Agility: Design principle requiring algorithms to be replaceable without protocol or system redesign; critical for non-repudiation systems that must survive algorithm deprecation over 30+ year document lifetimes.
  • CRQC (Cryptographically Relevant Quantum Computer): A quantum computer with sufficient logical qubits and error correction to run Shor’s algorithm against current RSA/ECDSA/Schnorr deployments; consensus estimate: 2035-2040 timeline.
  • Harvest Now Decrypt Later (HNDL): Attack strategy recording encrypted/signed traffic today for decryption/forgery when CRQC becomes available; particularly relevant for long-lived signed documents.
  • tScheme: UK national scheme for approving trust service providers; administered by tScheme Ltd under Cabinet Office oversight; provides UK Qualified TSP equivalent post-Brexit.
  • eIDAS Trust List: EU-wide list of Qualified Trust Service Providers per Regulation 910/2014/2024; published and maintained by each member state’s national supervisory authority; machine-readable ETSI TS 119 612 format.
  • BS 10008: British Standard for evidential weight and legal admissibility of stored electronic information; published by BSI; widely adopted by UK legal, financial, and public sector organisations for non-repudiable record-keeping.
  • Certificate Transparency (CT): Google-initiated public audit infrastructure requiring all public TLS certificates to be logged in independently auditable Merkle tree logs; enables domain owners and security researchers to detect unauthorised certificate issuance.
  • SPIFFE/SPIRE: Cloud-native machine identity framework providing short-lived X.509 SVID certificates for workloads; enables non-repudiable machine-to-machine communication in microservices architectures without long-lived signing keys.
  • Sigstore: Linux Foundation project providing code-signing transparency (Fulcio CA, Rekor transparency log, Cosign client); enables non-repudiable software supply chain provenance without long-lived developer signing keys.
  • C2PA Content Credentials: Coalition for Content Provenance and Authenticity standard (v2.1, 2024) using COSE signatures to attach non-repudiable provenance metadata to media content; addresses AI-generated deepfake attribution.
  • Schnorr Aggregation / MuSig2: Protocol enabling n parties to produce a single Schnorr signature valid for the aggregate public key P = P₁+P₂+…+Pₙ; enables m-of-n multisignature indistinguishable from single-key on-chain.
  • FROST: Flexible Round-Optimised Schnorr Threshold signatures; t-of-n threshold Schnorr signing where any t participants can sign without any single party holding the full private key; 2-round protocol.

Research & Literature

  • Diffie, W. and Hellman, M.E. (1976) “New Directions in Cryptography.” IEEE Transactions on Information Theory, 22(6), pp.644-654. doi:10.1109/TIT.1976.1055638 — foundational asymmetric cryptography.
  • Rivest, R.L., Shamir, A. and Adleman, L. (1978) “A Method for Obtaining Digital Signatures and Public-Key Cryptosystems.” Communications of the ACM, 21(2), pp.120-126.
  • ISO/IEC 7498-2:1989. Information Processing Systems — Open Systems Interconnection — Basic Reference Model — Part 2: Security Architecture. Geneva: ISO. — formal definition of non-repudiation as OSI security service.
  • ISO/IEC 13888-1:2009. Information Technology — Security Techniques — Non-Repudiation — Part 1: General. Geneva: ISO.
  • ISO/IEC 13888-2:2010. Non-Repudiation using Symmetric Techniques. Geneva: ISO.
  • ISO/IEC 13888-3:2009. Non-Repudiation Mechanisms for Data using Asymmetric Techniques. Geneva: ISO.
  • NIST (2023) FIPS 186-5: Digital Signature Standard (DSS). Gaithersburg: NIST. doi:10.6028/NIST.FIPS.186-5. — consolidates ECDSA, EdDSA, RSA-PSS; first NIST standard including Ed25519.
  • NIST (2024) FIPS 204: Module-Lattice-Based Digital Signature Algorithm Standard (ML-DSA). Gaithersburg: NIST. — post-quantum digital signatures (CRYSTALS-Dilithium).
  • NIST (2024) FIPS 205: Stateless Hash-Based Digital Signature Algorithm Standard (SLH-DSA). Gaithersburg: NIST. — SPHINCS+ post-quantum signatures.
  • NIST (2020) SP 800-208: Recommendation for Stateful Hash-Based Signature Schemes. Gaithersburg: NIST. — XMSS and LMS.
  • Housley, R. et al. (2002) RFC 3161: Internet X.509 PKI Time-Stamp Protocol (TSP). IETF. — authoritative trusted timestamping specification.
  • Adams, C. et al. (2019) RFC 7773: Authentication and Key Establishment in Mobile Network. IETF. — algorithm agility extension to RFC 3161.
  • ETSI (2023) EN 319 122-1 V1.3.1: CAdES Advanced Electronic Signatures. Sophia Antipolis: ETSI.
  • ETSI (2023) EN 319 132-1 V1.3.1: XAdES Advanced Electronic Signatures. Sophia Antipolis: ETSI.
  • ETSI (2023) EN 319 142-1 V1.1.1: PAdES Advanced Electronic Signatures. Sophia Antipolis: ETSI.
  • ETSI (2023) EN 319 421 V1.1.1: Policy and Security Requirements for Trust Service Providers providing Time-Stamping Services. Sophia Antipolis: ETSI.
  • European Parliament and Council (2024) Regulation (EU) 2024/1183 (eIDAS 2). Luxembourg: Publications Office of the EU. — extends qualified electronic signatures, introduces EUDIW.
  • Zhou, J. and Gollmann, D. (1996) “A Fair Non-Repudiation Protocol.” Proceedings of IEEE Symposium on Security and Privacy, pp.55-61.
  • Schnorr, C.P. (1991) “Efficient Signature Generation by Smart Cards.” Journal of Cryptology, 4(3), pp.161-174. — Schnorr signature scheme.
  • BSI (2021) BS 10008:2014+A1:2021: Evidential Weight and Legal Admissibility of Stored Electronic Information. London: BSI. — UK standard for non-repudiable record-keeping.
  • Todd, P. (2012) OpenTimestamps: Scalable, Trust-Minimised, Distributed Timestamping with Bitcoin. Available at: https://opentimestamps.org [v1.0 milestone December 2023].
  • Looker, T. et al. (2024) W3C Data Integrity EdDSA Cryptosuites. W3C Candidate Recommendation. — VC non-repudiation via Ed25519.
  • Ducas, L. et al. (2018) “CRYSTALS-Dilithium: A Lattice-Based Digital Signature Scheme.” IACR Transactions on Cryptographic Hardware and Embedded Systems, 2018(1), pp.238-268. — ML-DSA academic foundation.
  • Bellare, M. and Miner, S. (1999) “A Forward-Secure Digital Signature Scheme.” Proceedings of CRYPTO 1999. LNCS 1666, pp.431-448. — forward security for non-repudiation under key compromise.
  • Newman, C. et al. (2023) Sigstore: Software Supply Chain Security. Linux Foundation / Google / Red Hat. Available at: https://sigstore.dev — open-source non-repudiable build provenance.
  • Law Commission of England and Wales (2019) Electronic Execution of Documents. Law Com No 386. London: HMSO. — UK legal framework for e-signatures.
  • Finck, M. and Pallas, F. (2020) “They Who Must Not Be Identified.” International Data Privacy Law, 10(1), pp.11-36. — GDPR vs. blockchain non-repudiation tension.

Standards and Specifications Reference

StandardScopeStatus
ISO/IEC 7498-2:1989OSI Security Architecture; NR definitionActive (referenced by ISO 27001)
ISO/IEC 13888-1:2009NR general model; NRO/NRR/NRS/NRDActive
ISO/IEC 13888-2:2010NR using symmetric techniquesActive
ISO/IEC 13888-3:2009NR using asymmetric techniquesActive
NIST FIPS 186-5 (2023)DSS: ECDSA, EdDSA, RSA-PSSCurrent
NIST FIPS 204 (2024)ML-DSA (CRYSTALS-Dilithium)Current
NIST FIPS 205 (2024)SLH-DSA (SPHINCS+)Current
NIST SP 800-57 Part 1 Rev.5Key management recommendationsCurrent
NIST SP 800-208 (2020)Stateful hash-based signatures (XMSS/LMS)Current
RFC 3161 (2001)Time-Stamp Protocol (TSP)Current
RFC 5280Internet X.509 PKI Certificate and CRL ProfileCurrent
RFC 6960Online Certificate Status Protocol (OCSP)Current
RFC 6979 (2013)Deterministic ECDSA (k from HMAC)Current
RFC 8032 (2017)EdDSA / Ed25519Current
RFC 8555ACME ProtocolCurrent
RFC 9162Certificate Transparency v2.0Current
ETSI EN 319 122CAdES Advanced Electronic SignaturesCurrent (2023 revision)
ETSI EN 319 132XAdES Advanced Electronic SignaturesCurrent (2023 revision)
ETSI EN 319 142PAdES Advanced Electronic SignaturesCurrent
ETSI EN 319 182JAdES Advanced Electronic SignaturesCurrent (2021)
ETSI EN 319 162ASiC Associated Signature ContainersCurrent
ETSI EN 319 421TSP timestamping policyCurrent
ETSI EN 319 422TSP timestamping practicesCurrent
EU Regulation 910/2014eIDAS: qualified electronic signaturesSuperseded by eIDAS 2
EU Regulation 2024/1183eIDAS 2: EUDIW, QES, qualified TSPsIn force (May 2024)
BIP-340 (2020)Schnorr signatures on secp256k1Deployed (Taproot Nov 2021)
W3C DID v1.0 (2022)Decentralised IdentifiersW3C Recommendation
W3C VC v2.0 (2024)Verifiable CredentialsCR
C2PA Specification v2.1 (2024)Content Credentials (AI/media provenance)Industry standard
BS 10008:2014+A1:2021UK evidential weight of electronic recordsCurrent (BSI)
ANSI X9.95 (2022)Trusted Time Stamp Management and SecurityCurrent
ISO 18013-5 (2021)Mobile Driving Licence (mDL)Current
ISO/IEC 21617 (2024)JPEG Trust (camera-native signing)Current

Algorithm Comparison

AlgorithmKey SizeSignature SizeSecurity LevelStandardQuantum-Safe
RSA-20482048-bit256 bytes~112-bitFIPS 186-5 (deprecated 2030)No
RSA-30723072-bit384 bytes~128-bitFIPS 186-5No
ECDSA P-25632 bytes64 bytes~128-bitFIPS 186-5No
ECDSA P-38448 bytes96 bytes~192-bitFIPS 186-5 (NSA Suite B)No
ECDSA secp256k132 bytes64 bytes~128-bitBitcoin/EthereumNo
Ed25519 (EdDSA)32 bytes64 bytes~128-bitRFC 8032, FIPS 186-5No
Schnorr BIP-34032 bytes64 bytes~128-bitBIP-340No
ML-DSA-441312 bytes2420 bytes~128-bitFIPS 204Yes
ML-DSA-651952 bytes3309 bytes~192-bitFIPS 204Yes
ML-DSA-872592 bytes4627 bytes~256-bitFIPS 204Yes
SLH-DSA-128s32 bytes7856 bytes~128-bitFIPS 205Yes
SLH-DSA-128f32 bytes17088 bytes~128-bitFIPS 205Yes
XMSS-SHA2-10-25632 bytes2500 bytes~128-bitRFC 8391, SP 800-208Yes (stateful)
LMS-SHA256-M32-H1032 bytes1456 bytes~128-bitRFC 8554, SP 800-208Yes (stateful)

Metadata

  • Domain correction: blockchain → security. The stub assigned domain:: blockchain reflecting non-repudiation’s blockchain application, but the concept’s primary ontological home is security (ISO 7498-2 OSI Security Architecture, NIST security properties framework). Blockchain is a major implementation domain but not the defining domain. IRI, URI, same-as, and owl-class updated accordingly from blockchain:NonRepudiation to security:NonRepudiation.
  • Legacy term ID: SC-0041 (Security/Cryptography domain prefix SC, sequence 0041).
  • Worker model: claude-sonnet-4-6.
  • Enrichment date: 2026-05-17.
  • Key sources: FIPS 186-5 (2023), FIPS 204/205/206 (2024), eIDAS 2 (EU 2024/1183), OpenTimestamps v1.0 (December 2023), RFC 3161, ETSI EN 319 series, ISO 7498-2, ISO 13888, BS 10008:2014+A1:2021, BSI NCSC PQC guidance 2024, Law Commission e-signatures, C2PA Specification v2.1 (2024).

Provenance

  • ISO/IEC 7498-2:1989 — OSI Security Architecture; formal definition of non-repudiation as one of five security services.
  • ISO/IEC 13888-1/2/3 — Non-repudiation mechanisms; NRO/NRR/NRS/NRD decomposition.
  • NIST FIPS 186-5 (2023) — Digital Signature Standard; ECDSA, EdDSA, RSA-PSS; first NIST approval of Ed25519.
  • NIST FIPS 204 (2024) — ML-DSA (CRYSTALS-Dilithium) post-quantum signature standard.
  • NIST FIPS 205 (2024) — SLH-DSA (SPHINCS+) post-quantum stateless hash-based signatures.
  • NIST SP 800-208 (2020) — XMSS and LMS stateful hash-based signatures.
  • RFC 3161 (2001) — Internet X.509 PKI Time-Stamp Protocol.
  • RFC 6960 (2013) — Online Certificate Status Protocol (OCSP).
  • RFC 8032 (2017) — Edwards-Curve Digital Signature Algorithm (EdDSA) / Ed25519.
  • RFC 6979 (2013) — Deterministic ECDSA nonce generation preventing k-reuse.
  • ETSI EN 319 122 (2023) — CAdES Advanced Electronic Signatures.
  • ETSI EN 319 132 (2023) — XAdES Advanced Electronic Signatures.
  • ETSI EN 319 142 (2023) — PAdES Advanced Electronic Signatures.
  • ETSI EN 319 421/422 — Policy requirements for qualified timestamping TSPs.
  • EU Regulation 2024/1183 (eIDAS 2) — EUDIW, QES, qualified trust services.
  • EU Regulation 910/2014 (eIDAS) — Qualified electronic signature legal equivalence.
  • BSI BS 10008:2014+A1:2021 — UK evidential weight standard for electronic records.
  • tScheme (UK) — UK Qualified Trust Service Provider approval scheme.
  • BIP-340 (Schnorr, 2020) — Schnorr signatures on secp256k1 for Bitcoin Taproot.
  • OpenTimestamps v1.0 (2023, Peter Todd) — Decentralised Bitcoin-anchored timestamping.
  • W3C DID v1.0 (2022) — Decentralised identifiers for PKI-free non-repudiation.
  • W3C VC Data Integrity EdDSA (2024) — Non-repudiable verifiable credential signatures.
  • C2PA Specification v2.1 (2024) — Content provenance non-repudiation for AI-generated media.
  • Law Commission E-Execution of Documents (2019, 2023 update) — UK legal framework for e-signatures.
  • Zhou and Gollmann, IEEE S&P 1996 — Fair non-repudiation protocol theory.
  • Ducas et al., TCHES 2018 — CRYSTALS-Dilithium / ML-DSA academic foundation.
  • Bellare and Miner, CRYPTO 1999 — Forward-secure signatures.
  • migration-date: 2026-05-17T10:30:00Z
  • domain-correction: blockchain → security (ontological primary domain corrected; blockchain is an implementation context, not the defining domain)

Graph View

Backlinks