Minutes IETF116: acme: Thu 06:00
minutes-116-acme-202303300600-00
Meeting Minutes | Automated Certificate Management Environment (acme) WG | |
---|---|---|
Date and time | 2023-03-30 06:00 | |
Title | Minutes IETF116: acme: Thu 06:00 | |
State | Active | |
Other versions | markdown | |
Last updated | 2023-03-30 |
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
- Chairs/etc
-
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
- Continue discussion on mailing list, but feel free
-
Authorship: why so many authors
- Nothing done in that space
- Open to ideas
- Changes were made to the abstract text to mention CNAME
-
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
- They acknowledge that this draft exists and it would
-
Implementations
- Google Trust Services has enabled this challenge in
production & test acme servers - Planning to add support to Boulder CA, others (including
clients/libraries)
- Google Trust Services has enabled this challenge in
-
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
- Brandon: love to coordinate, challenge has been getting more
-
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
- Complexities such as lack of DNS, CAA account binding,
-
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.
-