Skip to main content

Minutes interim-2021-acme-01: Wed 14:00

Meeting Minutes Automated Certificate Management Environment (acme) WG
Date and time 2021-09-29 18:00
Title Minutes interim-2021-acme-01: Wed 14:00
State Active
Other versions markdown
Last updated 2021-10-04


Minutes of IETF ACME WG Interim



  • Yoav Nir and Deb Cooley presiding.
  • Note Well mentioned but not projected.
  • Appoint Aaron Gable for minutes.


Presenter: Brian Sipos

  • Version 05 has been uploaded, incorporating feedback from Roman Danyliw.
  • Update certificate profile to use SAN otherName with new Name Form "bundleEID"
  • Minor updates/clarifications to diagrams, typos, security considerations
  • No changes to wire formats or ACME logic
  • Future change: extract a portion of this draft into a new DTN WG doc, then normatively reference it here. Can't go directly into existing DTN WG doc due to unfortunate timing. There was some pushback (from Yoav and Roman) on that because those DTN documents are not yet published, but ultimately this is the concern of DTN, not ACME.
  • Certificate profile is being standardized in draft-ietf-dtn-tcpclv4-27
  • Registry update is in draft-ietf-dtn-bpbis-31
  • Need a version -06 of the draft to fix some missed "SAN URI" mentions, and then we can have WGLC


Presenter: Owen Friel

  • Current version 05
  • Major issue raised by Russ Housley regarding RFC7030 CSR Attributes
  • This draft will be updated to reference lamps-rfc7030-csrattrs once it is published


Presenter: Owen Friel

  • Current version 05
  • Mailing list discussion regarding need to disambiguate between wildcard and domain namespace authorizations. Conclusion: yes, do need to differentiate.
  • Mailing list discussion regarding whether new domainNamespace key needs to exist in both newAuthz and newOrder flows. Definitely yes for newAuthz; maybe for newOrder. Discussion here: yes to both, but should be discussed on the list following adoption.
  • Re-raising call for WG adoption.

ACME Renewal Info

Presenter: Aaron Gable

  • Current version 00 (individual draft)
  • Certificates have a normal cycle of replacement.
  • Sometimes there are issuance spikes, such as after mass revocation events.
  • Once the entire community has been re-issued there is a lull in the issuance and when all the issued certificates begin to expire there will be another spike of renewals.
  • Can acme encourage clients to renew early? Not currently.
  • If an acme server could do this, you could spread issuance out more smoothly.
  • The proposal is that there would be a URL for renewal checking that would be in the order object.
  • Clients would regularly check new renewalInfo endpoint to determine when they should renew.
  • Suggestion: Include the URL directly in the certificate. Probably needs a new extension.
  • Suggestion: should be more prescriptive on clients; more MUSTs, fewer SHOULDs.
  • Suggestion: monitoring tools should be able to query renewalInfo URLs, which suggests they should be determinsitically constructible
  • Question: is this (either load smoothing, or renewal before revocation, or both) a problem the WG wants to solve?
  • No objections.
  • Question: is having every client check in on renewalInfo this frequently really easier than having them renew all at once.
  • renewalInfo endpoint is very lightweight compared to full issuance
  • Next steps: prepare a version 01 that switches URL constructibility, get more comments from there, see on the mailing list whether there is enough interest.

Other Business

  • Question from Roman about ACME Challenges Using an Authority Token. Mary Barnes said she would touch base with Jon Peterson to see what the time line is.
  • Kathleen checking up on status of draft-ietf-acme-client
  • Adds a few challenge types. Needs additional feedback on the mailing list.