Session Date/Time: 21 Mar 2024 05:30

acme

Summary

This meeting covered the status of several ACME-related drafts, including DTM Node ID, ARI, Device Attestation, ACME Onion, and ACME Best Practices Provisioning. Presentations were given on DTM Node ID, ARI, Device Attestation, ACME Best Practices Provisioning, and ACME Client Key Auto-Discovery. The meeting focused on discussing outstanding issues, implementation status, and next steps for each draft.

Key Discussion Points

DTM Node ID: A new revision addressing editorial changes is expected soon. The draft's progress is dependent on a companion draft in the DTM working group.
ARI: Discussion revolved around the certificate identifier computation and the replacement of the POST request to the renewal info endpoint with the replaces field in the order object. The group also discussed the server behavior if the replaced certificate is already replaced by another one. The group also discussed a request to implement a mass-ARI endpoint.
Device Attestation: The draft focuses on issuing client certificates to end-user devices, primarily in enterprise contexts, using existing attestation formats like WebAuthn. Discussions revolved around the readiness for last call, target environments (physical vs. virtual devices), and the scope of unique identifiers.
ACME Onion: Following a working group last call with little engagement, the chairs implored the attendees to read and review the document.
ACME Best Practices Provisioning: This draft aims to enable IoT devices (printers, cameras, etc.) to obtain certificates trusted by browsers. Discussions focused on discovery mechanisms, root certificate handling, security considerations, and identifying networks. Concern was raised as to if the document fits within the ACME working group or if the group should pursue coordination with the IOT-OPS working group.
ACME Client Key Auto-Discovery: Discussion addressed the need for client key auto-discovery, especially when using CAs requiring out-of-band verification and billing. There was debate as to if the draft provides a means for CA Key rotation and if CA key rotation could be done without the new draft. CAB forum compliance was also a discussion point.

Decisions and Action Items

DTM Node ID: Release dash 13 revision to address editorial issues this week and assess consensus next week or the week after
ARI: Start a thread on the mailing list to resolve the open issues, specifically the behavior of the server if the certificate is replaced by another one. Then, proceed with a working group last call.
Device Attestation: Proceed with a working group last call in about a month, specifically asking for implementation feedback. The ADs will discuss where the draft should go.
ACME Onion: The working group will engage on the mailing list and answer the question "Is it really ready?"
ACME Best Practices Provisioning: Take the issues raised back with the ADs and assess coordination with other relevant WGs, such as IOT-OPS.
ACME Client Key Auto-Discovery: Raise questions on the mailing list and then the chairs will assess if the first draft is ready for adoption call before Vancouver. The second draft will return to a design team.

Next Steps

DTM Node ID: Prepare and publish -13 revision, consensus call after.
ARI: Mailing list discussion of open issues, followed by working group last call.
Device Attestation: Initiate working group last call, specifically targeting implementers for feedback. The ADs will discuss where the draft should go.
ACME Onion: Conduct a thorough review of the document by the working group.
ACME Best Practices Provisioning: Discuss with ADs and consider potential collaboration with IOT-OPS or other relevant WGs.
ACME Client Key Auto-Discovery: Discussion and resolution of design questions with mailing list.