Minutes of the ACME Working Group

IETF 122
Bangkok
2025-03-20

Administrivia

• Note Well
• Meeting tips
• Agenda-bashing
  • Mike Ounsworth asks to add Autodiscovery

Document Status

• No new RFCs since September 2023

• ACME Renewal Info

  • Published versions -07 and -08
  • Passed WGLC in Dec 2024
  • Approved by IESG in Feb 2025
  • Now in RFC Editor's queue

• ACME Integrations

  • In RFC Editor's queue since July 2023
  • No longer blocked on anima-brski-cloud and
    lamps-rfc7030-csrattrs

• ACME Onion

  • Published versions -05 through -07
  • Passed WGLC in Nov 2024
  • Approved by IESG in Jan 2025
  • Now in RFC Editor's queue

• ACME DTN NodeID

  • Passed WGLC in 2021
  • No longer blocked on RFC 9713

• ACME Client

  • Published versions -08 and -09

• ACME DNS Account Label

  • Still just draft -00

ACME Renewal Info (Gable)

• See Document Status updates
• Thanks to everyone who provided reviews and feedback since IETF 121

ACME Profiles (Gable)

• No document updates since IETF 121
• Server side fully implemented and deployed by Let's Encrypt in
  production
• Client side implemented by at least 6 clients

• No substantive feedback / changes requested by client authors

• David Benjamin:

  • If it seems useful and is deployed, let's call-for-adoption.
  • This profiles design makes sense to me because you get to share
    account information.

DTN Node ID Validation (Sipos)

• Latest version is draft -16
• Dependency has been published as RFC 9713

• Document is now ready for WGLC

• Yoav Nir:

  • Great, we'll do a short Last Call after IETF 122 is over

• Deb Cooley:

  • This already went through IESG, right?
  • Yes. Most reviews are done.

ACME DNS Update (Li)

• Looking to deploy ACME in 5G core network
• No recommended procedure for securly updating DNS records for dns-01
  validation
• Goal is to recommend a best-practice method for updating DNS records
• Use DNS Update (RFC 2136) with TSIG (RFC 8945) or SIG(0) (RFC 2931)
• An OAM configures domain and TSIG/SIG(0) keys on both ACME Client
  and Authoritative Nameserver
• Client uses configured key to secure connection to nameserver

• Security considerations:

  • Key access control on nameserver
  • Preventing replay attacks
  • Key rotation
  • Usage of Dot/DoH

• Henry Birge-Lee:

  • CA/B Forum is considering a ballot that allows long-lived DNS
    challenge tokens. Would that eliminate the need for the client
    to directly update the nameserver?
  • Similarly, validation is sometimes delegated to a different
    nameserver via CNAME. Does that mitigate the need for this
    secure update?

• Phillip Hallam-Baker (PHB):

  • Supports adoption.
  • Discussion in SETTLE came to conclusion that SIG(0) is the
    correct approach, not TKEY.
  • I see no reason to rotate the keys.
  • If ACME reduced the barrier to entry for getting certs, the next
    step is reducing the barrier to entry for managing domain names.
  • "Yes, it is an operational summary. But those are useful."

• Michael Richardson (MCR):

  • This is not a new protocol, it's a summary of how to put
    together several existing protocols.
  • This might be better as a wiki or youtube explainer video, but
    if the IETF thinks it's useful to publish as an RFC, then ok.
    I'm on the fence.
  • Recommendations like "use SIG(0) instead of TKEY" can still be
    useful.
  • Use of a CNAME to delegate validation is still very useful and
    operationally smart.
  • I'm happy to review in whatever format we choose to publish
    this.

• Henry Birge-Lee:

  • Seems like this fills a similar role as the ACME DNS REST API
    service. What are the pros and cons of this approach compared to
    that?
  • Talking about the https://github.com/joohoi/acme-dns

• Aaron Gable:

  • Given the "Things to Consider" slide, it's not clear to me that
    this is actually a best practice if it is not guaranteed to give
    you good security properties (replay attacks, key rotation), or
    even work in all environments.
  • Li: RFC 2136 talks about replay attacks in Security
    Considerations, but advice is incomplete

• Mike Ounsworth:

  • Given Aaron's comment that this guidance may not work in all
    environments, who is this guidance for? The ACME Client
    operator? The DNS nameserver operator? These are often different
    people and some may not care about changing their operations
    because of an ACME BCP document.
  • Li: Both client implementers and nameserver operators.

• Henry Birge-Lee

  • Regarding ACME DNS, it would be good to standardize something. I
    am curious about the pros and cons of just a standardized
    REST/JSON API for updating ACME challenges vs using DNS UPDATE.

• Yoav Nir

  • It seems like a document in this vein is a good thing to have,
    and we can figure out the details of its contents later.
  • We'll need reviewers with DNS expertise.
  • We'll take it to the list, then follow up with call for
    adoption.

ACME-RATS (Liu)

• Purpose is getting TLSClientAuth certificates for mutual TLS
• Core idea is to turn in a device attestation to "redeem" a
  certificate
• ACME Server may want to enforce policies on their clients, such as
  where the private key lives (e.g. hardware) and what storage
  properties and policies apply to it (e.g. FIPS)

• Changes since IETF 121:

  • Changed challenge name to "device-attest"
  • Removed http challenge
  • Changed structure of keyAuthorization
  • Added IANA registries

• But maybe a larger design overhaul is needed

• Current device-attest-01 challenge proves control of a permanent
  identifier
• Maybe need a more general challenge that can prove more general
  attributes, not just identifiers
• Maybe put the attestation in the Finalize payload, instead of as
  part of a challenge

• Design requirements:

  • ACME server can request that the client provide an attestation
  • ACME server can request specific attestation claims
  • ACME server can provide a freshness nonce for inclusion in the
    attestation

• Next step is a monthly call to collaborate on design

• Aaron Gable

  • It seems like you want a new identifier claim.
  • MCR: NO! We don't want that. The attestation is not an
    identifier. The attestation claims are unrelated to anything
    that goes into the certificate. There is a technical problem
    that the ACME state machine does not allow for the client to
    choose multiple challenges.

• Mike Ounsworth

  • But attestations are not identifiers
  • AG: Agreed, unfortunately that's the word that RFC 8555 has
    given us for "thing the ACME Server wants the Client to prove"
  • MO: Can a server ask for "fulfill any one of these three
    challenges, and also mandatorily this fourth one"?
  • AG: It would do that by creating two Authorizations (with
    different Identifiers), and putting three challenges on one and
    just one challenge on the other.
  • MO: Ok, this is a good design direction to explore in the design
    team that we're gonna start. Possible complication: if an
    identifier is requested, and it is fulfilled in the /finalize
    CSR, does that actually work with the ACME state machine?
  • AG: No, the order won't be in the "valid" state until all
    Authorizations (one per identifier) have been fulfilled. But a
    challenge can be fulfilled by POSTing a CSR to a challenge URL
    prior to finalization.
  • MO: Cool. Understood. Good direction design direction to
    explore.

JWTClaimConstraints (Wendt)

• RFC 9448 "TNAuthList Authority Token Profiles" extends RFC 8226
• This document defines a new identifier type JWTClaimConstraint
• ACME Client constructs a CSR containing a set of JWTClaimConstraints
• ACME Client requests that Token Authority issues a token over those
  claims
• ACME Client uses the token to fulfill the ACME Server's challenge
• Seeking call for adoption
  • Has already been presented in STIR WG

ACME PK Challenges (Wu)

• Goal is to defend against attacks where ACME Client replaces the
  public key in the Finalize request
• Focused on scenarios where many users/devices all use a single
  (possibly malicious) ACME Client (an "Entity Management System" or
  EMS) to acquire their certificates
• Adds new pubkey identifier type, and new challenges to prove control
  over it
• Propose using WebAuthn, Opaque/AKE, NIZK, or DLEQ for proof of
  possession

• Have a goal to issue user certs over one-time-use keys

• Aaron Gable:

  • if the client can substitute the pubkey in the Finalize request,
    it can also substitute the pubkey identifier in the New Order
    request.
  • I don't think it's possible to protect against that. Am I wrong?
  • Wu: (explained the proposed mechanism for linking across the
    stages of the ACME flow)
  • I understand the idea of checking for consistency between the
    NewOrder and Finalize, but what if the public key is replaced
    all the way at the beginning of the process? IE the malicious
    client can also lie at the beginning as well.

• Liang Xia:

  • This draft comes from a very specific enterprise environment

• Mike Ounsworth:

  • Generally ACME clients are very powerful, e.g. with access to
    DNS keys or HTTP server contents
  • If we consider the client to be malicious, we have much bigger
    problems
  • Saying that we partly trust the client -- we do trust the New
    Order request, but not the Finalize request -- is a weird
    in-between.

• Henry Birge-Lee:

  • Generally PKIs are partitioned by purpose, and ACME is used in
    many non-WebPKI contexts
  • In the WebPKI, the client is very powerful and must be trusted
  • Is ACME really intended for PKIs where the client is less
    trusted?

Any Other Business

AutoDiscovery (Ounsworth)

• Pair of drafts, one for client autodiscovery, one for server
  autodiscovery
• Both are expired
• Context is that the CA/BForum is considering shorter certificate
  lifetimes
• Most current setups rely on a single CA, but
  single-points-of-failure become a bigger problem with more frequent
  renewal
• Mike Ounsworth no longer has employer motivation to work on these
  drafts

• They're open for folks to pick them up if they want

• Henry Birge-Lee

  • This affects even large providers like Amazon, where the choices
    are "use Amazon Trust Services" or "upload a PEM file by hand"

• Phillip Hallam-Baker:

  • Does this maybe belong in the IoT working group, along with
    other "how to provision everything" topics?