Remote Attestation Extensions for EST

2.1. RATS Entities

• Attester: the workload instance producing Evidence¶

• Verifier: the component that appraises Evidence and produces Attestation Results¶

• RATS Relying Party (RRP): consumes Attestation Results to make an authorization decision; in the context of this document, the authorization decision pertains to issuing new or releasing existing credentials to the Attester¶

2.2. TACRA Entities

• CAS: Credential Acquisition System¶

• RATS-Unaware Relying Party (RUP): authenticates the Attester using credentials issued by or retrieved from the RRP¶

2.3. EST Entities

• EST Client: TACRA CAS Client for EST. Renders Attester payloads as EST requests, and EST Server responses as payloads to the Attester.¶

• EST Server: TACRA CAS Server for EST. Forwards Freshness Handles, Evidence, Attestation Results, CSRs, and encrypted material between the EST Client, the Verifier, and a RATS Relying Party (Credential Authority or Secret Vault).¶

2.4. Artifacts

• Evidence: attestation evidence produced by the Attester¶

• Attestation Results: RATS Verifier output¶

• CSR: PKCS#10 certification request¶

• PoP: proof-of-possession of the private key corresponding to the CSR public key¶

• CEK: Credential Encryption Key; when used, CEKpub is carried in Evidence, the response is encrypted to CEKpub¶

• Credential Bundle: the plaintext the Secret Vault seals (Section "Sealing the Released Credential" of [TACRA]): credential items with their attributes, and metadata¶

• Container: the sealed object that carries a Credential Bundle to the Attester, the EncryptedCredentialBundle of that section, which this profile returns as the response of attest-retrieve (Section 9.2.4)¶

• Credential Hint: optional, implementation-defined information supplied by the Attester about the credential it expects. The Credential Authority or Secret Vault MAY use the hint, ignore it, or reject the request. The hint does not authorize issuance or release.¶

• Freshness Kind: the recency method, one of absent-timestamp, absent-none, absent-epoch, present-nonce or present-epoch ([TACRA])¶

• Freshness Handle: the value attest-initiate returns for present-nonce and present-epoch ([TACRA], [INTERACTION-MODELS])¶

• Freshness element: the octets the binding digest covers ([TACRA]): the Freshness Handle, the Attester's timestamp, a locally held epoch marker, or nothing for absent-none. On attest-enroll and attest-retrieve it is the handle member, when present¶

3.1. Attested Enrollment Mode

                                                       +----------+
                                                       | Verifier |
                                                       +----^-----+
+----------+ (1) +-------------+ (2) +------------+  (3,6)  |
| Attester +-----> EST Client  +-----> EST Server +---------+
+----------+ (4) +-------------+ (5) +------------+   (7)   |
                                                      +-----v------+
                                                      | Credential |
                                                      | Authority  |
                                                      +------------+

1. Attester initiates Remote Attestation¶

2. EST Client forwards to EST Server (attest-initiate)¶

3. If Freshness is required: EST Server obtains Freshness from the Verifier or RATS Relying Party and returns it via the EST Client¶

4. Attester generates CSK, CSR, and Evidence bound to the CSR and Freshness¶

5. EST Client POSTs CSR and Evidence (attest-enroll)¶

6. EST Server forwards Evidence to the Verifier¶

7. EST Server forwards CSR and Attestation Results to the Credential Authority, which verifies PoP and authorizes issuance; the credential is returned to the Attester via the EST Client¶

3.2. Attested Retrieval Mode

                                                       +----------+
                                                       | Verifier |
                                                       +----^-----+
+----------+ (1) +-------------+ (2) +------------+  (3,6)  |
| Attester +-----> EST Client  +-----> EST Server +---------+
+----------+ (4) +-------------+ (5) +------------+   (7)   |
                                                       +----v-----+
                                                       |  Secret  |
                                                       |  Vault   |
                                                       +----------+

1. Attester initiates Remote Attestation¶

2. EST Client forwards to EST Server (attest-initiate)¶

3. If Freshness is required: EST Server obtains Freshness from the Verifier or RATS Relying Party and returns it via the EST Client¶

4. Attester generates CEK and Evidence including CEKpub, bound to Freshness¶

5. EST Client POSTs Evidence (attest-retrieve)¶

6. EST Server forwards Evidence to the Verifier¶

7. EST Server forwards Attestation Results to the Secret Vault, which seals the matching Credential Bundle to CEKpub in a container. The EST Server, through the EST Client, returns that container to the Attester, which checks it and decrypts it with CEKpri.¶

5.1. attest-initiate

The first leg of both modes is where the Attester initiates Remote Attestation by invoking the EST Client.¶

• Method: GET¶

• Request: no body; query parameters target (REQUIRED) and credential_type and credential_hint (OPTIONAL)¶

• Success: 200 OK¶

• Response: AttestationInitiationResponse (Section 8.1): Freshness kind, Credential Acquisition Mode (enroll or retrieve), acceptable ciphers¶

• Error: 400 when target is absent or credential_type is not a token of Section 8.3, 404 when the EST Server does not serve that Target, 403 when the RATS Relying Party does not serve that Credential Type for it, 400 or 403 for a Credential Hint the policy does not know or denies (Section 10)¶

Query parameters:¶

• target: the Target of Initiate-Credential-Acquisition (Section 5.1 of [TACRA]), an octet string. In this profile a configured name is UTF-8 in Normalization Form C ([RFC5198]), a URI for instance. The client percent-encodes that string in the query. The EST Server decodes it and compares the octets.¶

• credential_type: the Credential Type the Attester plans to use with this Target (Section 8.3). If omitted, the EST Server returns the mode and algorithms its policy sets for the Target. The second leg then MAY omit credential_type or name the Credential Type those imply. When attest-initiate named one, the second leg of the same present-nonce exchange MUST name the same token (Section 9.1.4, Section 9.2.5).¶

• credential_hint: the Credential Hint of Initiate-Credential-Acquisition (Section 5.1 of [TACRA]). The client percent-encodes the string in the query, as for target. If omitted, the second leg MAY omit credential_hint or name one. When attest-initiate named one, the second leg of the same present-nonce exchange MUST name the same string (Section 9.1.4, Section 9.2.5).¶

• If the EST Client already knows all the information the Attester needs to proceed, i.e., it is already configured for an absent Freshness kind (absent-timestamp, absent-none, or absent-epoch), and it knows what Credential Acquisition Mode is expected, and which ciphers to use, it MAY complete attest-initiate locally and, in that case, MUST NOT contact the EST Server.¶

• The EST Server, if contacted, obtains the Freshness Kind and Handle, if any, from the configured Verifier or RATS Relying Party and returns that result.¶

• For present-nonce, that GET returns a single-use Handle its originator minted, and the EST Server records it for the correlation of Section 9.1.4 and Section 9.2.5, as the nonce resource of [ATTESTATION-FRESHNESS] associates its nonce with the next request (Section 6).¶

• present-nonce and present-epoch MUST include a Freshness Handle from the party chosen by the EST Server. absent-* Freshness Kinds carry no Freshness Handle.¶

• The EST Client forwards the response to the Attester.¶

• The Attester produces Evidence as the Freshness Kind requires.¶

• The EST Client then POSTs attest-enroll or attest-retrieve as the Attester indicates.¶

A Credential Authority or Secret Vault issues or releases credentials for a Target per its policy for that Target, since the Target only recognizes credentials from an issuer it already trusts. The Target itself takes no part in this profile: it is the RATS-unaware Relying Party of [TACRA], named in the request and in the binding. If the second leg fails because a present-epoch moved or a present-nonce is no longer valid, the Attester retries attest-initiate.¶

5.2. attest-enroll

• Method: POST¶

• Request: AttestedEnrollmentRequest (Section 9.1.1): CSR and Evidence¶

• Success: 200 OK¶

• Response: enrollment response as for simpleenroll (Section 4.2.3 of [RFC7030])¶

5.3. attest-retrieve

• Method: POST¶

• Request: AttestedRetrievalRequest (Section 9.2.1): CEKpub and Evidence¶

• Success: 200 OK¶

• Response: EncryptedCredentialBundle (Section 9.2.4)¶

7.1. Message Definitions

In the definitions below, a byte string is carried as a text string holding its unpadded base64url encoding (Section 5 of [RFC4648]), as the control operator .b64u defines it (Section 2.1 of [RFC9741]): only characters of the base64url alphabet, no padding, and the bits that encode no octet set to zero. The group choices tie each member to the Freshness Kinds and modes its description below names: in a response, handle and expires_in to present-nonce and present-epoch, max_age to absent-timestamp, acceptable_csk to enroll and acceptable_cek to retrieve; in a request, handle to every Freshness Kind but absent-none. The container of attest-retrieve is the encrypted-credential-bundle of [TACRA], with its plaintext, and is not repeated here.¶

; The JSON messages of the attest-* resources (RFC 8610; RFC 8259).
; A byte string is carried as a text string holding its unpadded
; base64url encoding (RFC 4648, Section 5), as the control .b64u of
; RFC 9741 defines.

attestation-initiation-response = {
  initiation-freshness,
  initiation-mode,
  ? acceptable_evidence: [+ text],
}

initiation-freshness = (
  freshness_kind: "present-nonce",
  handle: text .b64u (bytes .size (16..64)),
  ? expires_in: uint,
//
  freshness_kind: "present-epoch",
  handle: text .b64u (bytes .size (8..64)),
  ? expires_in: uint,
//
  freshness_kind: "absent-timestamp",
  ? max_age: uint,
//
  freshness_kind: "absent-epoch" / "absent-none",
)

initiation-mode = (
  mode: "enroll",
  acceptable_csk: [+ text],
//
  mode: "retrieve",
  acceptable_cek: [+ text],
)

attested-enrollment-request = {
  request-common,
  request-freshness,
  csr: text .b64u bytes,
}

attested-retrieval-request = {
  request-common,
  request-freshness,
  cek_pub: text .b64u bytes,
}

request-common = (
  target: text,
  ? credential_type: text,
  evidence: text .b64u bytes,
  ? profile: text,
  binding: binding,
  ? credential_hint: text,
)

request-freshness = (
  freshness_kind: "absent-none"
//
  freshness_kind: "absent-timestamp",
  handle: text .b64u (bytes .size 8),
//
  freshness_kind: "absent-epoch" / "present-epoch",
  handle: text .b64u (bytes .size (8..64)),
//
  freshness_kind: "present-nonce",
  handle: text .b64u (bytes .size (16..64)),
)

binding = {
  method: "binding-input",
  hash: "sha512",
}

8.1. AttestationInitiationResponse

Fields:¶

• freshness_kind (string, REQUIRED): one of the Freshness Kinds of [TACRA]¶

  • absent-timestamp: stamp Evidence from a trusted clock¶

  • absent-none: no freshness claim¶

  • absent-epoch: embed an epoch marker already held locally¶

  • present-nonce: single-use Freshness Handle; embed it in Evidence¶

  • present-epoch: current epoch marker as Freshness Handle; embed it in Evidence; retry attest-initiate if the epoch moved¶

• handle (bytes, 16 to 64 octets for present-nonce, 8 to 64 for present-epoch): Freshness Handle, REQUIRED for present-nonce and present-epoch, and MUST be absent otherwise (Section 5.1). A present-nonce Handle is a nonce as [TACRA] specifies: 16 to 64 octets, at least 128 bits of entropy, issued once and not reused.¶

• expires_in (integer, OPTIONAL): seconds until a present-nonce or present-epoch Handle is no longer valid, the expiry of [ATTESTATION-FRESHNESS]. The Handle originator SHOULD NOT set it below 60 seconds ([TACRA]).¶

• max_age (integer, OPTIONAL): for absent-timestamp, the maximum Evidence age in seconds acceptable to the Verifier or RATS Relying Party¶

• mode (string, REQUIRED): enroll or retrieve¶

• acceptable_cek (array, REQUIRED when mode is retrieve and absent otherwise): the CEK suites the Secret Vault accepts, tokens of Section 8.4, at least one¶

• acceptable_csk (array, REQUIRED when mode is enroll and absent otherwise): the CSK algorithms the Credential Authority accepts, tokens of Section 8.4, at least one¶

• acceptable_evidence (array, OPTIONAL): the Evidence formats the EST Server forwards, each named by its media type (Section 8.4). A request of the second leg MUST name the format of its Evidence in profile, one of them. When the list is absent, or attest-initiate was completed locally, the EST Client sends no profile¶

For present-nonce, the Freshness Handle originator MUST ensure uniqueness and MUST correlate the second-leg request with the Handle from this attest-initiate. For present-epoch, it checks that the Handle is still the current epoch marker ([TACRA]). The Verifier appraises whether Evidence is bound to a still-valid Freshness Handle.¶

8.2. The Binding in This Profile

This profile uses the digest of Section "Binding Credential Keys to Evidence" of [TACRA]. The Attester writes that digest into the freshness input of its Evidence, the Direct form of that section. The Verifier reports the value it read. The Credential Authority or the Secret Vault recomputes the digest from the request and refuses the request with 400 Bad Request unless the two are equal.¶

The three octet strings of that construction are, in this profile:¶

• freshness: the freshness element of the request, the octets of handle. For present-nonce and present-epoch that is the Freshness Handle attest-initiate returned. For absent-epoch it is the epoch marker the Attester holds. For absent-timestamp it is the Attester's timestamp, 8 octets, as [TACRA] encodes it. For absent-none it is empty, and handle is absent.¶

• target: the octets of the target member, the Target octet string of [TACRA], neither recoded nor normalized. The member carries the same string as the Target of the attest-initiate, on the wire or completed locally.¶

• subject: for Enrollment, the DER encoding of the PKCS#10 CSR, the octets of csr. For Retrieval, CEKpub as the request carries it, the octets of cek_pub, in the encoding of its KEM in Section "Sealing the Released Credential" of [TACRA].¶

The digest is SHA-512, as [TACRA] sets for a freshness input of 64 octets, which REPORT_DATA of AMD SEV-SNP and REPORTDATA of Intel TDX are. A platform whose freshness input is not 64 octets is outside this document's mandatory method.¶

The binding object (Section 7.1) carries no octets of its own. It names the method and the hash:¶

• method (string, REQUIRED): binding-input, the construction above and the only method this document defines.¶

• hash (string, REQUIRED): sha512.¶

A Credential Authority or Secret Vault that does not recognize method refuses the request with 400 Bad Request.¶

8.3. Credential Type Tokens

credential_type, on attest-initiate and in both requests, takes one of the Credential Type tokens of [TACRA], which this profile uses as follows:¶

• x509: an X.509 certificate ([RFC5280]). Enrollment mints one. Retrieval MAY return one that was issued before.¶

• wic: a WIMSE Workload Identity Certificate (Section 6.1 of [WIMSE]), an X.509 certificate whose Workload Identifier is its one URI SubjectAltName. Enrollment mints one, and the Credential Authority sets the Workload Identifier under its policy, as it sets the subject names of any certificate it issues. Retrieval MAY return one that was issued before.¶

• wit: a WIMSE Workload Identity Token ([WIMSE]). Retrieval only.¶

• jwt: a JSON Web Token used as a bearer token ([RFC7519]). Retrieval only.¶

• api-key: an API key. Retrieval only.¶

• psk: a pre-shared symmetric key. Retrieval only.¶

• private-key: a private key shared by the instances of a replicated service. Retrieval only, under the conditions of Section 11.¶

attest-enroll mints x509 or wic. A credential_type other than these on attest-enroll is a Credential Type the RATS Relying Party does not serve, and the EST Server refuses the request with 403 Forbidden (Section 10). When credential_type is absent, on attest-enroll and on attest-retrieve alike, the client takes what the RATS Relying Party issues or releases under its policy. A client that needs a Credential Type names it. attest-retrieve MAY carry any token above. The Secret Vault selects what it releases from the Attestation Results, its policy and the Credential Hint. Where the request names a credential_type, it releases that Credential Type or refuses the request. A Credential Type the RATS Relying Party does not serve is refused with 403 Forbidden, and the response names the Credential Types it serves for that target (Section 10). A credential_type that is not a token of this section is refused with 400 Bad Request.¶

8.4. Protocol Tokens

acceptable_csk, acceptable_cek and acceptable_evidence are arrays of ASCII tokens, and profile is one such token. This document defines them. Further tokens, for other CSK algorithms, digests and freshness inputs, are left for a later revision.¶

CSK algorithms, for Enrollment:¶

• ecdsa-p256-sha256: ECDSA on P-256 with SHA-256, the signature of the CSR. Implementations MUST support it.¶

CEK suites, for Retrieval: the HPKE suites of the container of [TACRA], each named by its KEM, its KDF and its AEAD as the HPKE registries name them ([RFC9180]), joined with +:¶

• DHKEM(P-256, HKDF-SHA256)+HKDF-SHA256+AES-256-GCM: the mandatory suite of [TACRA]. Implementations MUST support it.¶

• MLKEM768-P256+HKDF-SHA256+AES-256-GCM: the suite with the hybrid KEM of [HPKE-PQ], which a Secret Vault MAY offer where a released secret must stay confidential against a later quantum computer.¶

A Credential Authority or Secret Vault names in acceptable_csk or acceptable_cek the tokens it accepts, and the Attester generates its key for one of them.¶

Evidence formats: the media type of the Evidence, in the format the Verifier recognizes, for example application/vnd.veraison.tsm-report+cbor.¶

A client MUST NOT use a token the attest-initiate response did not list. A client that completed attest-initiate locally uses the tokens its configuration names.¶

9.1. Credential Enrollment Mode

9.2. Credential Retrieval Mode

11.1. Specific to Attested Enrollment Mode

• Key Substitution: attestation success is not sufficient without Evidence-to-CSR binding and PoP¶

• Identity Over-Issuance: Credential Authority policy must constrain subject/SAN to the attested identity context¶

11.2. Specific to Attested Retrieval Mode

• Shared Signing Key distribution: If the credential bundle includes a private signing key shared across replicas, compromise of one replica compromises the group. This mode SHOULD be restricted to environments where unwrap and key use are strongly protected.¶

• Non-Exportability Requirements: Deployments that transport a signing key SHOULD require Evidence to attest that CEKpri is non-exportable and that decryption/unwrapping occurs only within an approved protected environment (e.g., TEE/TPM-sealed key usage).¶

• Origin of the container: the EST Client and the EST Server saw CEKpub and can return a container of their own, sealed to it. The Secret Vault's secret stays confidential: a container the Secret Vault sealed can only be unsealed with CEKpri, and one created by the EST Client or the EST Server will not authenticate the Attester to the Target. This profile accepts that risk, and the Trust Model of [TACRA] states what follows by Credential Type.¶

• Attribution: Shared keys eliminate per-instance attribution. If accountability is required, consider per-instance keys with identical identity claims, or a centralized signing service.¶

11.3. Common to Both Modes

• Freshness: the Freshness Kinds and the freshness element are those of [TACRA], built on the recency methods of Section 10 of [RFC9334]. A present-* Handle comes from the Verifier or the RATS Relying Party, a timestamp from the Attester's clock, and an epoch marker from a local hold or a returned Handle. Evidence MUST carry the freshness element in the binding (Section 8.2). The originator of a Handle MUST reject present-nonce reuse and a stale present-epoch.¶

• Evidence and Attestation Results: the EST Client and the EST Server see Evidence and, in the Passport model, Attestation Results in plaintext (Section 12.2 of [RFC9334], the Trust Model of [TACRA]). A retrieved secret stays inside the EncryptedCredentialBundle (Section 9.2.4), an enrolled certificate is public, and CSKpri and CEKpri never leave the Attester.¶

• Channel binding: the digest of Section 8.2 binds no TLS session and no Credential Authority or Secret Vault. It binds the Target name, so an EST Server can relay the exchange to another RATS Relying Party that serves the same Target, and that party recomputes the same digest. What it obtains, and that Evidence can reach any RATS Relying Party, is in the Trust Model of [TACRA]. A TLS channel binding would have to reach the Attester from the EST Client, which this architecture does not assume (Design Goal 8 of [TACRA]), so this profile puts none in the Evidence.¶

• Client authentication: [TACRA] leaves the authentication of the EST Client to the EST Server to profiles. This profile requires none for the attest-* resources: Remote Attestation authenticates the Attester, and the EST Client holds no credential of its own. A deployment MAY require TLS client authentication on them, as on simpleenroll (Section 3.3 of [RFC7030]). An EST Server that returns present-nonce Handles on an unauthenticated attest-initiate SHOULD rate-limit those requests and cap the Handles outstanding per client.¶

• The channels from the EST Server to the Verifier and to the Credential Authority or Secret Vault MUST provide integrity, authenticity, and replay protection.¶

• The EST Server SHOULD enforce size and rate limits on Evidence.¶

• The Credential Type and the Credential Hint are not in the binding. The RATS Relying Party decides by its policy what it issues or releases for them. The EST Server's correlation of a present-nonce Handle with its attest-initiate only checks that the second leg does not change a credential_type or credential_hint the attest-initiate named, and authorizes nothing ([TACRA]).¶

• If classic EST and attested resources both exist, the RATS Relying Party MUST be able to require attestation. The EST Server MUST NOT substitute a classic EST operation for an attested request.¶

13.1. application/est-attest-initiate+json

Type name:

application¶

Subtype name:

est-attest-initiate+json¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

binary¶

Security considerations:

See Section 11 of this document.¶

Interoperability considerations:

The response of attest-initiate.¶

Published specification:

This document.¶

Applications that use this media type:

EST implementations of the attest-* resources of this document.¶

Fragment identifier considerations:

The syntax and semantics of fragment identifiers are as specified for "application/json". At publication of this specification, no fragment identification syntax is defined for "application/json".¶

Additional information:

Deprecated alias names for this type: N/A; Magic number(s): N/A; File extension(s): N/A; Macintosh file type code(s): N/A¶

Person & email address to contact for further information:

Mark F. Novak mark.f.novak@jpmchase.com¶

Intended usage:

COMMON¶

Restrictions on usage:

N/A¶

Author:

See the Authors' Addresses section of this document.¶

Change controller:

IESG¶

13.2. application/est-attest-enroll+json

Type name:

application¶

Subtype name:

est-attest-enroll+json¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

binary¶

Security considerations:

See Section 11 of this document.¶

Interoperability considerations:

The request of attest-enroll; its response is that of simpleenroll.¶

Published specification:

This document.¶

Applications that use this media type:

EST implementations of the attest-* resources of this document.¶

Fragment identifier considerations:

The syntax and semantics of fragment identifiers are as specified for "application/json". At publication of this specification, no fragment identification syntax is defined for "application/json".¶

Additional information:

Deprecated alias names for this type: N/A; Magic number(s): N/A; File extension(s): N/A; Macintosh file type code(s): N/A¶

Person & email address to contact for further information:

Mark F. Novak mark.f.novak@jpmchase.com¶

Intended usage:

COMMON¶

Restrictions on usage:

N/A¶

Author:

See the Authors' Addresses section of this document.¶

Change controller:

IESG¶

13.3. application/est-attest-retrieve+json

Type name:

application¶

Subtype name:

est-attest-retrieve+json¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

binary¶

Security considerations:

See Section 11 of this document.¶

Interoperability considerations:

The request of attest-retrieve; its response is application/est-attest-bundle+json.¶

Published specification:

This document.¶

Applications that use this media type:

EST implementations of the attest-* resources of this document.¶

Fragment identifier considerations:

The syntax and semantics of fragment identifiers are as specified for "application/json". At publication of this specification, no fragment identification syntax is defined for "application/json".¶

Additional information:

Deprecated alias names for this type: N/A; Magic number(s): N/A; File extension(s): N/A; Macintosh file type code(s): N/A¶

Person & email address to contact for further information:

Mark F. Novak mark.f.novak@jpmchase.com¶

Intended usage:

COMMON¶

Restrictions on usage:

N/A¶

Author:

See the Authors' Addresses section of this document.¶

Change controller:

IESG¶

13.4. application/est-attest-bundle+json

Type name:

application¶

Subtype name:

est-attest-bundle+json¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

binary¶

Security considerations:

See Section 11 of this document.¶

Interoperability considerations:

The response of attest-retrieve, the EncryptedCredentialBundle (Section 9.2.4). The JSON object is the encrypted-credential-bundle that [TACRA] specifies.¶

Published specification:

This document.¶

Applications that use this media type:

EST implementations of the attest-* resources of this document.¶

Fragment identifier considerations:

The syntax and semantics of fragment identifiers are as specified for "application/json". At publication of this specification, no fragment identification syntax is defined for "application/json".¶

Additional information:

Deprecated alias names for this type: N/A; Magic number(s): N/A; File extension(s): N/A; Macintosh file type code(s): N/A¶

Person & email address to contact for further information:

Mark F. Novak mark.f.novak@jpmchase.com¶

Intended usage:

COMMON¶

Restrictions on usage:

N/A¶

Author:

See the Authors' Addresses section of this document.¶

Change controller:

IESG¶

14.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[RFC5198]

Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, <https://www.rfc-editor.org/rfc/rfc5198>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/rfc/rfc6838>.

[RFC7030]

Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, <https://www.rfc-editor.org/rfc/rfc7030>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC8951]

Richardson, M., Werner, T., and W. Pan, "Clarification of Enrollment over Secure Transport (EST): Transfer Encodings and ASN.1", RFC 8951, DOI 10.17487/RFC8951, November 2020, <https://www.rfc-editor.org/rfc/rfc8951>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC9180]

Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

[RFC9741]

Bormann, C., "Concise Data Definition Language (CDDL): Additional Control Operators for the Conversion and Processing of Text", RFC 9741, DOI 10.17487/RFC9741, March 2025, <https://www.rfc-editor.org/rfc/rfc9741>.

14.2. Informative References

[ATTESTATION-FRESHNESS]

Tschofenig, H., Brockhaus, H., Mandel, J., and S. Turner, "Requesting a Freshness Nonce for Attestation Evidence in Certificate Signing Requests", Work in Progress, Internet-Draft, draft-ietf-lamps-attestation-freshness-09, 17 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-attestation-freshness-09>.

[CSR-ATTEST]

Ounsworth, M., Tschofenig, H., Birkholz, H., Wiseman, M., and N. Smith, "Use of Remote Attestation with Certification Signing Requests", Work in Progress, Internet-Draft, draft-ietf-lamps-csr-attestation-32, 22 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-csr-attestation-32>.

[HPKE-PQ]

Barnes, R. and D. Connolly, "Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms for HPKE", Work in Progress, Internet-Draft, draft-ietf-hpke-pq-05, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-hpke-pq-05>.

[INTERACTION-MODELS]

Birkholz, H., Eckel, M., Pan, W., and E. Voit, "Reference Interaction Models for Remote Attestation Procedures", Work in Progress, Internet-Draft, draft-ietf-rats-reference-interaction-models-20, 28 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-reference-interaction-models-20>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC6585]

Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, <https://www.rfc-editor.org/rfc/rfc6585>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC8792]

Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, <https://www.rfc-editor.org/rfc/rfc8792>.

[RFC9148]

van der Stok, P., Kampanakis, P., Richardson, M., and S. Raza, "EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol", RFC 9148, DOI 10.17487/RFC9148, April 2022, <https://www.rfc-editor.org/rfc/rfc9148>.

[RFC9457]

Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, <https://www.rfc-editor.org/rfc/rfc9457>.

[TACRA]

Novak, M., Richardson, M., Birkholz, H., and S. Nikolaichuk, "Trustworthy Acquisition of Credentials via Remote Attestation", Work in Progress, Internet-Draft, draft-novak-rats-tacra-03, 2 November 2026, <https://datatracker.ietf.org/doc/html/draft-novak-rats-tacra-03>.

[TWISIGDef]

Confidential Computing Consortium Trustworthy Workload Identity SIG, "Trustworthy Workload Identity (TWI) Special Interest Group - Definitions", n.d., <https://github.com/confidential-computing/twi/blob/main/TWI_Definitions.md>.

[TWISIGReq]

Confidential Computing Consortium Trustworthy Workload Identity SIG, "Trustworthy Workload Identity (TWI) Special Interest Group - Requirements", n.d., <https://github.com/confidential-computing/twi/blob/main/TWI_Requirements.md>.

[WIMSE]

Campbell, B., Salowey, J. A., Schwenkschuster, A., Sheffer, Y., and Y. Rosomakho, "WIMSE Workload Credentials", Work in Progress, Internet-Draft, draft-ietf-wimse-workload-creds-03, 30 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds-03>.

A.1. attest-initiate for Enrollment

NOTE: '\' line wrapping per RFC 8792

GET /.well-known/est/attest-initiate?credential_type=x509&\
    credential_hint=payments.workload.tacra.example&target=https%3A%\
    2F%2Fdb-nonce.tacra.example HTTP/1.1
Host: est.tacra.example
Accept: application/est-attest-initiate+json

HTTP/1.1 200 OK
Content-Type: application/est-attest-initiate+json

{
  "freshness_kind": "present-nonce",
  "handle": "JguWe4G_4VRGo0tZY4URL8xT...",
  "expires_in": 300,
  "acceptable_evidence": [
    "application/vnd.veraison.tsm-report+cbor"
  ],
  "acceptable_csk": [
    "ecdsa-p256-sha256"
  ],
  "mode": "enroll"
}

A.2. attest-enroll

POST /.well-known/est/attest-enroll HTTP/1.1
Host: est.tacra.example
Content-Type: application/est-attest-enroll+json

{
  "target": "https://db-nonce.tacra.example",
  "credential_type": "x509",
  "freshness_kind": "present-nonce",
  "handle": "JguWe4G_4VRGo0tZY4URL8xT...",
  "csr": "MIHkMIGMAgEAMCoxKDAmBgNV...",
  "evidence": "o2dhdXhibG9iWRKbY9p1jeZk...",
  "binding": {
    "method": "binding-input",
    "hash": "sha512"
  },
  "profile": "application/vnd.veraison.tsm-report+cbor",
  "credential_hint": "payments.workload.tacra.example"
}

HTTP/1.1 200 OK
Content-Type: application/pkcs7-mime; smime-type=certs-only

MIICswYJKoZIhvcNAQcCoIICpDCCAqACAQExADAL...

A.3. attest-initiate for Retrieval

NOTE: '\' line wrapping per RFC 8792

GET /.well-known/est/attest-initiate?credential_type=api-key&\
    credential_hint=payments.workload.tacra.example&target=https%3A%\
    2F%2Fledger-nonce.tacra.example HTTP/1.1
Host: est.tacra.example
Accept: application/est-attest-initiate+json

HTTP/1.1 200 OK
Content-Type: application/est-attest-initiate+json

{
  "freshness_kind": "present-nonce",
  "handle": "JRAAJxYwTJ-tsqU1Kqk_PQpA...",
  "expires_in": 300,
  "acceptable_evidence": [
    "application/vnd.veraison.tsm-report+cbor"
  ],
  "acceptable_cek": [
    "DHKEM(P-256, HKDF-SHA256)+HKDF-SHA256+AES-256-GCM"
  ],
  "mode": "retrieve"
}

A.4. attest-retrieve

NOTE: '\' line wrapping per RFC 8792

POST /.well-known/est/attest-retrieve HTTP/1.1
Host: est.tacra.example
Content-Type: application/est-attest-retrieve+json

{
  "target": "https://ledger-nonce.tacra.example",
  "credential_type": "api-key",
  "freshness_kind": "present-nonce",
  "handle": "JRAAJxYwTJ-tsqU1Kqk_PQpA...",
  "cek_pub": "MFkwEwYHKoZIzj0CAQYIKoZI...",
  "evidence": "o2dhdXhibG9iWRKbY9p1jeZk...",
  "binding": {
    "method": "binding-input",
    "hash": "sha512"
  },
  "profile": "application/vnd.veraison.tsm-report+cbor",
  "credential_hint": "payments.workload.tacra.example"
}

HTTP/1.1 200 OK
Content-Type: application/est-attest-bundle+json

{
  "container": "hpke-base",
  "suite": {
    "kem": "DHKEM(P-256, HKDF-SHA256)",
    "kdf": "HKDF-SHA256",
    "aead": "AES-256-GCM"
  },
  "enc": "BFR-7sH5nfSJ7HuGs5K0dydE...",
  "ciphertext": "FrhDDRwvpBSZgk-1tjX-IBHR...",
  "aad": {
    "group_id": "0156b1ec5fc72a6ccc6c04b33e23cb114c9e19979cd3fe68bdd\
    7e9495544a46c",
    "target": "aHR0cHM6Ly9sZWRnZXItbm9uY2UudGFjcmEuZXhhbXBsZQ",
    "handle": "JRAAJxYwTJ-tsqU1Kqk_PQpA...",
    "credential_hint": "payments.workload.tacra.example"
  }
}