Remote ATtestation procedureS D. Condrey Internet-Draft Writerslogic Inc Intended status: Standards Track 7 February 2026 Expires: 11 August 2026 Trust Anchor Bootstrap Protocol for Proof of Process draft-condrey-rats-witnessd-enrollment-00 Abstract This document specifies a trust anchor bootstrap protocol for the witnessd Proof of Process framework. The protocol defines how new devices enter the witnessd ecosystem, how device keys are provisioned and verified, and how Verifiers discover and validate device trust anchors. Three enrollment modes are defined: self-sovereign mode for individual users, organizational mode for enterprise deployments, and public registry mode for federated trust ecosystems. 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 the bootstrapping problem: how do Verifiers know which device keys to trust? 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 Enrollment 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. Enrollment Modes . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Self-Sovereign Mode . . . . . . . . . . . . . . . . . . . 3 2.2. Organizational Mode . . . . . . . . . . . . . . . . . . . 4 2.2.1. Well-Known URI for Device Discovery . . . . . . . . . 4 2.3. Public Registry Mode . . . . . . . . . . . . . . . . . . 4 3. Device Enrollment Protocol . . . . . . . . . . . . . . . . . 5 3.1. Enrollment Request . . . . . . . . . . . . . . . . . . . 5 3.2. Challenge-Response Flow . . . . . . . . . . . . . . . . . 5 3.3. Certificate Issuance . . . . . . . . . . . . . . . . . . 6 4. Trust Anchor Discovery . . . . . . . . . . . . . . . . . . . 7 4.1. Discovery Mechanisms . . . . . . . . . . . . . . . . . . 7 4.2. Caching Policy . . . . . . . . . . . . . . . . . . . . . 7 4.3. Revocation Checking Integration . . . . . . . . . . . . . 8 5. Key Lifecycle Management . . . . . . . . . . . . . . . . . . 8 5.1. Key Rotation . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Device Migration . . . . . . . . . . . . . . . . . . . . 9 5.3. Key Compromise Response . . . . . . . . . . . . . . . . . 9 5.4. Certificate Renewal . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Compromise Impact Analysis . . . . . . . . . . . . . . . 11 6.3. Mitigation Requirements . . . . . . . . . . . . . . . . . 11 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 7.1. Device Identifier Privacy . . . . . . . . . . . . . . . . 12 7.2. Enrollment Metadata Minimization . . . . . . . . . . . . 12 7.3. Registry Privacy Modes . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 13 Condrey Expires 11 August 2026 [Page 2] Internet-Draft witnessd Enrollment February 2026 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The Proof of Process (PoP) specification [I-D.condrey-rats-pop] defines how Attesters generate Evidence during document authorship. Evidence packets are signed with device keys, but the core specification does not define how these keys are provisioned or how Verifiers establish trust in them. This document addresses the trust anchor bootstrap problem by defining: * Device enrollment protocols for provisioning signing keys * Trust anchor discovery mechanisms for Verifiers * Multiple enrollment modes for different deployment scenarios * Key lifecycle management including rotation and migration 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. Enrollment Modes 2.1. Self-Sovereign Mode In self-sovereign mode, users generate their own device keys and manually provide trust anchors to Verifiers they wish to work with. This mode provides maximum privacy but requires out-of-band trust establishment. Workflow: 1. Device generates key pair in secure hardware (if available) 2. Device exports public key and self-signed certificate 3. User manually provides public key to Verifier (via secure channel) 4. Verifier stores trust anchor associated with user identity Condrey Expires 11 August 2026 [Page 3] Internet-Draft witnessd Enrollment February 2026 Use cases: Individual authors, privacy-conscious users, testing environments. 2.2. Organizational Mode In organizational mode, device keys are signed by an organization's Certificate Authority (CA). The organization publishes its CA certificate, and Verifiers trust devices whose keys chain to the organization's CA. Workflow: 1. Organization establishes CA infrastructure 2. Organization publishes CA certificate at well-known location 3. Device generates key pair and creates certificate signing request 4. Organization signs device certificate (may require proof of device identity) 5. Device stores signed certificate 6. Verifiers validate device certificates against organization CA Use cases: Enterprises, academic institutions, publishing houses. 2.2.1. Well-Known URI for Device Discovery Organizations SHOULD publish device trust information at: /.well-known/witnessd-devices This endpoint returns a signed JSON document listing: * Organization CA certificate chain * Supported enrollment methods * Device certificate validation policy * Contact information for enrollment requests 2.3. Public Registry Mode In public registry mode, devices register with a public discovery service, similar to ACME for TLS certificates. This enables federated trust without requiring prior relationship establishment. Condrey Expires 11 August 2026 [Page 4] Internet-Draft witnessd Enrollment February 2026 Workflow: 1. Device generates key pair 2. Device proves control of user identifier (email, domain, etc.) 3. Registry issues device certificate bound to user identifier 4. Registry publishes certificate in transparency log 5. Verifiers query registry to validate device certificates Use cases: Open ecosystems, cross-organization verification, consumer applications. 3. Device Enrollment Protocol The device enrollment protocol establishes trust between a new device and the enrollment authority. The protocol uses a challenge-response flow to verify device identity and key possession. 3.1. Enrollment Request Devices initiate enrollment by submitting a request containing: enrollment-request = { device-public-key: bstr, ; Device's public key (COSE_Key) user-identifier: tstr, ; Email, domain, or opaque ID enrollment-mode: mode-type, ? device-attestation: bstr, ; TPM/Secure Enclave attestation ? proof-of-possession: bstr, ; Signature over challenge nonce: bstr, ; Freshness nonce timestamp: time } mode-type = &( self-sovereign: 0, organizational: 1, public-registry: 2 ) 3.2. Challenge-Response Flow For organizational and public registry modes, the enrollment authority issues a challenge: 1. Device submits initial enrollment request Condrey Expires 11 August 2026 [Page 5] Internet-Draft witnessd Enrollment February 2026 2. Authority returns challenge (random nonce + user verification requirement) 3. Device signs challenge with private key (proof of possession) 4. User completes verification (email link, domain TXT record, etc.) 5. Device submits signed challenge and verification proof 6. Authority validates and issues device certificate enrollment-challenge = { challenge-nonce: bstr, verification-method: verification-type, ? verification-uri: tstr, ; For email/web verification expires: time } verification-type = &( email-link: 0, domain-txt: 1, organizational-approval: 2, device-attestation-only: 3 ) enrollment-response = { challenge-nonce: bstr, challenge-signature: bstr, ; Signed by device private key verification-token: tstr, ; From email/domain verification timestamp: time } 3.3. Certificate Issuance Upon successful verification, the authority issues a device certificate: Condrey Expires 11 August 2026 [Page 6] Internet-Draft witnessd Enrollment February 2026 device-certificate = { device-id: bstr, ; Unique device identifier public-key: bstr, ; COSE_Key user-identifier: tstr, issuer: tstr, ; Authority identifier issued-at: time, expires-at: time, ? constraints: [* constraint], signature: bstr ; Authority signature } constraint = &( max-evidence-per-day: uint, allowed-document-types: [* tstr], geographic-restriction: tstr ) Certificates MUST be valid for no more than 1 year. Devices MUST re- enroll before certificate expiration. 4. Trust Anchor Discovery Verifiers must discover and maintain trust anchors for device certificate validation. This section defines discovery mechanisms and caching policies. 4.1. Discovery Mechanisms Verifiers discover trust anchors through: Well-known URI: Query /.well-known/witnessd-devices at the organization's domain to retrieve CA certificates and enrollment policies. Public Registry: Query the public registry service for device certificates bound to user identifiers. The registry provides certificate chains and revocation status. Out-of-band provisioning: For self-sovereign mode, trust anchors are manually configured by the Verifier operator. 4.2. Caching Policy Verifiers SHOULD cache trust anchors to reduce latency and network load. Caching policies: * CA certificates: Cache for up to 24 hours or until the next-update field indicates refresh is needed Condrey Expires 11 August 2026 [Page 7] Internet-Draft witnessd Enrollment February 2026 * Device certificates: Cache for the certificate validity period minus a safety margin (RECOMMENDED: 1 hour) * Revocation status: Cache according to revocation list TTL (see draft-condrey-rats-witnessd-revocation) Verifiers MUST refresh cached trust anchors before expiration. Stale cache entries MUST NOT be used for verification. 4.3. Revocation Checking Integration Trust anchor discovery integrates with revocation checking: 1. Verifier receives Evidence packet 2. Verifier extracts device certificate from Evidence 3. Verifier validates certificate chain to trusted CA 4. Verifier checks certificate revocation status 5. Verifier checks Evidence revocation status 6. If all checks pass, Verifier proceeds with appraisal Certificate revocation and Evidence revocation are independent. A revoked certificate invalidates all Evidence signed by that device. Evidence may be revoked even if the certificate remains valid. 5. Key Lifecycle Management Device keys have a lifecycle from generation through retirement. This section defines key management operations. 5.1. Key Rotation Devices SHOULD rotate signing keys periodically to limit exposure from potential compromise. Key rotation workflow: 1. Device generates new key pair 2. Device requests certificate for new key (standard enrollment) 3. Device publishes key rotation notice signed by old key 4. Rotation notice links old key to new key 5. Old key enters grace period (RECOMMENDED: 30 days) Condrey Expires 11 August 2026 [Page 8] Internet-Draft witnessd Enrollment February 2026 6. After grace period, old key is retired key-rotation-notice = { old-device-id: bstr, new-device-id: bstr, old-public-key: bstr, new-public-key: bstr, rotation-time: time, grace-period-end: time, old-key-signature: bstr, ; Proves control of old key new-key-signature: bstr ; Proves control of new key } Evidence signed during the grace period MAY use either key. After the grace period, only the new key is valid. 5.2. Device Migration When users migrate to a new device, Evidence continuity must be maintained. Migration is treated as key rotation with additional verification: * User initiates migration from old device (if available) * Old device signs migration authorization for new device * New device completes enrollment with migration authorization * If old device is unavailable, user completes out-of-band verification (email, organizational approval, etc.) Migration without old device access requires stronger verification to prevent unauthorized device takeover. 5.3. Key Compromise Response When a device key is compromised: 1. User reports compromise to enrollment authority 2. Authority revokes device certificate immediately 3. User enrolls new device with fresh key 4. User may re-endorse historical Evidence with new key (see draft- condrey-rats-witnessd-revocation) Condrey Expires 11 August 2026 [Page 9] Internet-Draft witnessd Enrollment February 2026 Hardware-backed keys (TPM, Secure Enclave) reduce compromise risk and are RECOMMENDED for high-security deployments. 5.4. Certificate Renewal Devices MUST renew certificates before expiration. Renewal may use the existing key (if not compromised) or coincide with key rotation. Renewal workflow: 1. Device submits renewal request with current certificate 2. Authority validates current certificate is still valid 3. Authority issues new certificate (same or new key) 4. New certificate validity period begins from issuance Devices SHOULD initiate renewal at least 7 days before certificate expiration to allow for processing delays. 6. Security Considerations 6.1. Threat Model The enrollment protocol considers the following threats: Unauthorized enrollment: Attacker attempts to enroll a device under another user's identity. Mitigated by user identifier verification (email, domain, organizational approval). Key extraction: Attacker attempts to extract device private key. Mitigated by hardware-backed key storage (TPM, Secure Enclave) where available. Enrollment authority compromise: Attacker compromises the enrollment authority and issues fraudulent certificates. Mitigated by certificate transparency logs and short certificate validity periods. Man-in-the-middle: Attacker intercepts enrollment messages. Mitigated by TLS for all enrollment communications and challenge- response binding. Replay attacks: Attacker replays old enrollment requests. Mitigated by nonces and timestamps in all protocol messages. Condrey Expires 11 August 2026 [Page 10] Internet-Draft witnessd Enrollment February 2026 6.2. Compromise Impact Analysis The impact of various compromises: * Single device key compromise: Only Evidence from that device is affected. Other devices and users are unaffected. * Organizational CA compromise: All devices enrolled under that CA are potentially affected. Requires CA re-keying and mass device re-enrollment. * Public registry compromise: All devices using that registry are potentially affected. Requires registry recovery and certificate reissuance. Organizational deployments SHOULD use Hardware Security Modules (HSMs) for CA key protection. Public registries MUST implement multi-party controls for certificate issuance. 6.3. Mitigation Requirements Implementations MUST: * Use TLS 1.3 or later for all enrollment communications * Validate certificate chains completely before trusting * Check certificate revocation status before accepting Evidence * Implement rate limiting to prevent enrollment abuse * Log enrollment events for audit purposes Implementations SHOULD: * Use hardware-backed key storage where available * Implement certificate transparency monitoring * Support multiple enrollment authorities for redundancy * Provide key compromise notification mechanisms 7. Privacy Considerations Condrey Expires 11 August 2026 [Page 11] Internet-Draft witnessd Enrollment February 2026 7.1. Device Identifier Privacy Device identifiers enable tracking across Evidence packets. To protect user privacy: * Device identifiers SHOULD be opaque random values, not derived from hardware identifiers or user information * Users MAY request new device identifiers during key rotation to break tracking linkage * Verifiers MUST NOT share device verification patterns with third parties Self-sovereign mode provides the strongest privacy as no central authority learns about device enrollment. Public registry mode has the weakest privacy as the registry sees all enrolled devices. 7.2. Enrollment Metadata Minimization Enrollment authorities collect metadata during device registration. To minimize privacy impact: * Collect only the minimum information necessary for enrollment * Do not retain IP addresses or location data beyond enrollment completion * Do not share enrollment metadata with third parties * Provide data deletion upon user request (subject to legal retention requirements) Enrollment authorities MUST publish a privacy policy describing data collection, retention, and sharing practices. 7.3. Registry Privacy Modes Public registries MAY offer privacy modes: Public mode: Device certificates are publicly discoverable. Anyone can verify Evidence from the device. Suitable for public authors. Unlisted mode: Device certificates are not publicly listed but can be retrieved by packet-id lookup. Provides some obscurity. Private mode: Device certificates are only returned to authenticated Condrey Expires 11 August 2026 [Page 12] Internet-Draft witnessd Enrollment February 2026 Verifiers with a legitimate need. Suitable for sensitive contexts. Users SHOULD select the privacy mode appropriate for their use case. The default mode is deployment-specific. 8. IANA Considerations This document requests registration of the following well-known URI: * URI suffix: witnessd-devices * Change controller: IETF * Specification document: [this document] 9. References 9.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, . 9.2. Informative References [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 13]