Trust Anchor Bootstrap Protocol for Proof of Process

Introduction The Proof of Process (PoP) specification 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

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 when, and only when, they appear in all capitals, as shown here.

Enrollment Modes

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:

Device generates key pair in secure hardware (if available)
Device exports public key and self-signed certificate
User manually provides public key to Verifier (via secure channel)
Verifier stores trust anchor associated with user identity

Use cases: Individual authors, privacy-conscious users, testing environments.

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:

Organization establishes CA infrastructure
Organization publishes CA certificate at well-known location
Device generates key pair and creates certificate signing request
Organization signs device certificate (may require proof of device identity)
Device stores signed certificate
Verifiers validate device certificates against organization CA

Use cases: Enterprises, academic institutions, publishing houses.

Well-Known URI for Device Discovery Organizations SHOULD publish device trust information at: This endpoint returns a signed JSON document listing:

Organization CA certificate chain
Supported enrollment methods
Device certificate validation policy
Contact information for enrollment requests

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. Workflow:

Device generates key pair
Device proves control of user identifier (email, domain, etc.)
Registry issues device certificate bound to user identifier
Registry publishes certificate in transparency log
Verifiers query registry to validate device certificates

Use cases: Open ecosystems, cross-organization verification, consumer applications.

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.

Enrollment Request Devices initiate enrollment by submitting a request containing:

Challenge-Response Flow For organizational and public registry modes, the enrollment authority issues a challenge:

Device submits initial enrollment request
Authority returns challenge (random nonce + user verification requirement)
Device signs challenge with private key (proof of possession)
User completes verification (email link, domain TXT record, etc.)
Device submits signed challenge and verification proof
Authority validates and issues device certificate

Certificate Issuance Upon successful verification, the authority issues a device certificate: Certificates MUST be valid for no more than 1 year. Devices MUST re-enroll before certificate expiration.

Trust Anchor Discovery Verifiers must discover and maintain trust anchors for device certificate validation. This section defines discovery mechanisms and caching policies.

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.

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

Revocation Checking Integration Trust anchor discovery integrates with revocation checking:

Verifier receives Evidence packet
Verifier extracts device certificate from Evidence
Verifier validates certificate chain to trusted CA
Verifier checks certificate revocation status
Verifier checks Evidence revocation status
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.

Key Lifecycle Management Device keys have a lifecycle from generation through retirement. This section defines key management operations.

Key Rotation Devices SHOULD rotate signing keys periodically to limit exposure from potential compromise. Key rotation workflow:

Device generates new key pair
Device requests certificate for new key (standard enrollment)
Device publishes key rotation notice signed by old key
Rotation notice links old key to new key
Old key enters grace period (RECOMMENDED: 30 days)
After grace period, old key is retired

Evidence signed during the grace period MAY use either key. After the grace period, only the new key is valid.

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.

Key Compromise Response When a device key is compromised:

User reports compromise to enrollment authority
Authority revokes device certificate immediately
User enrolls new device with fresh key
User may re-endorse historical Evidence with new key (see draft-condrey-rats-witnessd-revocation)

Hardware-backed keys (TPM, Secure Enclave) reduce compromise risk and are RECOMMENDED for high-security deployments.

Certificate Renewal Devices MUST renew certificates before expiration. Renewal may use the existing key (if not compromised) or coincide with key rotation. Renewal workflow:

Device submits renewal request with current certificate
Authority validates current certificate is still valid
Authority issues new certificate (same or new key)
New certificate validity period begins from issuance

Devices SHOULD initiate renewal at least 7 days before certificate expiration to allow for processing delays.

Security Considerations

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.

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.

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

Privacy Considerations

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.

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.

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

IANA Considerations This document requests registration of the following well-known URI:

URI suffix: witnessd-devices
Change controller: IETF
Specification document: [this document]