ACME WG Agenda at IETF 124

2025-11-04 13:30-15:30 CST

Housekeeping

• Notewell read
• Minute Takers: Aaron Gable, John Gray
• Chat monitor: Yoav Nir

Agenda Bash

• Peter Liu asks that ACME RATS go last due to scheduling conflict

With IESG

• draft-ietf-acme-dtnnodeid
• draft-ietf-acme-integrations
• draft-acme-device-attest

Adopted Drafts

draft-ietf-acme-dns-persist – Shiloh Heurich

• Adopted on Oct 16, 2025

• Implementation status update:

  • CA/BF passed ballot SC-088v3 on Oct 9, 2025

    • Expect IP Review period to complete Nov 8, 2025

  • Fastly/Certainly in 2026

  • Let's Encrypt in 2026
  • Google Trust Services in 2026
  • Amazon Trust Services may do the same
  • PoC implementations in Pebble server and xx client

• Changes since IETF 123:

  • Added "just-in-time" validation, where CA can check record
    without requiring client to POST to the challenge endpoint
  • Expanded Security Considerations
  • Improved

• CAs can use SC-088v3 outside of ACME

  • But standardizing here will allow widespread adoption

• Trades freshness for operational simplicity

  • ACME account key is a long-lived credential to protect

• Validation Reuse

  • Takes TTL of DNS record into account, similar to CAA
  • Also exposes an optional persistUntil parameter

• DNSSEC

  • Discussion on SHOULD vs MUST validate

    • Corey Bonnell suggests it remain a SHOULD
    • Deb Cooley concurrs, but says the doc must clarify when it's
      okay to violate that SHOULD, or IESG will get sad

  • Trades off security vs private PKI flexibility

• Seeking working group input:

  • DNSSEC requirement?
  • Security Considerations
  • Timeline
  • (missed item)

• Tim Geoghegan: how does renewal work?

  • CA re-verifies the record; ACME renewal is just issuance

• Corey Bonnell: the syntax for controlling wildcard issuance could be
  simplified

• Michael Richardson: does the presence of a DNS Persist record affect
  whether other validation methods can be used?

  • Aaron Gable: There is a separate draft in LAMPS that establishes
    a form of CAA record. Only use these validations methods in
    order to confirm domain control validation in this subtree. The
    two drafts compliment each other.

• Stefan Ubbink: are you aware of the dnsop DNS Verification draft?

  • Yes, was non-normatively referenced in a previous draft
  • It's useful inspiration and very related, but not normatively
    used

• Deb Cooley: Why two drafts (LAMPS vs ACME) - CAA used more widely

  • Comments on SHOULD language, don't overide it elsewhere

draft-ietf-acme-profiles – Aaron Gable

• Call for adoption in August.

• Recent Changes:

  • Roles on how clients behave, some changes to MUST and SHOULD.
  • Created draft -00 after adoption
  • Implemented in two servers (pebble and boulder). Used in 7
    clients
  • Let's encrypted is actively using this, and it is very helpful
    in migrations
  • 3 step process is allowing a smooth migration process
  • Will do the same migration to 47-day validity periods. Allows
    easy brown outs

• Next Steps

  • Lets Encrypt is main contributor, would love to hear more
    feedback from other ACME operators
  • Letting the draft soak and authors expect it is very stable
  • WGLC is eventually the next step

draft-ietf-acme-dns-account-label

• No updates

New Business

draft-wendt-acme-authority-token-jwtclaimcon – Chris Wendt

• Coming from STIR WG, revitalized interest from RFC 9795
• Getting real industry adoption, referenced in FCC document

• Want to return to Call for Adoption

  • Chair note: CfA closed on 2025-09-22 with insufficient support
    for adoption. Hopefully this presentation can drum up more
    support, particularly from implementers.
  • But didn't realize history of previous support, and similarity
    to previously-published TNAuthList
  • This is mainly for STIR CA ecosystems - Russ Housely, Sean
    Turner had previously voiced support for this work

• Chair asking working group if they are willing to review the draft.
  A number of people indicated they are willing to review.

  • Based on this the document will be adopted.
  • Aaron: ACME wire-protocol looks good, but hard to review
    validation routine without knowing STIR ecosystem well??

draft-demarco-acme-openid-federation – Tim Geoghegan

• OpenID Federation is a trust hierarchy not wholly dissimilar to an
  x509 PKI, but in the JWT ecosystem

  • JWTs instead of RFC 5280 certificates
  • Trust anchor list instead of root certificate store
  • Subordinate statement instead of cross-signing

• Some orgs, e.g. European universities, want to use both at the same
  time

  • For example, RADIUS protocol uses x509 certs for auth
  • But universities already have OpenID Federation set up
  • So we want to encode that federation in an x509 cert

• Since IETF 123:

  • Improved document organization to match other ACME RFCs
  • Moved explanatory material to appendix
  • Narrowed focus to just new identifier type and challenge
  • Replaced discussion of discovery with references to OpenID docs

• Implementation status:

  • Implemented in forks of Pebble (server) and Lego (client)
  • Also a test harness for interop

• Challenge: OpenID Federation v1.0 is not yet finalized

• Some similarity to DNS Persist (delegating to another set of keys)

  • But these OpenID entities may not have DNS records at all
  • Do plan to review DNS Persist's ideas and security
    considerations

• Stefan Santesson:

  • Why do we send the OIDF trust chain in the challenge response?

    • This is risky because applicant might not know the CA's set
      of trust anchors
    • CA should use an OIDF Resolver to get this info

  • Why use a specific ACME key instead of the entity key?

    • Crypto hygiene: use different keys for each purpose
    • Defining a new entity type might cause problems down the
      line

  • Why does the client have to use OIDF to find the issuer's
    directory?

    • Holdover from the discovery portions of the draft

  • What does the embedding of the OIDF info in the cert look like?

    • Largely outside the scope of this draft
    • Not trying to define profiles, just make it possible

• Jan-Frederik Rieckers: eduroam already has a federation

  • Yes, the eduroam example is a simple hypothetical

• Mike Ounsworth: the confusing part is how validation works

  • (Similar to the JWTClaim draft above)
  • Are the certs serverauth certs? Human certs? Does it matter for
    ACME?
  • The point is to prove control over an OIDF Entity Identifier
  • Trying to keep the draft minimal to avoid redefining OIDF
    concepts
  • Mike [Chair]: The main value of bringing this draft to the
    ACME WG is to get security review of the ACME aspects by this
    group of experts. Chair asks that enough of the OIDF background
    is added so that reviewers from the PKI community can properly
    assess the security aspects. Adding a simple worked example
    might be enough.

• Kathleen Moriarty: This kind of work definitely fits in the original
  vision for ACME

• Michael Richardson: Additional use-case: third-party mechanic
  authenticating to a busted mobile tower's local network

  • Important that the resulting certificate can be validated
    offline, locally

• Stefan Santesson: Concrete use-case is the European digital wallet
  project

  • Identity information is already in OIDF, EU requires x509
  • This is the exact vehicle we need to connect those to
    environments

• Aaron Gable: The exact same thing for this draft as the JWT claim
  constraints: ACME wire protocol stuff is great, the people in this
  room have a hard time viewing the GUTS of the description of the
  challenge.

  • Will want to pull in OIDF experts for that specific section.
  • The way it will play out, the issuer will validate following the
    OpenID specification.

• Chair (Mike) - Will take draft to the List for a call for adoption!

draft-davidben-acme-profile-sets - David Benjamin

• Getting just one cert that works for all clients is really hard
• Idea: extend the Profiles draft by also specifying profile sets

• A client is configured with a profile name. If that name is actually
  a profile set, then it makes one Order for each profile in that set.

  • Client is in charge of getting and renewing certs for each
    profile
  • No changes to the issuance-path ACME protocol

• Stefan Santesson: How do you get old ACME clients to participate?

  • You don't. We can't do this today, but we'd like to be able to
    in the future.

• Aaron Gable: Should this be part of the extant profiles draft, or a
  separate draft? Bringing to working group for advice.

  • Tim Hollebeek thinks they should be separate drafts, as
    profile-sets may end up more complex than expected. Don't hold
    up profiles draft.
  • Bob Beck concurs.

• Mike Ounsworth: Should we adopt?

  • Added to the chairs' TODO list for adoption call

draft-liu-acme-rats – Peter Liu

• Purpose is to attest to security properties in the certificate

  • Certificate consumers may want to know about the bearer
  • Certificate issuer may want to know about the applicant

• Since IETF 123:

  • Interim design meeting
  • Closed 4 issues (#10, #12, #13, and #18)
  • Split identifier type into two separate types, renamed
    challenges

• The new "trustworthy" identifier is a sentinel value

  • Both the type and the value are the string "trustworthy"
  • The identifier is validated using the new attestation-result-01
    or attestation-evidence-01 challenge type
  • The challenge object can contain strings indicating which
    attestations the client needs to present
  • The client POSTs the attestations to the challenge URL

• Yaov Nir: Are there any implementations?

  • Not yet, hoping to do a hackathon at next IETF
  • Requesting adoption now, which doesn't require implementations

• Aaron Gable: Minor comment about examples in the document.

  • Michael Richardson: We renamed it, had missed it.

• Bob Beck: Should this be split into two documents, since half of it
  is closer to ready for implementation?

  • Will take that idea under consideration

AOB

None