Use of Remote Attestation with Certification Signing Requests#

M. Ounsworth, H. Tschofenig, H. Birkholz, M. Wiseman, N. Smith (LAMPS WG)

• Why: CAs increasingly must verify policy compliance before issuance — e.g., that a CSR's private key lives in an HSM and is non-exportable. Today that's a zoo of proprietary attestation mechanisms. This standardizes carrying attestation evidence inside PKCS#10/CRMF, which matters for anyone automating certificate issuance for workloads and devices.
• What: ASN.1 structures carrying attestation data in CSRs, supporting both standardized (RATS-family) and proprietary attestation formats. WG draft at -22/-23: a design team (formed to break an author stalemate over design options) did a deep editorial pass; the Attestation OID registry was removed in -23; two PRs remain open (one debating whether a "Hint" should become a full CMS Attribute — the authors lean toward dropping hints entirely; one revisiting ASN.1 choices).
• How: Attestation evidence is generated, transmitted in the CSR, and verified by the CA as part of issuance policy (from abstract plus status slides; the precise ASN.1 details are still in flux per the open PRs).
• Where applicable: Any PKI where issuance is gated on key-protection or environment properties — HSM-bound keys, device identity, workload certificates. Mature WG draft (years in progress, design-team-reviewed) — on the path to last call but not there yet.