Remote ATtestation procedureS D. Condrey Internet-Draft Writerslogic Inc Intended status: Standards Track 7 February 2026 Expires: 11 August 2026 Evidence Revocation and Status Protocol for Proof of Process draft-condrey-rats-witnessd-revocation-00 Abstract This document specifies mechanisms for revoking and updating Evidence status in the witnessd Proof of Process framework. It defines how authors can mark Evidence as superseded or revoked, how device key compromise is handled, and how Verifiers can efficiently check Evidence validity. The specification also defines an External Verifier Registry protocol that enables Relying Parties to discover trusted Verifiers and obtain federated verification services. About This Document This note is to be removed before publishing as an RFC. This is a companion document to draft-condrey-rats-pop, which defines the core Proof of Process evidence framework. This document addresses Evidence lifecycle management after initial generation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 11 August 2026. Condrey Expires 11 August 2026 [Page 1] Internet-Draft witnessd Revocation February 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 2. Evidence Status Model . . . . . . . . . . . . . . . . . . . . 3 2.1. Status Values . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Status Update Structure . . . . . . . . . . . . . . . . . 4 3. Revocation Mechanisms . . . . . . . . . . . . . . . . . . . . 5 3.1. Author-Initiated Revocation . . . . . . . . . . . . . . . 5 3.2. Key Compromise Handling . . . . . . . . . . . . . . . . . 5 3.3. Revocation Distribution . . . . . . . . . . . . . . . . . 5 4. External Verifier Registry . . . . . . . . . . . . . . . . . 6 4.1. Verifier Discovery . . . . . . . . . . . . . . . . . . . 6 4.2. Federated Verification . . . . . . . . . . . . . . . . . 6 4.3. Verifier Accountability . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5.1. Revocation Freshness . . . . . . . . . . . . . . . . . . 8 5.2. Revocation Service Availability . . . . . . . . . . . . . 8 5.3. Revocation Privacy . . . . . . . . . . . . . . . . . . . 8 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 6.1. Verifier Tracking Prevention . . . . . . . . . . . . . . 9 6.2. Metadata Minimization . . . . . . . . . . . . . . . . . . 9 6.3. Anonymous Verification Mode . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Condrey Expires 11 August 2026 [Page 2] Internet-Draft witnessd Revocation February 2026 1. Introduction The Proof of Process (PoP) specification [I-D.condrey-rats-pop] defines how Attesters generate Evidence during document authorship. However, Evidence is not immutable once generated. Authors may need to: * Mark old Evidence as superseded by newer Evidence * Revoke Evidence if it was generated in error or under duress * Update Evidence status after device key compromise * Correct declarations or metadata errors This document defines protocols for Evidence status management and revocation, as well as a Verifier registry enabling federated verification services. 1.1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Evidence Status Model 2.1. Status Values Evidence packets may have the following status values: active: Evidence is current and valid. This is the default status for newly generated Evidence. superseded: Evidence has been replaced by a newer Evidence packet. The superseding packet-id is recorded. Superseded Evidence remains verifiable but should not be considered current. revoked: Evidence has been explicitly revoked by the author. Revoked Evidence should not be trusted. A revocation reason is recorded. suspended: Evidence is temporarily suspended pending investigation or dispute resolution. May transition to active, revoked, or remain suspended. Condrey Expires 11 August 2026 [Page 3] Internet-Draft witnessd Revocation February 2026 expired: Evidence has exceeded its validity period (if one was declared). Expired Evidence may still be verifiable for historical purposes but should not be considered current. 2.2. Status Update Structure Status updates are CBOR-encoded structures signed by the original Evidence author. The following CDDL defines the status update format: status-update = { packet-id: bstr, ; Evidence packet being updated new-status: status-code, reason: reason-code, ? superseded-by: bstr, ; For superseded status ? explanation: tstr, ; Optional human-readable text timestamp: time, signature: bstr ; Author signature over update } status-code = &( active: 0, superseded: 1, revoked: 2, suspended: 3, expired: 4 ) reason-code = &( unspecified: 0, key-compromise: 1, content-error: 2, metadata-error: 3, generated-in-error: 4, duress: 5, newer-version: 6, validity-expired: 7 ) Status transitions MUST follow these rules: * active MAY transition to any other status * superseded is terminal (no further transitions) * revoked is terminal (no further transitions) * suspended MAY transition to active or revoked Condrey Expires 11 August 2026 [Page 4] Internet-Draft witnessd Revocation February 2026 * expired MAY transition to revoked only The signature MUST be created using the same key that signed the original Evidence packet. If the original key is compromised, the key compromise protocol in Section 3.2 applies. 3. Revocation Mechanisms 3.1. Author-Initiated Revocation Authors may revoke their own Evidence by publishing a signed revocation statement. The statement includes: * packet-id of the revoked Evidence * Revocation reason code * Optional explanatory text * Timestamp of revocation * Author signature (using same key that signed Evidence) 3.2. Key Compromise Handling When a device signing key is compromised, all Evidence signed by that key may be affected. The key compromise protocol: 1. Author generates new device key 2. Author publishes key compromise notice (signed by new key + optional secondary authentication) 3. Notice specifies compromise window (earliest and latest possible compromise times) 4. Evidence within compromise window is marked as suspicious 5. Evidence outside window may be re-endorsed with new key 3.3. Revocation Distribution Revocation information may be distributed through: * Well-known URI: /.well-known/witnessd-revocations * Revocation list embedded in Attestation Results Condrey Expires 11 August 2026 [Page 5] Internet-Draft witnessd Revocation February 2026 * Push notifications to subscribed Verifiers * Blockchain or transparency log publication 4. External Verifier Registry This section defines a protocol for discovering trusted Verifiers and obtaining federated verification services. 4.1. Verifier Discovery Organizations may publish their trusted Verifiers at: /.well-known/witnessd-verifiers This endpoint returns a signed JSON document listing: * Trusted Verifier identities and endpoints * Verifier certificates * Supported appraisal policies * Service level agreements 4.2. Federated Verification Federated verification enables Relying Parties in one organization to accept Attestation Results from Verifiers in another organization. The protocol operates as follows: 1. Relying Party receives Evidence packet from an author 2. Relying Party queries its organization's trusted Verifier list 3. If the author's organization has a trusted Verifier, the Relying Party forwards the Evidence to that Verifier 4. The remote Verifier appraises the Evidence and returns an Attestation Result 5. The Attestation Result is signed by the remote Verifier and includes the Verifier's identity for accountability 6. The Relying Party validates the Attestation Result signature against the trusted Verifier list Condrey Expires 11 August 2026 [Page 6] Internet-Draft witnessd Revocation February 2026 Trust delegation allows organizations to designate other Verifiers as authoritative for specific author domains. Delegation statements are signed by the delegating organization and published in the Verifier registry. Attestation Results from federated Verifiers MUST include: * Original Evidence packet-id * Verifier identity and organization * Appraisal policy applied * Timestamp of verification * Result validity period 4.3. Verifier Accountability Verifiers MUST maintain audit logs of all appraisal operations. Audit logs include: * Timestamp of each appraisal request * Evidence packet-id appraised * Appraisal policy applied * Result issued (without sensitive details) * Requesting party identifier (if authenticated) Audit logs MUST be retained for a minimum of 7 years to support legal and compliance requirements. Logs SHOULD be stored in append-only format to prevent tampering. Misbehavior reporting enables Relying Parties to report Verifiers that issue inconsistent or incorrect Attestation Results: 1. Relying Party detects inconsistency (e.g., same Evidence receives conflicting results from same Verifier) 2. Relying Party submits misbehavior report to registry operator 3. Registry operator investigates and may revoke Verifier listing 4. Misbehavior reports are published for transparency Condrey Expires 11 August 2026 [Page 7] Internet-Draft witnessd Revocation February 2026 Organizations MAY implement reputation scoring for Verifiers based on consistency, availability, and misbehavior history. Reputation scores are advisory and do not replace explicit trust decisions. 5. Security Considerations 5.1. Revocation Freshness Verifiers MUST check revocation status using fresh data. Cached revocation lists have a maximum validity period (RECOMMENDED: 24 hours for general use, 1 hour for high-security contexts). 5.2. Revocation Service Availability Verifiers MUST handle revocation service unavailability gracefully. Two modes are defined: Hard-fail mode: If revocation status cannot be determined, the Verifier MUST reject the Evidence as unverifiable. This mode is RECOMMENDED for high-security contexts where accepting potentially revoked Evidence poses significant risk. Soft-fail mode: If revocation status cannot be determined, the Verifier MAY accept the Evidence with a warning flag indicating revocation status is unknown. The Attestation Result MUST clearly indicate this condition. This mode is acceptable for lower-risk contexts where availability is prioritized. Verifiers SHOULD implement the following availability measures: * Cache revocation lists with appropriate TTL * Support multiple revocation distribution endpoints * Implement exponential backoff for failed queries * Monitor revocation service health proactively Relying Parties MUST be informed of the Verifier's failure mode and MAY override the default based on their risk tolerance. 5.3. Revocation Privacy Revocation queries may reveal which Evidence packets a Verifier is checking, potentially leaking information about document verification patterns. The following mitigations apply: Condrey Expires 11 August 2026 [Page 8] Internet-Draft witnessd Revocation February 2026 * Verifiers SHOULD download complete revocation lists rather than querying individual packet-ids to prevent query correlation * Revocation services MUST NOT log individual query patterns in a way that enables tracking specific Verifier behavior * Batch queries SHOULD be supported to allow Verifiers to check multiple packet-ids in a single request, reducing metadata leakage For high-privacy deployments, Verifiers MAY use Private Information Retrieval (PIR) techniques to query revocation status without revealing which packet-id is being checked. PIR support is OPTIONAL and deployment-specific. Revocation lists MUST NOT include information beyond what is necessary for status determination. Specifically, revocation reasons are available only to authenticated parties with a legitimate need to know. 6. Privacy Considerations This section addresses privacy implications of Evidence status management and Verifier registry operations. 6.1. Verifier Tracking Prevention Verifiers process Evidence from multiple authors and may accumulate significant metadata about verification patterns. To prevent misuse: * Verifiers MUST NOT correlate verification requests across different Relying Parties without explicit consent * Verification logs MUST be purged of personally identifiable information after the retention period expires * Verifiers MUST NOT share verification metadata with third parties except as required by law 6.2. Metadata Minimization Status updates and revocation statements contain metadata that could be privacy-sensitive. Implementations MUST: * Include only the minimum metadata necessary for status determination * Avoid including IP addresses, device identifiers, or location data in status update structures Condrey Expires 11 August 2026 [Page 9] Internet-Draft witnessd Revocation February 2026 * Use opaque packet-ids that do not encode author identity 6.3. Anonymous Verification Mode For privacy-sensitive contexts, Verifiers MAY support anonymous verification where: * Relying Party identity is not required for verification * No verification logs are retained * Rate limiting is applied to prevent abuse Anonymous verification provides weaker accountability guarantees and is not suitable for all deployment contexts. Verifiers MUST clearly document whether anonymous mode is supported. 7. IANA Considerations This document requests registration of the following well-known URIs: * URI suffix: witnessd-revocations * URI suffix: witnessd-verifiers Change controller: IETF Specification document: [this document] 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . 8.2. Informative References Condrey Expires 11 August 2026 [Page 10] Internet-Draft witnessd Revocation February 2026 [I-D.condrey-rats-pop] Condrey, D., "Proof of Process: An Evidence Framework for Digital Authorship Attestation", Work in Progress, Internet-Draft, draft-condrey-rats-pop, . Author's Address David Condrey Writerslogic Inc United States Email: david@writerslogic.com Condrey Expires 11 August 2026 [Page 11]