ACME WG Meeting Minutes at IETF 123

Housekeeping

• Notewell
• Minute Taker: Aaron Gable
• Chair changes: welcoming Mike Ounsworth
• Agenda Bash
  • Mike Ounsworth (Chair) is double-booked with PQUIP, so requests
    that his drafts (acme-discovery, and acme-rats) go first.

New RFCs

• RFC 9773, ACME Renewal Information
• RFC 9799, ACME for ".onion" Names

With IESG

• draft-ietf-acme-dtnnodeid, ACME DTN Noce ID Extension

• draft-ietf-acme-integrations, ACME Integrations for Device
  Certificate Enrollment

Adopted Drafts

draft-acme-device-attest

• ACME Device Attestation Extension, Brandon Weeks

• Few updates, but several new adopters

  • EJBCA, KeyFactor, "CertACME"

• Some feedback has been presented on GitHub but not the mailing list

• Yoav Nir: Make the list aware of feedback and changes, but no need
  to have all discussions on the list
• Latest draft (-04) addresses feedback from Mike Ounsworth
  • References ACME RATS (see below)

draft-ietf-acme-client

• ACME End User Client and Code Signing Certificate, Kathleen
  Moriarty
• Attempts to define challenge types, independent of certificate type
• Some discussion on whether Document Signing should be included

• Q Misell: Distinction between this draft's WebAuthn and similar
  challenge from Device Attestation draft?

  • Kathleen to coordinate with Brendan Weeks on this
  • Suggested moving cert types to an appendix, thought it was
    useful to have challenge types separate from individual use
    cases to get through the work quicker.

• Mike Ounsworth: WG has a July 2024 milestone to either move this
  forward or abandon it

  • Do we have rough consensus? Do we have running code?

• Sean Turner: Let's proceed to last call

• Mike: This is a fundamental change to ACME, allowing in-protocol
  authentication of clients (rather than requiring EAB)
• Kathleen: DigiCert says they're doing this as of 2019
• Matt G1: The draft is interesting

• Aaron Gable: Likes that the draft describes generic challenge types,
  but

  • Draft is sorely missing descriptions of what a client provides
    to respond to a challenge
  • Similarly missing descriptions of algorithms for server to
    validate challenges
  • Would like more discussion of how these new methods could be
    used to validate specific identifiers that might appear in
    certs
  • (As opposed to EAB, which authenticates the client as a whole)

• Charles Eckel: Would like clarification on relationship to

• Dave Robin: Confusion on whether document is a survey, or a protocol
  extension

  • Why isn't this three documents, each of the depth of other new
    challenge docs we've had?
  • Kathleen: this structure felt like it made sense in 2018
  • Breaking it into pieces might let each piece proceed
    independently
  • Kathleen: happy to drop challenge types that aren't wanted
    anymore

• Peter Liu: (notetaker missed this question)

  • Peter said they were implementing and were interested in the 3
    challenge types being in one document as they may be sued by
    clients for the same application, e.g. document signing or
    attaining code signing certificates and ACME management for
    updates

draft-ietf-acme-dns-account-label

• ACME DNS Labeled with Account ID
• No presentation today

New Business

draft-vanbrouwershaven-acme-client-discovery, draft-vanbrouwershaven-acme-auto-discovery

• ACME Auto-Discovery for Clients and for Servers, Mike
  Ounsworth

• Within cloud environments, you can either use their ACME CA, or
  manually upload your own PEM file

  • These both have drawbacks
  • What if you have your own ACME CA you'd like to use?

• Client problem: let ACME client discover what CA to use, given only
  an identifier

  • Core idea: use CAA record extension

• Server problem: let CA discover what client account keys are
  authorized

• Drafts looking for a new owner

  • No longer being pushed by original interested party (Entrust)
  • Some difficulties around who has agreed to TermsOfService

• Aaron Gable: what about discovery for non-DNS identifiers (like IP
  or DTNNodeID)

  • Mike: focus was specificially for

• Q: Added code for this to a fork of certbot, quickly and easily

  • But still need CA and, importantly, cloud provider impls

• Leif Johansson: autodiscovery is also present in
  draft-demarco-acme-openid-federation (see below)

• If someone wants to own these drafts, contact Mike on the list
  • Otherwise they'll be allowed to expire

draft-geng-acme-public-key

• ACME Public Key Challenges, Liang Xia
• Since last meeting, added more background and security model

• Goal is to defend against public key replacement attacks

  • Specifically when the ACME Client is not on the device being
    validated

• Four actors: Applicant, IDP, ACME Server, ACME Client

  • Applicant can't talk to ACME server directly, so it has to use
    this separate client
  • Applicant doesn't trust the client it is using
  • But all parties do trust an Identity Provider

• Draft adds a new challenge type, in which the server uses the IDP to
  check that the requested pubkey is one the applicant actually wants
  to use

• Nice side-effect: can remove CSR from finalize call

• Kathleen Moriarty: looks very similar to expired openid-connect
  draft

  • Yes, there's a shared use-case
  • Kathleen: so should we pull this into the already-adopted
    draft-ietf-acme-client?
  • This draft is really focused on a specific security threat

• Q Misell: Two main issues with the draft

  • The problem feels academic; draft should describe the real-world
    situation in which this set of actors and trust relationships
    actually arise
  • If the IDP fulfills a challenge, then the IDP must have an
    account key, at which point it is an ACME client...

• David Adrian: it's good to have public key control challenges

  • Chrome sees value in having identifier types and challenges
  • But no opinion on this specific draft

• David Robin: why are we getting rid of the CSR?

  • Also, are you just moving trust from the client to the IDP?
  • Aaron: in ACME, the CSR only acts as a transport for the pubkey,
    so if that has already been provided, the CSR is redundant

draft-liu-acme-rats

• ACME RATS, Peter Liu
• RATS (Remote Attestation Evidence / Result) is an existing process
  for mobile devices

• Since last meeting, added use case, current practices

  • Also narrowed down design choices

• Use case: inspector connecting to local wifi at each site

  • Could type a password for each wifi (bad)
  • Could use mobile device management to distribute passwords
    (still just passwords)
  • Instead, use ACME-RATS to get device cert, use EAP-TLS or
    Tunneled EAP to connect to wifi

• Draft puts RATS attestation in newOrder request

  • Because challenges are for identifiers, not system attributes

• Next steps: design team continuing to meet, hope for adoption in
  Montreal

• Q Misell: RFC 8555 says that "a server should consider one challenge
  sufficient"

  • So maybe it's okay to attach RATS to an existing challenge
  • Let's take this to the list
  • Aaron Gable: similar concern

• Kathleen Moriarty: this could tie into the RATS posture assessment
  draft

draft-wendt-acme-authority-token-jwtclaimcon-04

• JWTClaimConstraints profile of ACME Authority Token, Chris
  Wendt
• Collaboration with STIR WG

• Creates a new JWTClaimConstraints identifier type

  • Which gets baked into certificate per RFC 8226

• Cert may contain both TNAuthList and JWTClaimConstraints

• Draft contains lots of discussion of how to validate these together

  • Would like feedback on whether this section makes sense

• Next steps: seeking WG review and then adoption

• Jon Peterson: yes, please look at it
• Aaron Gable: likes the simple structure with a new identifier type
  and a new challenge for it
  • Confused by Section 5.5, which feels largely unnecessary
  • Will follow up on mailing list

draft-aaron-acme-profiles

• ACME Profiles Extension, Aaron Gable
• Decided to do a call for adoption at IETF 122, let's do that now
• Considering what it might look like to use profiles to issue
  multiple certs (e.g. one classical, one post-quantum) from a single
  order

draft-birgelee-acme-dns-persist -- Henry Birge-Lee

• Problem: completing dns-01 challenge requires client to have API
  token to update DNS

• To get around this, lots of impls use a CNAME to delegate DNS to a
  cloud provider

  • In this case, the real validation token is effectively this
    long-lived CNAME

• So let's enshrine this, create a validation method using a
  long-lived DNS record

• The CA/Browser Forum is developing language for this now

• Draft fully matches CABF's proposed syntax

  • Record looks a lot like a CAA record, but is a TXT record

• ACME Challenge object has type "dns-persist-01", and no "token"
  field

• DNSOP's "draft-ietf-dnsop-domain-verification-techniques-09" also
  discusses persistent validation now

• Q Misell: this is good, ACME for Onions also moved language from
  CABF to ACME

  • Also, a CA could pre-check for a persistent record upon new
    order creation, so that the challenge doesn't have to be
    "fulfilled"
  • Henry: no, that should be done via authorization reuse

• Corey Bonnell: highly supportive

  • Shiloh Heurich from Fastly has a similar draft
  • Henry is happy to collaborate

• Erik Nygren: should also coordinate with DNSOP draft

draft-demarco-acme-openid-federation

• ACME with OpenID Federation, Leif Johansson
• We're over time, please read this draft and discuss on the list

AOB

• No time.