]> Huawei

liuchunchi@huawei.com

Cryptic Forest Software, Ltd

mike@ounsworth.ca

Sandelman Software Works Inc

mcr+ietf@sandelman.ca

AppViewX, Inc

ganesh.mallaya@appviewx.om

Security Automated Certificate Management Environment ACME Remote Attestation Zero Trust This document describes an approach where an ACME Server can challenge an ACME Client to provide Evidence, Endorsements, or Attestation Result according to the Remote ATtestation procedureS (RATS) framework in any format supported by the Conceptual Message Wrapper (CMW). The ACME Server can optionally challenge the Client for specific claims that it wishes attestation for. About This Document 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 Automated Certificate Management Environment Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction ACME is a standard protocol for issuing and renewing certificates automatically. When an ACME client needs a certificate, it connects to the ACME server, providing a proof of control of a desired identity. Upon success, it then receives a certificate with that identity in it. These identities become part of the certificate, usually a Fully Qualified Domain Name (FQDN) that goes into the Subject Alt Name (SAN) for a certificate. Prior to ACME, the authorization process of obtaining a certificate from an operator of a (public) certification authority was non-standard and ad-hoc. It ranged from sending faxes on company letterhead to answering an email sent to a well-known email address like hostmaster@example.com, evolving into a process where some randomized nonce could be placed in a particular place on the target web server. The point of this process is to prove that the given DNS FQDN was controlled by the same client system initiating the certificate request. ACME standardized the process of proving domain control, allowing for full automation of certificate issuance. It has been a massive success: increasing HTTPS usage from 27% in 2013 to over 80% in 2019 . While the ACME process supports many kinds of identifiers such as email addresses and DTN node IDs, and other client-type identifiers, ACME for client certificates has not yet become as popular, in part because these types of certificates are usually located on much more general purpose systems such as laptops and computers used by people in which there is no standardized automated way to perform proof of control. In addition to proving control of an identifier, a major concern that enterprises have with the use of client certificates has been the trustworthiness of the client system itself. Such systems have many more configurations, and are often harder to assess the security posture of as a result. While well managed mutual TLS (client and server authentication via PKIX certificate) has significant advantages over the more common login via username/password, if the private key associated with a client certificates is disclosed or lost, then the impact can be more significant. One use case envisioned here is that of client devices within an enterprise. A Network Operations Center (NOC) (which may be internal or an external contracted entity) will issue (client) certificates to devices that can prove via remote attestation that they are running an up-to-date operating system as well as the enterprise-required endpoint security software. Another use case envisioned is issuance of server certificates, for example TLS certificates or code-signing certificates, where the Certification Authority (CA) requires, in addition to proof of control of the identifiers, some proof about the security posture of the operating environment, such as how the private key is stored, or the running environment of the server application. This is a place where Remote Attestation Procudures (RATS) can offer additional assurance. Remote Attestation provides a framework as well as an emerging ecosystem of standardized data formats and tools for a device to provide a remote peer with proof of various system properties in the form of measured evidence and third-party endorsements. ACME servers can leverage the Remote Attestation ecosystem either by directly consuming evidence and endorsements, or by having a third-party verifier assess the evidence and endorsements and produce an attestation result which is then provided to the ACME server. In this document, we propose an extension to the ACME protocol where ACME Server MAY challenge the ACME Client to produce an Attestation Evidence or Attestation Result in any format that is supported by the RATS Conceptual Message Wrapper , for instance, an EAT (entity attestation token). The ACME Server then verifies the attestation result against an appraisal policy as required by the requested certificate profile. Essentially, this provides a mechanism for the ACME server to challenge for and transport Remote Attestation data, but it leaves out-of-scope how the ACME server verifies the provided data according to its certificate profiles. Remote Attestation can in some cases provide proof of control of an identifier, such as a hardware serial number or a cryptographic public key, but in general Remote Attestation will be at a lower level than the identifier going into the certificate such as a FQDN or an email address. Therefore the design of this extension does not replace the identity challenges in the ACME protocol, but acts supplementally to it. ACME can presently offer certificates with multiple identities. Typically, in a server certificate situation, each identity represents a unique FQDN that would be placed into the certificate as distinct Subject Alt Names (SAN). For instance each of the names: example.com, www.example.com, www.example.net and marketing.example.com might be placed in a single certificate for a server that provides web content under those four names. This document defines a new identity type, trustworthy that the ACME client can ask for. A new attestation-result-01 challenge is defined as a new method by which the ACME Server can challenge the Client to provide Remote Attestation according to the RATS Passport model. The attestation-evidence-02 challenge is also defined, challenging the client to provide direct evidence according to the RATS Background Check model. In this way, the Certification Authority (CA) or Registration Authority (RA) issues certificates only to devices that can provide an appropriate attestation of the required properties / claims, indicating that the device from which the ACME request originates has passed the required security checks. The term "remote attestation" covers a broad range of standardized and proprietary technologies and data formats and this specification tries to be as technology-agnostic as possible. However, it assumes that evidence could contain sensitive data and therefore needs an optional payload encryption mechanism to keep this information protected as at passes through the various layers of the ACME server and RA to a RATS Verifier, whereas attestation results are assumed to be non-sensitive and therefore do not require this extra protection. Attested ACME requests can form an essential building block towards the continuous monitoring/validation requirement of Zero-Trust principle when coupled with other operational measures, such as issuing only short-lived certificates. For ease of denotion, we omit the "ACME" adjective from now on, where Server means ACME Server and Client means ACME Client.

Design overview Conceptually, the server is challenging the client to produce remote attestation as part of the certificate enrollment flow. However, this mechanism cannot be defined simply as an ACME challenge for a number of reasons. First, the ACME protocol is designed such that a client requests a given identifier to appear in the certificate, and the server provides a list of proof-of-control challenges such as {DNS-01, HTTP-01} to which the client only needs to respond to one. The design goal here is that the remote attestation challenge supplements the identifier challenges rather than replaces them. Instead we want the behavior that the client must respond to one of {DNS-01, HTTP-01} and also provide remote attestation of the given list of attestable properties. Second, an ACME client can request multiple identifiers in a single certificate request and so ACME challenges are per identifier. By contrast, remote attestation typically applies to the entire client device or private key and is not coupled to the requested identifiers. Consider an example where a Client requests a certificate for the DNS name "client01.finance.example" and the Server wants to respond that the client can fulfill either a DNS-01 or an HTTP-01 Challenge to prove ownership of that DNS same, and also the Client must provide two separate types of remote attestation, one measuring the boot stack and device integrity where the application runs, and a separate attestation proving that the subject private key is in an HSM. The desired behavior is {DNS-01 OR HTTP-01} AND measured-boot AND hsm. The only way for the Server to issue four Challenges in ACME that behave this way is to issue the DNS-01 and HTTP-01 under the same Identifier, and the measured-boot and hsm Challenges each under their own Identifier. To achieve this, introduces a new ACME Identifier type "remote-attestation" which is not really an identifier, but instead conveys the general type of attestation required. EDNOTE: there will be cases where the attestation does act as proof-of-control of an identifier, such as validating a Serial Number DN component. So do we want to allow attestation-result-01 and attestation-evidence-01 to be used within any identifier so that you can say DNS-01 or HTTP-01 or remote-attestation for cases where that makes sense?

Related work TODO: need a compare & contrast with draft-ietf-acme-device-attest. @Ganesh, you're an author on both, could you write this text? define a mechanism for carrying arbitrary remote attestation data within a certificate signing request (CSR) object (PKCS#10 or CRMF). Since ACME internally uses PKCS#10 CSRs, this provides an alternate mechanism for carrying remote attestation within ACME. This specification provides additional functionality that cannot be achieved via attested CSRs, namely giving the ACME server a way to challenge the client not only for attestation, for for attestation of specific properties. It also decouples the attestation from the CSR, which future-proofs this mechanism in case CSR is removed as a mandatory part of the ACME protocol at some future time. That said, there is no reason that could not be combined with the mechanism described in this document; for example a client could provide an attested CSR proving protection properties of the private key within an HSM, and also respond to an ACME remote attestation challenge proving the security posture of the application stack. defines a summary of a local assessment of posture for managed systems and across various layers. The claims and mechanisms defined in are a good basis for the assessment that will need to be done in order to satisfy the trustworthiness challenge detailed in this document.

Overview

'remote-attestation' identifier A new identifier type to indicate client support or server request for remote attestation. This is a "dummy" identifier in that the value does not contain an actual identifier, but instead a property that is the be remotely attested. The value MAY be left empty, or contain a property hint as per .

type (required, string):

The string "remote-attestation".

value (required, string):

A string from the ACME Attest Claims Hint Registry defined in , which could be the empty string.

A Client MAY advertize support for multiple "remote-attestation" identifiers in the same ACME protocol flow. A Server MAY issue challenges for multiple "remote-attestation" identifiers in the same ACME protocol flow. As the Server is authoritative for the requirements to be fulfilled for the given certificate request, the Server MAY choose not to issue a Challenge for every "remote-attestation" identifier type that the Client advertized support for, and conversely, the Server MAY issue a challenge for "remote-attestation" identifiers that the Client did not advertize support for. EDNOTE: Is there any reason for the client to include "remote-attestation" identifiers in the newOrder at all?

remote-attest-01 Challenge A remote-attest-01 challenge type asks the Client to provide Evidence appropriate for making a trustworthiness decision. The Client SHOULD use the provided freshness_nonce as an attestation freshness nonce, if the Client's underlying attestation technology supports freshness nonces. The Server MAY include a attestClaimsHint containing a list of claims or specific properties that it would like to see attested. The Client MUST complete the challenge by returning a CMW which MAY contain remote attestation data in any defined CMW format, including: EAT , WebAuthn (cite), TPM attest_certify (?cite), PKIXKeyAttesation . It may contain other RATS conceptual message types such as evidence, endorsement, or attestation result as appropriate for the mode. Since this specification allows wide flexibility on the contents of the remote attestation data, this document does not remove the need for vendors to perform interoperability testing with CAs to ensure compatibility. This section describes the challenge/response extensions and procedures to use them.

remote-attest-01 Challenge Object The remote-attest-01 Challenge Object is: The basic fields type (which MUST be "remote-attest-01"), url, status, validated and error are preserved from un-modified. The following new fields are added:

freshness_nonce (required, string):

A randomly created nonce provided by the server which MUST be included in the Attestation Results to provide freshness.

EDNOTE TODO: we should decide whether this nonce MAY / SHOULD / SHOULD NOT / MUST NOT be the same as the ACME nonce or the ACME Challenge URL.

attestClaimsHint (optional, list of string)

If the Server requires attestation of specific claims or properties in order to issue the requested certificate profile, then it MAY list one or more types of claims from the newly-defined ACME Attest Claims Hints registry defined in .

verifierEncryptionCredential (optional, JWK)

A URL where the Client can fetch the encryption public key that it can use for encrypting the remote-attestation challenge response.

The attestClaimsHint SHOULD contain values from the "JSON Web Token Claims" registry created by , in particular claims related to remote attestation as registered in and related documents, but MAY contain non-registered values. The Client SHOULD attempt to collect evidence, endorsements, or attestation results from its local environment that satisfies these claims, either directly if the local environment supports EAT , or mapped to the closest equivalent claims in the supported format. The Client MAY ignore any claims that it does not recognize or that it is unable to collect remote attestation for. In other words, the Client SHOULD return what it has rather than failing, and allow the Server to decide if it is acceptable for the requested certificate profile. The verifierEncryptionCredential is an encryption key in JSON Web Key (JWK) {!RFC7517} format that the Client can use to encrypt the attestation data that it will return. It is intended for cases where the evidence contains sensitive data the Client wishes to protect it against accidental logging, for example by HTTP proxies, as it passes through the Server's application stack. This could for example include data such as identifiers that could be linkable to a person and therefore qualify as Personally Identifiable Information, or any other detailed type of system measurement that the Client deems sensitive. The credential SHOULD be in the JSON Web Key (JWK) format, but MAY be in other reasonable formats such as a DER or PEM encoded X.509 certificate. EDNOTE: in the name of simplicity, make this "MUST JWK"? EDNOTE: We need to think carefully about whether this step needs to behave differently depending on whether the client will provide Evidence vs Attestation Result; particularly the nonces work a bit differently in the two cases. ... is it enough for the Server to always provide a nonce and just ignore it if the thing it gets back is an AR? Or maybe go even more hands-off and say "Here's a nonce field, whether and how you use it is up to the RA and its attestation Verifier" ?

remote-attest-01 Response The HTTP POST body to the challenge URL MUST be a raw JSON or CBOR CMW , base64 encoded as necessary. If the Server provided a verifierEncryptionCredential and the Client wishes to make use of it, then the entire CWM payload MUST be placed inside a JSON Web Encryption (JWE) envelope .

Example Protocol Flow

Step 1: newOrder Request Object During the certificate order creation step, the Client sends a /newOrder JWS request (Section 7.4 of ) whose payload contains an array of identifiers. To indicate support for remote attestation, the client adds one or more remote-attestation identifiers to the array of identifiers. This is entirely optional and the server MAY choose to challenge for attestation or not according to its configuration for the requested certificate profile irrespective of whether the client indicated that it is attestation-capable. The "remote-attestation" identifier MAY appear as the only identifier type in the array, but only if the supported remote attestation type is capable of proving control of the identifier(s) that will go into the certificate's CN or SANs. For example, a measured-boot style remote attestation MAY be capable of proving ownership of a hardware serial number, or a WebAuthn / FIDO / Passkey style remote attestation MAY be capable of proving control of a FIDO token belonging to a given username or email address. However, more typically the "remote-attestation" identifier serves to provide supplemental trustworthiness next to a direct proof-of-control identity challenge such as DNS-01 or HTTP-01. In this example, a client is requesting a certificate for a dns identity client01.finance.example and offers that it can provide remote attestation of the measured-boot stack of the application server via the remote-attestation identifier "measured-boot", as well as provide remote attestation from the underlying cryptographic hardware holding the private key via the remote-attestation identifier "hsm". These values refer to the ACME Attest Properties Hint Registry defined in . An example extended newOrder JWS request:

Step 2: Order Object As explained in , the server returns an Order Object. An example extended Order Object that includes confirmation that this order will include remote attestation: The server is not required to match the list of remote-attestation identifiers provided by the client. The server MAY challenge for a subset of the remote-attestation identifiers offered by the client, or it MAY challenge for remote-attestation identifiers that were not offered by the client. The server has full discretion for deciding what properties are required to be attested for the requested certificate profile.

Step 3: Authorization Object The Client MUST complete the authorizations provided by the server, but it MAY do so in any order . In this example, the Server has created an Authorization Object for the "remote-attestation" and "dns" identifiers. The client accesses each authorization object from the URLs given in the Order Object. In this example, the PAniVnsZcis authorization relates to the dns identifier, and it is not changed from . The C1uq5Dr+x8GSEJTSKW5B authorization corresponds to the remote-attestation "measured-boot" identifier. Here is an example remote-attest-01 challenge: EDNOTE: TODO: check 8555 if "token" is mandatory, and if so, use that to carry the attestation freshness nonce. In this example, the Server is indicating that it wants a remote attestation result including the following claims: meaning that it is interesting in the type of device and what software is running on it. This field is called a "hint" because the ACME Client might not be capable of obtaining remote attestation evidence, endorsements, or attestation results that directly map to these claims. Servers SHOULD NOT we written to expect exactly these claims back. This mechanism does not remove the need for vendors to perform interop testing against CAs. EDNOTE: is the attestClaimsHint actually adding anything useful on top of the identifier values of "measured-boot", "hsm", "passkey", etc?

Step 4: Respond to Remote Attestation Challenge The client now queries its local environment to obtain evidence, endorsements and/or attestation results to satisfy the Remote Attestation challenge. If the underlying remote attestation technology supports a freshness nonce, then the Client passes the (example) token yoW1RL2zPBzYEHBQ06Jy into the underlying attestation service as the nonce. The payload of the Remote Attestation Challenge response MUST be a CMW , but the underlying payload type within the CMW is left unconstrained and therefore the details of collecting the remote attestation data for this this step are not in scope for this document. As an example, it might use EAT , TPM-CHARRA , or X, or Y (XXX: insert more options) Assume the following binary blob is Remote Attestation evidence collected by the Client: This result is sent as a POST to https://example.com/acme/chall/prV_8235AD9d (EDIT: change to cwm+jws example that wraps the example binary blob) Alternatively, the Client MAY use the JWE format to encrypt the remote attestation data for the Server's verifierEncryptionCredential and instead send a POST like this: ('[snip]' indicates that the JWE has been truncated for publication.) The Server decodes the provided CMW . The Server MUST perform a full verification of the remote attestation data, including verification of the signature against a pre-configured trust anchor, and appraisal according to a suitable appraisal policy. The CA's certificate policy is the final authority for what trust anchors and appraisal policies will apply and the details are not in scope for this document. At this point, if the client were to re-retrieve the authorization object from step 3, it would observe (if everything was accepted and successfully verified) that the status for this challenge would now be marked as valid.

Step 5: Perform other challenges The client SHOULD now perform any other Remote Attestation or non-Remote Attestation challenges that were listed in the Order Object from step 2. ACME provides no ordering constraint on the challenges, so the Client MAY process them in any order, including concurrently.

Step 6: Finalize Order, retrieve certificate At this point, the process continues as described in . This means that the finalize action is used, which includes a CSR. If all is well, it will result in a certificate being issued.

ACME Attest Properties Hint Registry In order for the client to communicate in the newOrder request what types of attestation it is capable of producing, and for the server to indicate in the newOrder response what properties it requires attestation of, this specification creates a new IANA registry called "ACME Attest Properties Hint Registry. The hint is used as the value of the "remote-attestation" identifier type, as described in {#new-order-req} and {#new-order-resp}. In order to preserve vendor flexibility, the initial values in the ACME Attest Properties Hint Registry are intended to be generic in nature, and decoupled from the RATS conceptual message type (evidence, endorsement, or attestation result) or attestation data format (EAT (cite), WebAuthn (cite), TPM attest_certify (cite), PKIXKeyAttestation (cite), or device-proprietary). This model expects CAs to publish documentation about what specific data formats they support, and for vendors to perform interoperability testing with CAs to ensure compatibility. Ultimately, the CA's certificate policies will be the authority on what evidence or attestation results it will accept. The ACME Attest Claims Hint Registry is intended to help clients to collect evidence or attestation results that are most likely to be acceptable to the server, but are not a guaranteed replacement for performing interoperability testing between a given attesting device and a given CA. Similarly, an ACME attestation hint may not map one-to-one with attestation functionality exposed by the underlying attesting device, so ACME clients might need to act as intermediaries mapping ACME hints to vendor-specific functionality on a per-hardware-vendor basis. See for the initial contents of this new registry.

Example use cases

Conflicting duties (EDIT: This text might be stale)

1. Integration/compatibility difficulty: Integrating SOC and NOC requires plenty of customized, case-by-case developing work. Especially considering different system vendors, system versions, different data models and formats due to different client needs... Let alone possible updates.
2. Conflict of duties: NOC people do not want SOC people to interfere with their daily work, and so do SOC people. Also, NOC people may have limited security knowledge, and SOC people vice versa. Where to draw the line and what is the best tool to help them collaborate is a question.

Enterprise WiFi Access In enterprise access cases, security administrators wish to check the security status of an accessing end device before it connects to the internal network. Endpoint Detection and Response (EDR) softwares can check the security/trustworthiness statuses of the device and produce an Attestation Result (AR) if the check passes. ACME-RA procedures can then be used to redeem a certificate using the AR. With that being said, a more specific use case is as follows: an enterprise employee visits multiple campuses, and connects to each one's WiFi. For example, an inspector visits many (tens of) power substations a day, connects to the local WiFi, download log data, proceed to the next and repeat the process. Current access solution include: 1. The inspector remembers the password for each WiFi, and conduct the 802.1X EAP password-based (PAP/CHAP/MS-CHAPv2) authentication. or 2. an enterprise MDM receives the passwords and usernames over application layer connection from the MDM server, and enter them on user's behalf. While Solution 1 obviously suffer from management burdens induced by massive number of password pairs, and password rotation requirements, the drawback of Solution 2 is more obsecure, which include: a. Bring Your Own Device (BYOD) situation and MDM is not available. b. Password could risk leakage due to APP compromise, or during Internet transmission. Anyone with leaked password can access, without binding of trusted/usual devices. c. The RADIUS Client/Access Point/Switch is not aware of the identity of the accessing device, therefore cannot enforce more fine-grained access policies. An ideal user story is: 1. When the inspector is at base (or whenever the Remote Attestation-based check is available), he get his device inspected and redeem a certificate using ACME-RA. 2. When at substation, the inspector authenticate to the WiFi using EAP-TLS, where all the substations have the company root CA installed. 2*. Alternatively, the Step 2 can use EAP-repeater mode, where the RADIUS Client redirects the request back to the RADIUS Server for more advanced checks.

BYOD devices Another example is issuing S/MIME certificates to BYOD devices only if they can prove via attestation that they are registered to a corporate MDM and the user they are registered to matches the user for which a certificate has been requested. In this case, the Server might challenge the client to prove that it is properly-registered to the enterprise to the same user as the subject of the requested S/MIME certificate, and that the device is running the corporate-approved security agents.

Private key in hardware In some scenarios the CA might require that the private key corresponding to the certificate request is stored in cryptographic hardware and non-extractable. For example, the certificate profile for some types of administrative credentials may be required to be stored in a token or smartcard. Or the CA might be required to enforce that the private key is stored in a FIPS-certified HSM running in a configuration compliant with its FIPS certificate -- this is the case, for example, with CA/Browser Forum Code Signing certificates which can be attested for example via . It could also be possible that the requested certificate profile does not require the requested key to be hardware-backed, but that the CA will issue the certificate with extra assurance, for example an extra policy OID or a longer expiry period, if attestation of hardware can be provided.

Security Considerations The attestation-result-01 challenge (the Passport Model) is the mandatory to implement. The encrypted-evidence-01 challenge (the background-check model) is optional. In all cases the Server has to be able to verify Attestation Results from the Verifier. To do that it requires appropriate trust anchors. In the Passport model, Evidence -- which may contain personally identifiable information (PII)) -- is never seen by the ACME Server. Additionally, there is no need for the Verifier to accept connections from ACME Server(s). The Attester/Verifier relationship used in the Passport Model leverages a pre-existing relationship. For instance if the Verifier is operated by the manufacturer of the Attester (or their designate), then this is the same relationship that would be used to obtain updated software/firmware. In this case, the trust anchors may also be publically available, but the Server does not need any further relationship with the Verifier. In the background-check model, Evidence is sent from the Attester to the ACME Server. The ACME Server then relays this Evidence to a Verifier. The Evidence is encrypted so that the Server it never able to see any PII which might be included. The choice of Verifier is more complex in the background-check model. Not only does ACME Server have to have the correct trust anchors to verify the resulting Attestation Results, but the ACME Server will need some kind of business relationship with the Verifier in order for the Verifier to be willing to appraise Evidence. The trustworthy identifier is not an actual identifier. It does not result in any specific contents to the certificate Subject or SubjectAltName.

IANA Considerations

ACME Attest Properties Hint Registry IANA is requested to open a new registry, XXXXXXXX Type: designated expert The registry has the following columns:

• Property Hint: the string value to be placed within an ACME identifier of type "remote-attestation".
• Description: a description of the general property which the client is expected to attest.

The initial registry contents is shown in the table below.

Property Hint	Description
""	Empty string. Indicates client support for, or a server request for, attestation without being specific about what type. Typically this means the client will produce whatever remote attestation data it is capable of.
"hsm"	Attestation that the private key associated with this certificate request is stored in cryptographic hardware such as a TPM or PKCS#11 HSM. In the case of PKCS#11 HSMs, the attestation SHOULD contain the PKCs#11 properties of the private key storage, as well as an indication of whether the cryptographic module is operating in FIPS mode.
"measured_boot"	Attestation from the device's onboard measured-boot stack of the device running the application.
"os_patch_level"	Attestation to the version or patch level of the device's operating system.
"sw_manifest"	A manifest list of all software currently running on the device.
"fido2"	A request for FIDO2-based user authentication; maybe this is to validate a user identifier directly against the FIDO2 data, or maybe this serves as a second-factor to the CA's certificate pickup flow.

In general, the target environment that the Server wants to be remotely attested is the environment where the application is running. The "hsm" property is an exception to this because this wants attestation from the cryptographic module instead. In cases where the ACME client is running on a different host from the application, remote attestation always refers to the application host. In other words, a centralized ACME client MUST fulfill the ACME-RA challenge by getting the application server that will ultimately use the certificate to query its local environment for remote attestation, and the ACME client MUST NOT present remote attestation from the host where it is running. EDNOTE: I am somewhat surprised that a registry like this does not already exist associated with CMW.

References Normative References Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. 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. Fraunhofer SIT Independent Linaro University of Applied Sciences Bonn-Rhein-Sieg Google LLC The Conceptual Messages introduced by the RATS architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during remote attestation procedures. Conceptual Messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of Conceptual Messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated CBOR tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. This allows CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts like X.509 certificates. Additionally, the draft defines a media type and a CoAP content format to transport CMWs over protocols like HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, evolving message serialization formats without breaking compatibility, and avoiding the need to redefine how messages are handled within each protocol. Cisco Systems Fraunhofer SIT MIT Linaro Intel This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogeneous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party. This document also defines two serialisations of the proposed information model, utilising CBOR and JSON. 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. An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification. Informative References 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. Transforming Information Security LLC Beyond Identity Dell Technologies This document establishes an architectural pattern whereby Attestation Results could be produced for a complete set of benchmarks or controls that are defined and grouped by an external entity, eliminating the need to convey individual Evidence items for each item within a benchmark or control framework. This document establishes a pattern to list sets of benchmarks and controls within CWT and JWT formats for use as an Entity Attestation Token (EAT). While the discussion below pertains mostly to TPM, other Roots of Trust such as TCG DICE and non-TCG defined components will also be included. Crypto4A Inc. Cryptic Forest Software University of the Bundeswehr Munich Fraunhofer SIT This document specifies a vendor-agnostic format for Evidence produced and verified within a PKIX context. The Evidence produced this way includes claims collected about a cryptographic module, such as a Hardware Security Module (HSM), and elements found within it such as cryptographic keys. One scenario envisaged is that the state information about the cryptographic module can be securely presented to a remote operator or auditor in a vendor-agnostic verifiable format. A more complex scenario would be to submit this Evidence to a Certification Authority to aid in determining whether the storage properties of this key meet the requirements of a given certificate profile. This specification also offers a format for requesting a cryptographic module to produce Evidence tailored for expected use. Google This document specifies new identifiers and a challenge for the Automated Certificate Management Environment (ACME) protocol which allows validating the identity of a device using attestation. Electronic Frontier Foundation CA/BROWSER FORUM n.d. This document defines the YANG Remote Procedure Calls (RPCs) and configuration nodes that are required to retrieve attestation evidence about integrity measurements from a device, following the operational context defined in RFC 9683 "TPM-based Network Device Remote Integrity Verification". Complementary measurement logs originating from one or more Roots of Trust for Measurement (RTMs) are also provided by the YANG RPCs. The defined module requires the inclusion of the following in the device components of the composite device on which the YANG server is running: at least one Trusted Platform Module (TPM) of either version 1.2 or 2.0 as well as a corresponding TPM Software Stack (TSS), or an equivalent hardware implementation that includes the protected capabilities as provided by TPMs as well as a corresponding software stack.

Acknowledgments TODO acknowledge.