ACME

IETF 125 - ACME Working Group Meeting Minutes

Summary

The ACME Working Group met at IETF 125 to discuss the status of active drafts and several new proposals. Key highlights included the resolution of registry issues for device attestation, a consensus on simplifying profile advertisements to URLs, and a decision to split the public key challenges proposal into two separate work items. The group also explored using ACME for persistent DNS validation and individual identity validation using electronic passports (EMRTD).

Key Discussion Points

Working Group Status and Document Updates

RFC Published: RFC 9491 (DTN Node ID) has been published.
draft-ietf-acme-integrations: Currently in missref status pending draft-ietf-anima-rfc8366bis.
draft-ietf-acme-device-attest: Completed IETF Last Call. Richard Salz (Designated Expert) noted that the draft lacked specific registry definitions for identifiers in new order requests. The authors are implementing these structural changes before publication.
draft-ietf-acme-client: Kathleen Moriarty is seeking co-authors for further updates to this draft.

ACME Profiles

Presentation: ACME Profiles update for IETF 125 Presenter: Aaron Gable

Changes in draft-01: The requirement for servers to reject unadvertised profiles was weakened from "MUST" to "SHOULD" to allow for pre-negotiated private profiles.
Metadata Structure: Discussion centered on how to advertise profiles in the directory meta. Proposals included structured dictionaries or arrays for documentation.
Consensus: Richard Salz, Sean Turner, and Corey Bonnell suggested that the most robust approach is to restrict profile values to URLs. If human-readable text is needed, data URIs (e.g., data:text/plain,...) can be used.

ACME-RATS (Remote Attestation)

Presentation: Automated Certificate Management Environment (ACME) Remote Attestation Identifier and Challenge Type Presenter: Peter

Design Choice: Remote attestation is designed to supplement existing identifier challenges (e.g., DNS-01) rather than replace them. This ensures that a client proves both control of an identifier and the security properties of the hardware.
Freshness Nonce: There was a discussion regarding whether to reuse the ACME HTTP nonce. Aaron Gable and the chat consensus favored an independent freshness nonce/token provided within the challenge object, similar to existing challenge types.
Next Steps: The design team will continue regular meetings and focus on Proof of Concept (POC) development.

DNS Persist

Presentation: draft-ietf-acme-dns-persist Presenter: Shilo

Updates: Decoupled the account URI from the challenge object and renamed the Authorization Domain Name (ADN) to "Validation Domain Name" to align with CA/Browser Forum terminology.
Subdomain Validation: Discussion on how to handle ancestor records to avoid excessive DNS queries. Fabian (Google) noted potential overlap with RFC 9444.
TTL Ceiling: The authors decided to remove the TTL ceiling as a validation reuse limit, as TTL is intended for caching rather than business logic.
IP Validation: Strong support was expressed for including IP validation via reverse DNS (aligned with CA/B Forum SC-91) within the same draft.

Public Key Challenges

Presentation: ACME Extension for Public Key Challenges (slides) Presenter: Pan

Goal: Removing the mandatory Requirement for Certificate Signing Requests (CSRs) in web PKI and supporting non-web PKI (IoT/Enterprise) via Proof of Possession (PoP).
Architecture: Richard Salz raised concerns about conjoining identifier validation with public key validation and the potential loss of security properties (e.g., unknown key issuer attacks) if the signature doesn't cover intended identifiers.
Consensus: The work will be split into two drafts:
1. A baseline draft for CSR removal and Public Key PoP.
2. A separate draft for the Opaque protocol and password-based recovery use cases.

EMRTD (Electronic Passports)

Presentation: emrtd-data-01 Presenter: Mike McBride (on behalf of Sebastian)

Concept: Utilizing the NFC chips in machine-readable travel documents (e-passports) as a source of automated identity validation.
Use Case: Aaron Gable clarified that the likely primary use case is Individual Validation (IV) certificates (e.g., S/MIME or code signing) by allowing ACME servers to cryptographically verify passport data.
Implementation: The draft is currently a proposal. Mike McBride will assist the author in onboarding the document to the IETF datatracker.

Decisions and Action Items

draft-ietf-acme-profiles: Aaron Gable to publish draft-ietf-acme-profiles-02 restricting profile metadata values to URLs.
draft-ietf-acme-dns-persist: Authors to remove TTL validation ceiling and incorporate IP validation via reverse DNS in the next revision.
draft-ding-acme-pubkey: Authors to split the proposal into two distinct drafts (CSR-less baseline and Opaque/password-based issuance).
EMRTD Proposal: Mike McBride to help the author format and upload the draft to the IETF datatracker.

Next Steps

Initiate Working Group Last Call (WGLC) for draft-ietf-acme-profiles once version -02 is published.
Continue design team meetings for draft-ietf-acme-rats.
Seek co-authors and implementers for the EMRTD and ACME Client work.

Automatic IETF Minutes