]> J.P. Morgan Chase & Co.

mark.f.novak@jpmchase.com

Sandelman Software Works

mcr+ietf@sandelman.ca

Fraunhofer SIT

Henk.Birkholz@ietf.contact

The Capital Index LLC

nikolaichuk.s.f@gmail.com

Security Limited Additional Mechanisms for PKIX and SMIME trustworthy workload identity remote attestation credential enrollment credential retrieval This document specifies extensions to Enrollment over Secure Transport (EST) that realize the Trustworthy Acquisition of Credentials via Remote Attestation (TACRA) architecture. Remote Attestation Procedures (RATS) are used as an authorization input for workload credential provisioning. Two modes are defined: Enrollment: the Attester submits a PKCS#10 CSR and Evidence. A Credential Authority, as RATS Relying Party, authorizes issuance from Attestation Results and binds the credential to the CSR key. Retrieval: the Attester submits Evidence that includes a Credential Encryption Key (CEK). A Secret Vault, as RATS Relying Party, releases an existing credential bundle with secrets encrypted to CEKpub. These extensions add EST resources for a two-leg exchange: optional attest-initiate, followed by either attest-enroll or attest-retrieve. This memo is informational and intended to support discussion and implementation experience. It is not a completed interoperability specification. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Limited Additional Mechanisms for PKIX and SMIME Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction EST () defines an HTTPS-based protocol for certificate enrollment and management, typically between an EST Client and an EST Server acting as an interface to a Credential Authority. In modern environments (e.g., cloud, containers, confidential computing), workloads often lack pre-provisioned credentials and require issuance based on runtime properties. Zero trust environments place additional restrictions limiting which parties have access to secrets and credentials. This means that EST Clients and Servers may not be trusted to handle such restricted information in plaintext. RATS () defines an architecture and roles for Remote Attestation. This document extends EST to match the TACRA architecture: the Attester generates keys, Evidence, and CSRs; the EST Client and EST Server are conduits that carry them to a Verifier and a RATS Relying Party (RRP) (, Section 10 of , ). The RRP in this case is either a Secret Vault, where pre-provisioned credentials are stored, or a Credential Authority capable of creating new ones. Two modes are defined: Enrollment: issuance of a fresh credential bound to a workload-generated Credential Signing Key (CSK) Retrieval: release of a shared credential bundle, with secrets encrypted to an attester-supplied Credential Encryption Key (CEK)

Conventions and Definitions 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.

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

TACRA Entities CAS: Credential Acquisition System RATS-Unaware Relying Party (RUP): authenticates the Attester using credentials issued by or retrieved from the RRP

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

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 ): 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 () 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 () Freshness Handle: the value attest-initiate returns for present-nonce and present-epoch (, ) Freshness element: the octets the binding digest covers (): 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

Architecture The EST encoding is the same in the Passport model and in the Background Check model. The Attester does not talk to the Verifier and does not hold Attestation Results (Design Goal 8 of ). This profile uses the names of : Passport: the EST Server forwards Evidence to the Verifier and forwards the Attestation Results to the Credential Authority or Secret Vault. Background Check: the EST Server forwards Evidence to the Credential Authority or Secret Vault, which obtains the Attestation Results by contacting the Verifier itself. In , the Passport model is where the Attester obtains the Attestation Results from the Verifier and sends them to the Relying Party. Under TACRA, the Attester always uses the Background Check model. The difference between the two models is whether the EST Server or the RATS Relying Party obtains the Attestation Results from the Verifier. Who originates a Freshness Handle, the Verifier or the RATS Relying Party, is independent of that split (). Only the Passport model is illustrated. Both models use two EST legs: optional attest-initiate (), followed by either attest-enroll () or attest-retrieve (). Note that attest-initiate is optional: in cases where the Attester can know with certainty which Freshness Kind to use (and that the Freshness Kind is not either present-nonce or present-epoch), whether to ask for new or existing credentials, as well as which ciphers the RRP expects, it can be omitted. Neither EST Client nor EST Server has a RATS role. Both are subject to the following restrictions: MUST NOT generate keys, Evidence, or CSRs MUST NOT mint present-nonce or present-epoch Freshness Handles MUST NOT appraise Evidence or Attestation Results MUST NOT authorize credential issuance or release. Correlating a Handle with the attest-initiate that returned it is not authorization. Deciding on the Credential Type or the Credential Hint is, and belongs to the RATS Relying Party.

Attested Enrollment Mode

EST Client +-----> EST Server +---------+ +----------+ (4) +-------------+ (5) +------------+ (7) | +-----v------+ | Credential | | Authority | +------------+ ]]>

Attester initiates Remote Attestation EST Client forwards to EST Server (attest-initiate) If Freshness is required: EST Server obtains Freshness from the Verifier or RATS Relying Party and returns it via the EST Client Attester generates CSK, CSR, and Evidence bound to the CSR and Freshness EST Client POSTs CSR and Evidence (attest-enroll) EST Server forwards Evidence to the Verifier 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

Attested Retrieval Mode

EST Client +-----> EST Server +---------+ +----------+ (4) +-------------+ (5) +------------+ (7) | +----v-----+ | Secret | | Vault | +----------+ ]]>

Attester initiates Remote Attestation EST Client forwards to EST Server (attest-initiate) If Freshness is required: EST Server obtains Freshness from the Verifier or RATS Relying Party and returns it via the EST Client Attester generates CEK and Evidence including CEKpub, bound to Freshness EST Client POSTs Evidence (attest-retrieve) EST Server forwards Evidence to the Verifier 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.

Protocol Overview Three new EST operations are added under the EST well-known prefix (Section 3.2.2 of ): /.well-known/est/attest-initiate /.well-known/est/attest-enroll /.well-known/est/attest-retrieve They sit beside the operations of . An EST Server that uses the optional path segment of Section 3.2.2 of , /.well-known/est/arbitraryLabel1/simpleenroll for instance, MUST offer the attest-* operations under that segment as well, /.well-known/est/arbitraryLabel1/attest-initiate and likewise for the other two. As that section requires, it serves them without the segment too. The label MUST NOT be attest-initiate, attest-enroll or attest-retrieve. The segment selects the Credential Authority or Secret Vault the EST Server uses, as it selects a CA in . It is not the Target, which stays the target query parameter or member (). For attest-* the client uses the same segment it uses for simpleenroll at that issuer. Example exchanges are in . They support TACRA Initiate-Credential-Acquisition, Enroll-Credential, and Retrieve-Credential commands, encoded with EST semantics. All exchanges MUST use HTTPS as required by . EST Server authentication via TLS is REQUIRED.

Resources and Methods

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 (): Freshness kind, Credential Acquisition Mode (enroll or retrieve), acceptable ciphers Error: 400 when target is absent or credential_type is not a token of , 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 () Query parameters: target: the Target of Initiate-Credential-Acquisition (Section 5.1 of ), an octet string. In this profile a configured name is UTF-8 in Normalization Form C (), 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 (). 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 (, ). credential_hint: the Credential Hint of Initiate-Credential-Acquisition (Section 5.1 of ). 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 (, ). 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 and , as the nonce resource of associates its nonce with the next request (). 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 , 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.

attest-enroll Method: POST Request: AttestedEnrollmentRequest (): CSR and Evidence Success: 200 OK Response: enrollment response as for simpleenroll (Section 4.2.3 of )

attest-retrieve Method: POST Request: AttestedRetrievalRequest (): CEKpub and Evidence Success: 200 OK Response: EncryptedCredentialBundle ()

Relationship to Other LAMPS Work Two LAMPS documents cover parts of the exchange defined here. defines a nonce request and response for certificate management protocols, including an EST resource at /.well-known/est/nonce (GET, or POST with application/est-attestation-freshness+json) whose response carries a nonce of 8 to 64 bytes and an OPTIONAL expiry in seconds (Section 5.1 of ). attest-initiate () is the first leg that returns the Freshness Handle: such a nonce for present-nonce, the current epoch marker for present-epoch, and none for the absent-* kinds. It returns in addition the Freshness Kind itself, the Credential Acquisition Mode and the acceptable CSK or CEK algorithms (), none of which the nonce resource carries. A present-nonce Handle of this profile is a nonce as specifies: 16 to 64 octets, at least 128 bits of entropy, issued once and not reused. That range lies within the 8 to 64 octets of Section 5.1 of . expires_in is that document's expiry. That section requires the server to associate the nonce with the subsequent request. This profile does so by correlating the Handle with the attest-initiate that returned it, in the server processing of both modes, and by the RATS Relying Party's recomputation of the digest that carries the Handle (). It does not use a TLS session or a cookie for that: either would bind the EST Client, the conduit, and not the Attester. A request of this profile takes no nonce length: the Handle reaches the Evidence through the digest, so no platform needs a Handle of a particular size. An EST Server MAY offer both resources. They are not interchangeable: a nonce returned by the nonce resource is not a Freshness Handle of this profile, and attest-enroll and attest-retrieve take a Handle from attest-initiate, or none for the absent-* kinds. conveys attestations inside the CSR, in its id-aa-attestation attribute. It makes the Certification Authority or Registration Authority that processes the CSR responsible for ensuring that the binding between those attestations and the CSR's public key has been validated (Section 6.1 of ). This profile conveys the Evidence that carries the binding of beside the CSR, in the AttestedEnrollmentRequest (). That Evidence is produced over the digest of , which includes the finished CSR, so it cannot travel inside it, and does not replace it. Evidence beside the CSR is what this profile requires. Attestations in the CSR as well, per , are a second attestation, optional, about properties of the CSR key that this digest does not prove, under the rules of and of Section 6.1 of . Whether a Credential Authority requires them is agreed out of band. This choice is specific to Enrollment; Retrieval has no CSR and binds Evidence to CEKpub ().

Media Types and Encodings The messages of the attest-* resources are JSON (), as defined in CDDL () in ; implementations MUST support this encoding. A CBOR encoding, for EST over secure CoAP (), is left for future work. Evidence is an opaque byte string. As each EST message type has its own media type (Section 3.2.4 of ), so does each JSON message of the attest-* resources (): Resource Request Response attest-initiate none: a GET, query string, no body application/est-attest-initiate+json attest-enroll application/est-attest-enroll+json application/pkcs7-mime; smime-type=certs-only, as simpleenroll attest-retrieve application/est-attest-retrieve+json application/est-attest-bundle+json A client MUST send a POST of the resource's media type. An attest-initiate GET has no body; the client SHOULD set Accept to application/est-attest-initiate+json. An attest-initiate GET for present-nonce is not idempotent: each one returns a Handle its originator issued anew, as the nonce resource of does. An EST Server responds to a request of another media type with 415 (Unsupported Media Type) and SHOULD name the resource's media type in an Accept header field (Section 15.5.16 of ).

Message Definitions In the definitions below, a byte string is carried as a text string holding its unpadded base64url encoding (Section 5 of ), as the control operator .b64u defines it (Section 2.1 of ): 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 , with its plaintext, and is not repeated here.

Common Structures

AttestationInitiationResponse Fields: freshness_kind (string, REQUIRED): one of the Freshness Kinds of 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 (). A present-nonce Handle is a nonce as 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 . The Handle originator SHOULD NOT set it below 60 seconds (). 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 , at least one acceptable_csk (array, REQUIRED when mode is enroll and absent otherwise): the CSK algorithms the Credential Authority accepts, tokens of , at least one acceptable_evidence (array, OPTIONAL): the Evidence formats the EST Server forwards, each named by its media type (). 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 (). The Verifier appraises whether Evidence is bound to a still-valid Freshness Handle.

The Binding in This Profile This profile uses the digest of Section "Binding Credential Keys to Evidence" of . 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 encodes it. For absent-none it is empty, and handle is absent. target: the octets of the target member, the Target octet string of , 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 . The digest is SHA-512, as 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 () 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.

Credential Type Tokens credential_type, on attest-initiate and in both requests, takes one of the Credential Type tokens of , which this profile uses as follows: x509: an X.509 certificate (). Enrollment mints one. Retrieval MAY return one that was issued before. wic: a WIMSE Workload Identity Certificate (Section 6.1 of ), 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 (). Retrieval only. jwt: a JSON Web Token used as a bearer token (). 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 . 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 (). 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 (). A credential_type that is not a token of this section is refused with 400 Bad Request.

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 , each named by its KEM, its KDF and its AEAD as the HPKE registries name them (), joined with +: DHKEM(P-256, HKDF-SHA256)+HKDF-SHA256+AES-256-GCM: the mandatory suite of . Implementations MUST support it. MLKEM768-P256+HKDF-SHA256+AES-256-GCM: the suite with the hybrid KEM of , 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.

Attested Credential Acquisition Modes

Credential Enrollment Mode

Request: AttestedEnrollmentRequest Fields: target (string, REQUIRED): the Target of Enroll-Credential (Section 5.2 of ) freshness_kind (string, REQUIRED): MUST match the preceding attest-initiate response, or the configuration under which the EST Client completed attest-initiate locally () handle (bytes): the freshness element () - REQUIRED when freshness_kind is not absent-none and MUST be absent otherwise. For present-nonce and present-epoch it MUST equal the Freshness Handle returned by attest-initiate. For absent-timestamp it is the 8-octet timestamp and for absent-epoch the locally held epoch marker. Its size is 16 to 64 octets for present-nonce, 8 to 64 for present-epoch and absent-epoch, and 8 for absent-timestamp (). csr (bytes, REQUIRED): DER-encoded PKCS#10 CSR evidence (bytes, REQUIRED): MUST be bound to the Freshness returned by attest-initiate, if any profile (string, OPTIONAL): the media type of evidence, one of the acceptable_evidence of the attest-initiate (). It MUST be absent when that response carried no acceptable_evidence or attest-initiate was completed locally, and MUST be one of the listed tokens otherwise. The EST Server refuses another value with 415 Unsupported Media Type, as a format it does not accept. If absent, the EST Server forwards the Evidence as it is, and the Verifier recognizes its format. A format the EST Server does not accept is refused with 415 Unsupported Media Type. binding (object, REQUIRED): declares how the CSR key is bound to Evidence credential_type (string, OPTIONAL): x509 or wic (). If absent, the client takes what the Credential Authority mints. When the attest-initiate of a present-nonce exchange named a credential_type, this member MUST carry the same token (). credential_hint (string, OPTIONAL): Credential Hint supplied by the Attester; the Credential Authority MAY use it, ignore it, or reject the request. When the attest-initiate of a present-nonce exchange named a credential_hint, this member MUST carry the same string ().

Response (Success) On success, the EST Server returns the enrollment response produced by the Credential Authority, as for simpleenroll in .

Key Binding and PoP Requirements PoP: The Credential Authority MUST verify possession of the CSR private key. Evidence-to-CSR, Evidence-to-Target and Evidence-to-Freshness: the Evidence MUST carry the digest of , the binding of Section "Binding Credential Keys to Evidence" of , with the DER-encoded CSR as its subject. As that section requires, the Verifier reports the bound value in the Attestation Results, and the Credential Authority recomputes it from the request and refuses the request with 400 Bad Request on a mismatch. A substituted CSR, Target or freshness element fails that check. The binding object () is as defines it.

Enrollment Server Processing Upon receiving AttestedEnrollmentRequest, the EST Server MUST: Validate syntax, media type, and size limits. Check that a Credential Authority serves this target and credential_type, and that the mode the EST Server's configuration sets for them, which attest-initiate reports (), is enroll. Refuse the request with 400 Bad Request when a Secret Vault serves them. For present-nonce, correlate handle with the attest-initiate that returned it. Refuse the request with 400 Bad Request when no attest-initiate returned this Handle, when it has expired or was used before, or when its target or freshness_kind differ from the corresponding attest-initiate. Refuse it likewise when that attest-initiate named a credential_type and the request omits it or names another token, or named a credential_hint and the request omits it or names another string. A request MAY name a credential_type its attest-initiate omitted, the one the mode and the algorithms returned imply. A request MAY name a credential_hint its attest-initiate omitted. A present-nonce Handle is single-use. For present-epoch, handle is the epoch marker that every attest-initiate of the epoch returned for this target, and it serves all requests during that epoch. Refuse the request with 400 Bad Request when the marker has moved. For the absent-* Freshness Kinds no Handle was returned, and the RATS Relying Party checks the freshness element under the Freshness Kind its policy sets for the Target (). For present-epoch and the absent-* Freshness Kinds the EST Server does not correlate credential_type or credential_hint and forwards them to the RATS Relying Party, which decides under its policy (). This correlation keeps the two legs of one exchange together at the EST Server. It is not authorization: the Credential Authority takes the Freshness Kind from its policy for the Target, recomputes the digest and decides (). Passport: forward Evidence to the Verifier and obtain Attestation Results. Background Check: skip this step; the Credential Authority obtains Attestation Results itself. Forward the CSR and Attestation Results (Passport) or the CSR and Evidence (Background Check) to the Credential Authority, which verifies PoP and authorizes issuance. Return the Credential Authority's enrollment response. The Credential Authority MUST NOT mint identities (e.g., DNS names) beyond policy for the attested identity context.

Credential Retrieval Mode

Request: AttestedRetrievalRequest Fields: target (string, REQUIRED): the Target of Retrieve-Credential (Section 5.3 of ) freshness_kind (string, REQUIRED): MUST match the preceding attest-initiate response, or the configuration under which the EST Client completed attest-initiate locally () handle (bytes): the freshness element () - REQUIRED when freshness_kind is not absent-none and MUST be absent otherwise. For present-nonce and present-epoch it MUST equal the Freshness Handle returned by attest-initiate. For absent-timestamp it is the 8-octet timestamp and for absent-epoch the locally held epoch marker. Its size is 16 to 64 octets for present-nonce, 8 to 64 for present-epoch and absent-epoch, and 8 for absent-timestamp (). evidence (bytes, REQUIRED) -- MUST include CEKpub; MUST be bound to the Freshness returned by attest-initiate, if any cek_pub (bytes, REQUIRED): CEKpub in the encoding of its KEM in Section "Sealing the Released Credential" of , to which the Secret Vault seals the bundle profile (string, OPTIONAL): the media type of evidence, one of the acceptable_evidence of the attest-initiate (). It MUST be absent when that response carried no acceptable_evidence or attest-initiate was completed locally, and MUST be one of the listed tokens otherwise. The EST Server refuses another value with 415 Unsupported Media Type, as a format it does not accept. If absent, the EST Server forwards the Evidence as it is, and the Verifier recognizes its format. A format the EST Server does not accept is refused with 415 Unsupported Media Type. binding (object, REQUIRED): declares how CEKpub is bound to Evidence credential_type (string, OPTIONAL): one of the tokens of . If absent, the client takes what the Secret Vault releases. When the attest-initiate of a present-nonce exchange named a credential_type, this member MUST carry the same token (). credential_hint (string, OPTIONAL): Credential Hint supplied by the Attester; the RATS Relying Party (Secret Vault or Credential Authority) MAY use it, ignore it, or reject the request. When the attest-initiate of a present-nonce exchange named a credential_hint, this member MUST carry the same string ().

Evidence-to-CEK Binding The Evidence MUST carry the digest of with the octets of cek_pub as its subject. As Section "Binding Credential Keys to Evidence" of requires, the Verifier reports the bound value in the Attestation Results, and the Secret Vault recomputes it from the request and denies release with 400 Bad Request on a mismatch. The binding object is as defines it.

Credential Group ID Determination The Secret Vault maps Attestation Results to a credential group, as requires: stable for replica workloads, and distinct across security domains, tenants and the credentials it releases. The mapping is the Secret Vault's policy. This profile does not specify the construction of group_id, and different Secret Vaults need not compute the same value. credential_hint MAY select among the credentials the policy allows for the attested context and MUST NOT enlarge that set. A Credential Hint the policy does not know is ignored, or the request is refused with 400 Bad Request. The group_id the container carries () is the one the Secret Vault chose, an opaque string to everyone else.

Response: EncryptedCredentialBundle The EST Server returns the container the Secret Vault produced, the encrypted-credential-bundle of Section "Sealing the Released Credential" of , as the body of media type application/est-attest-bundle+json. The EST Client and the EST Server MUST treat it as opaque. That section specifies the container: its members, its suites, the info and the associated data of its HPKE sealing, and its plaintext, the Credential Bundle. In its aad, target is the base64url of the Target octets of the request, the octets of the target member of . This profile adds nothing to it. The Secret Vault names in acceptable_cek the suites it accepts (), the mandatory suite of among them, and the Attester generates its CEK for one of them. The Attester proceeds as requires: it checks that aad names its Target, its freshness element and its Credential Hint, checks the suite, and only then opens the ciphertext. It MUST refuse the container otherwise. Who sealed the container, the Attester cannot tell: anyone who saw CEKpub can seal to it. This profile accepts that, and states the consequence.

Retrieval Server Processing Upon receiving AttestedRetrievalRequest, the EST Server MUST: Validate syntax, media type, and size limits. Check that a Secret Vault serves this target and credential_type, and that the mode the EST Server's configuration sets for them, which attest-initiate reports (), is retrieve. Refuse the request with 400 Bad Request when a Credential Authority serves them. For present-nonce, correlate handle with the attest-initiate that returned it, as in Enrollment. Refuse the request with 400 Bad Request when no attest-initiate returned this Handle, when it has expired or was used before, or when its target or freshness_kind differ from the corresponding attest-initiate. Refuse it likewise when that attest-initiate named a credential_type and the request omits it or names another token, or named a credential_hint and the request omits it or names another string. A request MAY name a credential_type its attest-initiate omitted, the one the mode and the algorithms returned imply. A request MAY name a credential_hint its attest-initiate omitted. A present-nonce Handle is single-use. For present-epoch, handle is the epoch marker that every attest-initiate of the epoch returned for this target, and it serves all requests during that epoch. Refuse the request with 400 Bad Request when the marker has moved. For the absent-* Freshness Kinds no Handle was returned, and the RATS Relying Party checks the freshness element under the Freshness Kind its policy sets for the Target (). For present-epoch and the absent-* Freshness Kinds the EST Server does not correlate credential_type or credential_hint and forwards them to the RATS Relying Party, which decides under its policy (). This correlation keeps the two legs of one exchange together at the EST Server. It is not authorization: the Secret Vault takes the Freshness Kind from its policy for the Target, recomputes the digest and decides (). Passport: forward Evidence to the Verifier and obtain Attestation Results. Background Check: skip this step; the Secret Vault obtains Attestation Results itself. Forward Attestation Results (Passport) or Evidence (Background Check) to the Secret Vault, which computes group_id, authorizes, fetches the bundle and seals it to CEKpub (). Return the EncryptedCredentialBundle produced by the Secret Vault. A variant in which the EST Server receives a plaintext secret from the Secret Vault and seals it to CEKpub itself is not permitted: it would expose the secret to the EST Server ().

Error Handling An error response carries one of the status codes below, and a human-readable body of media type text/plain, as a simpleenroll error does (Section 4.2.3 of , updated by Section 5.1 of ): 400 Bad Request: a request that does not match its definition (), or an attest-initiate with no target. A credential_type that is not a token of . A present-nonce request that omits credential_type, or names another token, when its attest-initiate named one. A present-nonce request that omits credential_hint, or names another string, when its attest-initiate named one. A binding digest that does not recompute (). A present-nonce Handle that no attest-initiate returned, that has expired or was used before, or a present-epoch marker that has moved. A Credential Hint the policy does not know and does not ignore. A present-nonce request whose target or freshness_kind differs from the attest-initiate that returned its Handle, or a request to the resource of the other mode (, ). 401 Unauthorized: missing/invalid authentication required by deployment policy 403 Forbidden, forwarded from the RATS Relying Party: attestation failed, its policy denies enrollment or retrieval, the Credential Hint included, or it does not serve the credential_type for the target. In the last case the body names the Credential Types it serves for that target. 404 Not Found: a target the EST Server does not serve (Section 15.5.5 of : the query is part of the target URI, and a request of the second leg names the same target) 413 Content Too Large: a request larger than the server takes (Section 15.5.14 of ) 415 Unsupported Media Type: a request not of the resource's media type (), or Evidence of a format that is not accepted, a profile the attest-initiate response did not list among them 429 Too Many Requests: rate limiting (Section 4 of ) 500 Internal Server Error: internal error 502 Bad Gateway: the RATS Relying Party did not answer, or answered with a message the EST Server cannot pass on 503 Service Unavailable: the Verifier is unavailable A client acts on the status code. A machine-readable body () is left for a revision in which a client needs the reason. Error bodies MUST NOT leak sensitive attestation details. Servers MAY provide a correlation identifier for debugging.

Security Considerations

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

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

Common to Both Modes Freshness: the Freshness Kinds and the freshness element are those of , built on the recency methods of Section 10 of . 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 (). 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 , the Trust Model of ). A retrieved secret stays inside the EncryptedCredentialBundle (), an enrolled certificate is public, and CSKpri and CEKpri never leave the Attester. Channel binding: the digest of 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 . A TLS channel binding would have to reach the Attester from the EST Client, which this architecture does not assume (Design Goal 8 of ), so this profile puts none in the Evidence. Client authentication: 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 ). 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 (). 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.

Privacy Considerations Evidence can identify the device, its firmware level and the launched software (Section 11 of ). The EST Client, the EST Server, the Verifier and the RATS Relying Party see it. The Trust Model of states what the EST Client and the EST Server read, and a deployment that operates them accepts that exposure. Error bodies MUST NOT echo Evidence or Attestation Results.

IANA Considerations The attest-* resources are additional services of an EST server (Section 3.2.2 of ), under the well-known URI suffix "est" that registered. No registry of EST operation paths exists, so none is requested. IANA is requested to register the media types of in the "Media Types" registry (). The operation names this document adds are attest-initiate, attest-enroll and attest-retrieve.

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

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

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

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 of this document.

Interoperability considerations:

The response of attest-retrieve, the EncryptedCredentialBundle (). The JSON object is the encrypted-credential-bundle that 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

This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] The Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET. This document specifies that format, using UTF-8 with normalization and specific line-ending sequences. [STANDARDS-TRACK] This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document updates RFC 7030: Enrollment over Secure Transport to resolve some errata that were reported and that have proven to cause interoperability issues when RFC 7030 was extended. This document deprecates the specification of "Content-Transfer-Encoding" headers for Enrollment over Secure Transport (EST) endpoints. This document fixes some syntactical errors in ASN.1 that were present. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. RFCs have added to this extension point in both an application-specific and a more general way. The present document defines a number of additional generally applicable control operators for text conversion (bytes, integers, printf-style formatting, and JSON) and for an operation on text. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Siemens Siemens AKAYLA, Inc. sn3rd When an end entity includes attestation statements in a Certificate Signing Request (CSR), the freshness of the conveyed Evidence often needs to be established. A common mechanism is a nonce that is obtained from a Relying Party or Verifier and included by the Attester in the Evidence. This document specifies how an end entity requests such an attestation freshness nonce from an RA/CA when using certificate lifecycle management protocols. It defines message formats and protocol bindings for the conveyance of nonce request and response messages in the Certificate Management Protocol (CMP), Enrollment over Secure Transport (EST), and Certificate Management over CMS (CMC), including optional type-specific information needed to produce fresh Evidence for inclusion in a CSR. Cryptic Forest Software Siemens Fraunhofer SIT Independent Certification Authorities (CAs) issuing certificates to Public Key Infrastructure (PKI) end entities may require a certificate signing request (CSR) to include additional verifiable information to confirm policy compliance. For example, a CA may require an end entity to demonstrate that the private key corresponding to a CSR's public key is secured by a hardware security module (HSM), is not exportable, etc. The process of generating, transmitting, and verifying additional information required by the CA is called remote attestation. While work is currently underway to standardize various aspects of remote attestation, a variety of proprietary mechanisms have been in use for years, particularly regarding protection of private keys. This specification defines ASN.1 structures which may carry attestation data for PKCS#10 and Certificate Request Message Format (CRMF) messages. Both standardized and proprietary attestation formats are supported by this specification. Cisco Selkie Cryptography Updating key exchange and public-key encryption protocols to resist attack by quantum computers is a high priority given the possibility of "harvest now, decrypt later" attacks. Hybrid Public Key Encryption (HPKE) is a widely-used public key encryption scheme based on combining a Key Encapsulation Mechanism (KEM), a Key Derivation Function (KDF), and an Authenticated Encryption with Associated Data (AEAD) scheme. In this document, we define KEM algorithms for HPKE based on both post-quantum KEMs and hybrid constructions of post- quantum KEMs with traditional KEMs, as well as a KDF based on SHA-3 that is suitable for use with these KEMs. When used with these algorithms, HPKE is resilient with respect to attacks by a quantum computer. Fraunhofer SIT Fraunhofer SIT Huawei Technologies Cisco Systems This document describes interaction models for remote attestation procedures (RATS) [RFC9334]. Three conveying mechanisms -- Challenge/Response, Uni-Directional, and Streaming Remote Attestation -- are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. J.P. Morgan Chase & Co. Sandelman Software Works Fraunhofer SIT The Capital Index LLC There is a large class of "RATS-Unaware" Relying Parties (RUPs) that Attesters nevertheless need to interoperate with. Existing deployed services, which precede the introduction of Remote Attestation, are often difficult to change/update in significant ways due to, among other reasons, organizational friction, technological inertia, and regulatory policies. There are significant advantages if workloads can be incrementally updated in the trustworthiness of the platform, without disrupting their clients and servers. This document describes an architecture by which Remote Attestation is utilized for providing Attesters with Identity Documents (keys or credentials) to authenticate to RUPs. This architecture is intended to work with common credential acquisition protocols and mechanisms such as EST, SPIFFE/SPIRE, ACMEv2, and many others. Another important but separate goal is to encapsulate the Attester- side complexity of Remote Attestation and credential acquisition. This allows Attesters to be implemented in a way that abstracts away the details of credential acquisition: both the protocols used and the Credential Acquisition Mechanisms employed, whether minting new (Enrollment), or requesting existing (Retrieval) credentials. Likewise, the choice between RATS Passport and Background Check models is made opaque to the Attester, further simplifying its development. Ping Identity Palo Alto Networks Defakto Security Independent Zscaler The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the credentials that workloads use to represent their identity. They can be used in various protocols to authenticate workloads to each other. To use these credentials, workloads must provide proof of possession of the associated private key material, which is covered in other documents. This document focuses on the credentials alone, independent of the proof-of- possession mechanism. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK] JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807. Confidential Computing Consortium Trustworthy Workload Identity SIG Confidential Computing Consortium Trustworthy Workload Identity SIG

Example Messages These examples are informative. They are exchanges recorded on 29 October 2026 between an EST Client and an EST Server that implement this profile, on an AMD SEV-SNP guest, with the mandatory CEK suite. The Targets, the Handles and the structures are as they crossed the wire, with long base64url values shortened to their first 24 characters and marked .... An EST Server that uses a path segment of Section 3.2.2 of serves the same resources under it, /.well-known/est/arbitraryLabel1/attest-initiate for instance. The Host header names the EST Server as this document's examples do. Lines longer than 69 characters are folded as describes.

attest-initiate for Enrollment

attest-enroll

attest-initiate for Retrieval

attest-retrieve

Acknowledgments The authors thank the Confidential Computing Consortium's Trustworthy Workload Identity (TWI) Special Interest Group (, ) for creating the TACRA architecture.