When a workload credential outlives attestation

Summary

An active individual Internet-Draft proposes that a RATS-aware Identity Document Service issue a familiar key, token or credential to an attested workload, allowing RATS-unaware relying parties to remain unchanged.
The convenience creates a lifecycle seam: a credential can remain valid under ordinary certificate or token rules after Evidence, appraisal policy, workload location or a claim used at issuance has changed.
Daniel Kade proposes an attestation-to-credential lease that binds each credential to evidence and policy epochs, claim classes, key ownership, trigger events and a native revocation or status path. This is editorial guidance, not IETF consensus.

Five minutes between two valid decisions

The migration example is unusually useful because it does not require an attacker. A workload presents Evidence. A Verifier appraises it. An Identity Document Service accepts the Attestation Result and issues a credential that an existing service already knows how to verify. Five minutes later, routine orchestration moves the workload across a national boundary. The private key has not leaked. The certificate has not expired. The signature remains correct. Nothing visible to the legacy relying party has failed.

But the meaning of the credential may have changed. draft-bdnr-rats-trustworthy-credentials-02 notes that migration from Germany to France could make a Country=Germany claim false while leaving Region=Europe true. Whether that matters depends on policy. A regional routing entitlement might still be justified; a country-specific data-handling permission might not be. The same movement can therefore require no action, narrower scope, re-attestation or immediate revocation.

This is the post-issuance seam. Remote attestation evaluates a state at a bounded time under identified policies. A conventional credential is designed to be presented repeatedly until expiry or revocation. Converting the first into the second is operationally attractive because it protects old applications from a new trust protocol. It also concentrates responsibility in the converter. The component that hides attestation on the way in must translate trust changes on the way out.

Minimal blast radius is a serious design goal

The draft begins from a practical constraint. Many relying parties cannot process RATS Evidence or Attestation Results. They may be third-party binaries, written in unsuitable languages, subject to costly review, or owned by teams that cannot absorb another security subsystem. Requiring every server and client to become a RATS participant would make adoption depend on the slowest application in the estate.

The proposed bridge gives that constraint architectural form. A Credential Broker, Key Broker or Credential Authority can act both as a RATS Relying Party and as an Identity Document Service. The workload proves its state to that intermediary. If the result is acceptable, the intermediary returns an ordinary identity document—a key, token or credential—that collaborating parties already understand. The draft describes variants involving a key broker, a pre-provisioned proof-of-possession credential, and issuance of a new proof-of-possession credential or short-lived bearer token.

The benefit is real. Existing TLS, certificate, token and service-authentication paths need not be replaced. A workload can hold the private key, limiting exposure. The application’s ordinary authorisation machinery can continue to operate. The authors accurately call this a small blast radius.

Governance should preserve that virtue. The wrong response is to insist that every legacy service learn the vocabulary of Evidence, Endorsements, reference values and Attestation Results. The right question is narrower: what obligation moves to the intermediary when downstream software is deliberately kept unaware?

Attestation is not a timeless credential

RFC 9334 separates three judgments that are easy to collapse in conversation. A Verifier applies an Appraisal Policy for Evidence. It produces an Attestation Result. A Relying Party then applies its own Appraisal Policy for Attestation Results to decide whether the result is sufficient for a particular use. Authenticity is necessary, but it is not the same as authorisation.

Time enters twice. Evidence needs freshness appropriate to the use case, and an Attestation Result has a validity boundary. RFC 9334 warns that a race cannot be eliminated: the attested environment or the policy can change immediately after a result is produced. Its discipline is consequently modest but important—do not use a result beyond its validity period, and choose freshness rules that fit the decision.

An issued credential introduces a third clock. It has its own notBefore and notAfter, token expiry, status endpoint or revocation mechanism. Those properties are visible to a RATS-unaware relying party. The attestation epoch and appraisal-policy version usually are not. If the credential clock runs for eight hours while a material Evidence claim is trustworthy for five minutes, the system has not eliminated the five-minute limit. It has concealed it behind a longer-lived object.

Short lifetimes reduce the interval but do not define it. A ten-minute credential can still cross a five-minute claim boundary. Continuous re-attestation can improve observation but still needs a rule that converts a new judgment into an action on the credential already in circulation. Revocation can deliver that action only if issuance recorded which credential depends on which claim and every relying party actually checks the relevant status.

Correct signatures can preserve obsolete meaning

A signature proves a protected object was produced by the holder of a signing key and has not been altered. RFC 7515 gives JSON objects that protection. Certificate path validation under RFC 5280 checks issuers, names, constraints, time and revocation according to the relying party’s configuration. Proof of possession shows control of a corresponding private key. None of these tests reruns the Evidence appraisal that justified issuing the object.

This distinction matters because the bridge is designed to make an old service see a familiar credential. The service can make a completely correct decision under its native rules and still use an obsolete premise. If the certificate is unexpired and not revoked, acceptance is rational from its limited view. Blaming the service would misunderstand the architecture.

The intermediary therefore cannot treat issuance as the end of its RATS role. It has created a dependency between two trust systems. On one side are Evidence, Verifier policy, endorsements, reference values and claims that can change at different speeds. On the other are certificate validity, token expiry, key rotation and revocation semantics. The dependency must survive as operational state rather than disappear into an audit log that nobody consults during authorisation.

Claims age at different speeds

The Germany-to-France example also defeats indiscriminate revocation. A claim set is not one indivisible verdict. Country may be precise and volatile; region may be broader and stable across the same migration. A measured software component could remain unchanged while the hosting operator changes. A secure-boot claim could remain true while a configuration claim becomes false. A policy revision might newly reject one algorithm without disqualifying the workload’s other attributes.

The intermediary needs a dependency map at the level that policy uses. If a credential grants only an Europe-wide entitlement, movement within Europe need not end it merely because a country claim was present in the Attestation Result. If it grants access to data restricted to Germany, the country claim is material and migration is a trigger. If both rights are encoded in one coarse credential, the design has made selective correction impossible. Scope separation becomes a governance control, not only a credential-format preference.

This prevents two symmetrical failures. Overbroad survival lets a credential retain authority after its basis fails. Overbroad revocation turns every state change into an outage and gives operators an incentive to ignore attestation signals. A credible system must show why a changed claim did or did not affect each issued capability.

The workload identity must follow the attested key

The draft pays special attention to who asks for a credential. An EST client could run in a hypervisor or orchestrator outside the workload’s trusted computing base. It may authenticate to the service for channel or operational reasons. That client identity must not decide which workload identity document is returned. Evidence and attestation must make the binding, and the workload should retain its private key.

The same rule is needed after issuance. A lifecycle event must join to the credential through the attested workload key and identity, not merely through the orchestrator session that happened to carry the request. Otherwise a migration controller could obtain, refresh or revoke the wrong workload’s credential while every individual protocol exchange appears authenticated.

The LAMPS CSR-attestation draft exposes a related duty. When a certification authority or registration authority uses attestation, it is responsible for binding multiple attestation statements together and binding them to the public key in the certification request. The draft also says such requirements should be documented in a Certification Practice Statement. That is evidence of the shape of the responsibility, not proof that the trustworthy-credential proposal has settled its implementation.

WIMSE adds another useful separation. Its workload-credential work treats a credential as representing workload identity while proof of possession is a distinct mechanism. Key control answers “is this presenter the holder?” It does not answer “are all attributes that permitted issuance still true?” Rotation, trust anchors and lifetime rules can strengthen the holder test without repairing a stale location or software-state claim.

An attestation-to-credential lease

Daniel Kade’s proposal is an attestation-to-credential lease maintained by the Identity Document Service. It is not a new public credential type and does not require a legacy relying party to understand RATS. It is the minimum durable record and control path needed to keep two validity regimes connected.

The lease begins with the credential identifier and type, the workload identity, the workload-held public key and the proof-of-possession binding. It records the Evidence epoch and freshness limit used at issuance, the Verifier and its Appraisal Policy for Evidence version, and the IDS policy version that accepted the Attestation Result. These are dependencies, not decorations. A policy replacement or Verifier change can then identify the credentials whose basis must be reconsidered.

Next comes a claim map. Each authority-bearing scope in the credential is linked to the minimum attested claim class that justified it. The map distinguishes narrow claims such as country from broad claims such as region, and environmental claims from measured-software or key-protection claims. It records whether the dependency is mandatory, advisory or used only to select a shorter lifetime. Raw Evidence need not be copied into the lease; a protected reference, epoch and result digest can be enough for operational joining, subject to the privacy and retention policy.

The lease then sets a horizon. Credential expiry should not silently exceed the shortest material trust dependency unless continuous observation and a proven status path provide an equivalent control. This is not a universal demand for the shortest possible credential. It is a demand that any gap be explicit: eight hours may be acceptable if migration is detected and revocation reaches relying parties promptly; it is not acceptable merely because eight hours is the default certificate profile.

Finally, the lease names triggers and translations. Migration, key rotation, a new verifier policy, reference-value withdrawal, software change, remediation failure or changed endorsement can require re-attestation. The resulting action may be replacement, scope reduction, suspension, revocation, or a documented no-action decision when the changed claim is immaterial. The IDS must be able to prove that it emitted the native signal and that the relying party’s normal mechanism could receive it.

Revocation is a delivery system, not a database field

Recording “revoked” beside a credential does not complete the control. Some relying parties cache status. Some check only at connection establishment. Some accept short-lived credentials without online status. Some token systems introspect on every use; others validate locally until expiry. The lease must specify the actual enforcement path and its maximum delay.

This turns operational questions into auditable ones. Which event source reports workload migration? How quickly does the IDS reassess the country dependency? Which certificate-status or token-revocation mechanism is used? What happens to an already established session? How is an unreachable relying party handled? Does a replacement credential reduce scope, and is the old one invalidated before the new authority is used?

An exception must also be a state transition. If an incident commander lets a workload continue for thirty minutes after a verifier outage, the record needs the approving authority, bounded scope, expiry, compensating observation and later disposition. “Attestation unavailable” must not quietly become a permanent credential-renewal mode.

The current drafts leave room for this work

The trustworthy-credential document is candidly incomplete. Its bearer-token path needs another protocol or extension. The treatment of /serverkeygen needs detail. It specifies protected channels and secure storage, and it seeks to keep workload and collaborator changes small, but it does not establish a complete cross-lifecycle governance regime.

That is normal for an individual Internet-Draft. It has no formal IETF standing at the cutoff, and its text can change. The WIMSE and LAMPS drafts are also works in progress, although they sharpen adjacent questions about credential lifetime, proof of possession and attestation-bound certificate requests. They should be read as design material, not as evidence that the proposed lease is already required or deployed.

The sources establish no named implementation, common credential lifetime, migration failure, compliance breach, incident rate or market adoption. The opening is a bounded test case derived from the draft’s own migration warning. It shows a possible state transition, not an allegation about a provider.

A Workload Credential Can Outlive the Attestation Decision Behind It

Summary

Five minutes between two valid decisions

Minimal blast radius is a serious design goal

Attestation is not a timeless credential

Correct signatures can preserve obsolete meaning

Claims age at different speeds

The workload identity must follow the attested key

An attestation-to-credential lease

Revocation is a delivery system, not a database field

The current drafts leave room for this work

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing