ACME 116

IETF 116, Thursday, 30 March 2023 0600-0700 UTC, Room: G314-315

Agenda

Note Well, technical difficulties and administrivia (chairs) – 5 min

Document Status (chairs) – 10 min

Work items

 - draft-ietf-acme-ari-01 (Gable) - 15 min
 - draft-ietf-acme-dns-account-01-00 (Omidi, Chariton) - 15 min

AOB - 15 min

• Welcome

  • Chairs/etc
    • Roman, responsible AD
    • Yoav, in person chair
    • Deb, online

• Agenda (above)

• Document Status

  • ACME Subdomains

    • Latest version (07) from 1-March
    • Approved on 18th of March
    • In RFC Editor's queue to be published

  • ACME-Integrations

    • IESG review
    • Roman Danilyw asked if any help is needed to progress that.
      Deb didn't think so.

  • ACME-dtnnodeid

    • Publication requested
    • Waiting on the DTN working group
    • Roman asking about the status of the DTN working group
    • Deb said she would check/inquire

  • ACME-authority-token

    • Approved 16th of Feb
    • In RFC editor's queue

  • ACME-authority-token-tnauthlist

    • in RFC editor's queue

  • ACME-ari

    • will have presentation

  • ACME-device-attest

    • New document
    • Version 00 from 12th of december

  • ACME-dns-account-01

    • New document
    • Have presentation

• ARI presentation

  • Aaron was not present

• ACME-DNS-ACCOUNT-01

  • Antonis to start presentation
  • Due to recent events: "I am making this presentation in my free
    time without using technical resources.... of alphabet or any of
    its subsidiaries... personal opinion and work performmed at my
    own capacity... continuing as an independent contributor"

  • Updates

    • RFC has been adopted

    • Feedback

      • Changes were made to the abstract text to mention CNAME
        records explicitly
      • Currently a PR exists on GitHub to offer more changes in
        that space. They have not been submitted to the
        datatracker just yet.

      • Discussion in a GitHub issue regarding the design of the
        DNS-ACCOUNT-01 label to
        $hash._acme-challenge.example.com

        • Continue discussion on mailing list, but feel free
          to do it on GitHub too

      • Authorship: why so many authors

        • Nothing done in that space
        • Open to ideas

    • Support

      • CDNs have expressed interest, during the adoption too
      • CAs have expressed interest
      • Cloud providers have expressed interest
      • ACME clients have expressed interest
      • Blog post from Cloudflare to do automatic DCV by
        pointing a cname to them
        • They acknowledge that this draft exists and it would
          help them have a better offering

    • Implementations

      • Google Trust Services has enabled this challenge in
        production & test acme servers
      • Planning to add support to Boulder CA, others (including
        clients/libraries)

  • Yoav: Five authors should not be a problem

• Update on draft-acme-device-attest (Brandon Weeks)

  • There is work in RATS for another attestation type.
  • The author is Ok with WebAuthn since that's already
    standardized.
  • Question from Mike Ounsworth: Key attestation for pure x509 key
    attestion. Do you want to talk/coordinate since our work is
    similar
    • Brandon: love to coordinate, challenge has been getting more
      feedback
    • Mike: aware that i'm trying to add another attestation
      format to the chaos. Let's communicate offline.
    • Brandon: There is already another draft in lamps thats
      related to this.
    • Mike: I believe it is an opaque blob jammed into a CSR
    • Deb: Would be nice to get all the attestation drafts
      together so no overlap happens
    • Brandon: I only know of three, tls lamps and acme

• AOB:

  • Q Misell {draft-misell-acme-onion-00}

    • There is a draft I've been working on.
    • It is my first time interacting with the IETF, possibly my
      mail to acme was lost.

    • This is a short draft to define how ACME handles issuing to
      hidden services (e.g. TOR, etc). A small number of CAs
      already do this.

      • Complexities such as lack of DNS, CAA account binding,
        etc
      • How this will be communicated over ACME. TOR ownership
        verification looks quite different from a verification
        for a publicly-registered DNS name.
      • CAB Forum addresses the TOR use case

    • In ACME currently the CSR is disjoint from the label

    • First draft, please send feedback to the author or mailing
      list https://www.ietf.org/id/draft-misell-acme-onion-00.html

  • Amir Omidi: We are going to upstream our changes shortly, how
    would the WG like to proceed on the DNS-01 draft?

    • Yoav: like any other; wait until we reach consensus on-list.
    • Amir: is it ready for WGLC?
    • Yoav: it was only submitted a few weeks ago and has not had
      enough time for review. How many people have read it? ...
      online poll ... 5 RAISE HAND's. 27 not raised.
    • Encouraged to read in the next few weeks and we can raise it
      on the mailing list.