Automated Certificate Management Environment (ACME) Remote Attestation Identifier and Challenge Type

1.1. 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 [RFC8555] 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, Section 2.1 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?¶

1.2. 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?¶

[CSRATT] 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 [CSRATT] 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.¶

[RATSPA] defines a summary of a local assessment of posture for managed systems and across various layers. The claims and mechanisms defined in [RATSPA] are a good basis for the assessment that will need to be done in order to satisfy the trustworthiness challenge detailed in this document.¶

2.1. '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 Section 4.¶

type (required, string):

The string "remote-attestation".¶

value (required, string):

A string from the ACME Attest Claims Hint Registry defined in Section 4, 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?¶

2.2. 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 [I-D.ietf-rats-msg-wrap] which MAY contain remote attestation data in any defined CMW format, including: EAT [RFC9711], WebAuthn (cite), TPM attest_certify (?cite), PKIXKeyAttesation [RATSKA]. 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.¶

3.1. Step 1: newOrder Request Object

During the certificate order creation step, the Client sends a /newOrder JWS request (Section 7.4 of [RFC8555]) 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 Section 4.¶

An example extended newOrder JWS request:¶

  POST /acme/new-order HTTP/1.1
  Content-Type: application/json
  {
    "protected": base64url({
      "alg": "ES256",
    }),
    "payload": base64url({
      "identifiers": [
        { "type": "dns", "value": "client01.finance.example" },
        { "type": "remote-attestation", "value": "measured-boot" },
        { "type": "remote-attestation", "value": "hsm" },
      ],
    }),
    "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"
  }

3.2. Step 2: Order Object

As explained in [RFC8555], Section 7.1.3, the server returns an Order Object.¶

An example extended Order Object that includes confirmation that this order will include remote attestation:¶

  POST /acme/new-order HTTP/1.1
  ...

  HTTP/1.1 200 OK
  Content-Type: application/json
  {
    "status": "pending",

    "identifiers": [
        { "type": "dns", "value": "client01.finance.example" },
        { "type": "remote-attestation", "value": "measured-boot" },
        { "type": "remote-attestation", "value": "hsm" },
    ],

    "authorizations": [
      "https://example.com/acme/authz/PAniVnsZcis",
      "https://example.com/acme/authz/C1uq5Dr+x8GSEJTSKW5B",
      "https://example.com/acme/authz/01jcCDfT0iJBmUlaueum",
    ],

    "finalize": "https://example.com/acme/order/T..fgo/finalize",
  }

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

3.3. Step 3: Authorization Object

The Client MUST complete the authorizations provided by the server, but it MAY do so in any order [RFC8555].¶

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 [RFC8555], Section 8. The C1uq5Dr+x8GSEJTSKW5B authorization corresponds to the remote-attestation "measured-boot" identifier.¶

Here is an example remote-attest-01 challenge:¶

   GET https://example.com/acme/authz/C1uq5Dr+x8GSEJTSKW5B HTTP/1.1
   ..

   HTTP/1.1 200 OK
   Content-Type: application/json
   {
     "status": "pending",
     "expires": "2025-09-30T14:09:07.99Z",

     "identifier": {
       "type": "remote-attestation",
       "value": "measured-boot"
     },

     "challenges": [
       {
         "type": "remote-attest-01",
         "url": "https://example.com/acme/chall/prV_8235AD9d",
         "status": "pending",
         "freshness_nonce": "yoW1RL2zPBzYEHBQ06Jy",
         "attestClaimsHint": ["hwmodel", "swversion", "submods", "manifests",],
         "verifierEncryptionCredential": "https://example.com/acme/ra-encr-keys/_fyg_W85yTul8zDPygcIgKmj-xA",
       }
     ],
   }

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

"attestClaimsHint": ["hwmodel", "swversion", "submods", "manifests",],

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

3.4. 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 [I-D.ietf-rats-msg-wrap], 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 [RFC9711], TPM-CHARRA [RFC9684], or X, or Y (XXX: insert more options)¶

Assume the following binary blob is Remote Attestation evidence collected by the Client:¶

yePAuQj5xXAnz87/7ItOkDTk5Y4syoW1RL2zPBzYEHBQ06JyUvZDYPYjeTqwlPszb9Grbxw0UAEFx5DxObV1

This result is sent as a POST to https://example.com/acme/chall/prV_8235AD9d¶

   POST https://example.com/acme/chall/prV_8235AD9d HTTP/1.1
   ..
   Content-Type: application/cmw+cbor

   yePAuQj5xXAnz87/7ItOkDTk5Y4syoW1RL2zPBzYEHBQ06JyUvZDYPYjeTqwlPszb9Grbxw0UAEFx5DxObV1

(EDIT: change to cwm+jws example that wraps the example binary blob)¶

Alternatively, the Client MAY use the JWE format [RFC7516] to encrypt the remote attestation data for the Server's verifierEncryptionCredential and instead send a POST like this:¶

   POST https://example.com/acme/chall/prV_8235AD9d HTTP/1.1
   ..
   Content-Type: application/jwt

   eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkEyNTZHQ00ifQ.RYSEVOaD[snip]wwEbtY96_8P3a_A.5QLBf5hAXCkP7CdS.XBiai[snip]RWz1D3f.kCIIMWMoObyekuQ33u0oYQ

('[snip]' indicates that the JWE has been truncated for publication.)¶

The Server decodes the provided CMW [I-D.ietf-rats-msg-wrap].¶

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

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

3.6. Step 6: Finalize Order, retrieve certificate

At this point, the process continues as described in Section 7.4 of [RFC8555]. This means that the finalize action is used, which includes a CSR. If all is well, it will result in a certificate being issued.¶

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

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

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

5.4. 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 [CABF-CSBRs] which can be attested for example via [RATSKA].¶

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

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

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

8.1. Normative References

[RFC8555]

Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, <https://www.rfc-editor.org/rfc/rfc8555>.

[RFC9334]

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

[I-D.ietf-rats-msg-wrap]

Birkholz, H., Smith, N., Fossati, T., Tschofenig, H., and D. Glaze, "RATS Conceptual Messages Wrapper (CMW)", Work in Progress, Internet-Draft, draft-ietf-rats-msg-wrap-23, 11 December 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-msg-wrap-23>.

[I-D.ietf-rats-ar4si]

Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V. Scarlata, "Attestation Results for Secure Interactions", Work in Progress, Internet-Draft, draft-ietf-rats-ar4si-09, 15 August 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-ar4si-09>.

[RFC7519]

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

[RFC9711]

Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, <https://www.rfc-editor.org/rfc/rfc9711>.

[RFC7517]

Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/rfc/rfc7517>.

[RFC7516]

Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <https://www.rfc-editor.org/rfc/rfc7516>.

8.2. Informative References

[CSRATT]

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

[RATSPA]

Moriarty, K., Wiseman, M., Stein, A. J., and C. Nelogal, "Remote Posture Assessment for Systems, Containers, and Applications at Scale", Work in Progress, Internet-Draft, draft-ietf-rats-posture-assessment-03, 7 July 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-posture-assessment-03>.

[RATSKA]

Ounsworth, M., Fiset, J., Tschofenig, H., Birkholz, H., Wiseman, M., and N. Smith, "Evidence Encoding for Hardware Security Modules", Work in Progress, Internet-Draft, draft-ietf-rats-pkix-key-attestation-03, 1 March 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-pkix-key-attestation-03>.

[I-D.draft-bweeks-acme-device-attest-01]

Weeks, B., "Automated Certificate Management Environment (ACME) Device Attestation Extension", Work in Progress, Internet-Draft, draft-bweeks-acme-device-attest-01, 7 August 2022, <https://datatracker.ietf.org/doc/html/draft-bweeks-acme-device-attest-01>.

[letsencrypt]

Electronic Frontier Foundation, "Celebrating Ten Years of Encrypting the Web with Let's Encrypt", 20 August 2025, <https://www.eff.org/deeplinks/2023/08/celebrating-ten-years-encrypting-web-lets-encrypt>.

[CABF-CSBRs]

CA/BROWSER FORUM, "Baseline Requirements for Code-Signing Certificates", n.d., <https://cabforum.org/working-groups/code-signing/documents/>.

[RFC9684]

Birkholz, H., Eckel, M., Bhandari, S., Voit, E., Sulzen, B., Xia, L., Laffey, T., and G. C. Fedorkow, "A YANG Data Model for Challenge-Response-Based Remote Attestation (CHARRA) Procedures Using Trusted Platform Modules (TPMs)", RFC 9684, DOI 10.17487/RFC9684, December 2024, <https://www.rfc-editor.org/rfc/rfc9684>.