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

Peter Chunchi Liu (Huawei), Mike Ounsworth (Cryptic Forest Software), Michael Richardson (Sandelman Software Works), Ganesh Mallaya (AppViewX), Sven Rajala (Keyfactor).

• Why: Where device attestation meets automated certificate issuance: enterprises increasingly want to issue client (and server) certificates only to devices that can prove their posture — measured boot, HSM-held keys, MDM registration — and ACME had no standardized way to ask.
• What: A WG document (-03) defining a remote-attestation identifier type whose value is a property hint (measured-boot, hsm, …) rather than a real identifier, plus a remote-attest-01 challenge answered with a RATS Conceptual Message Wrapper (CMW) in any supported format (EAT, WebAuthn, TPM). The challenge object carries a freshnessNonce, an optional attestClaimsHint listing claims the server wants attested, and a verifierEncryptionCredential (JWK) so sensitive evidence can be JWE-encrypted in transit. The design supports both the RATS Passport model (attestation-result-01, mandatory to implement) and Background Check model (encrypted evidence), and is explicitly supplemental — the client still satisfies DNS-01/HTTP-01 for the identifiers that go into the certificate.
• How: A pseudo-identifier plus challenge/response in the existing ACME order flow; verification and appraisal policy remain the CA's business.
• Where applicable: Enterprise client certs, WiFi/EAP-TLS onboarding, BYOD S/MIME, code-signing keys in HSMs. Complementary to (broader than) the WebAuthn-based ACME Device Attestation extension; also worth reading alongside V-PEA below, which generalizes the same WHAT+environment idea.