# Automated Certificate Management Environment (acme) IETF 114, Thursday, 28 July 2022 1600-1700 EDT (2000-2100 UTC), Room: Philadelphia North (Mezzanine) ## Agenda Note Well, technical difficulties and administrivia (chairs) – 5 min Document Status (chairs) – 10 min Work items - draft-ietf-acme-dtnnodeid-09 (Sipos) - 10 min - draft-aaron-acme-ari (Gable) - 10 min New work - draft-bweeks-acme-device-attest (Weeks) - 15 min AOB - 10 min ## Minutes ### Administrivia This session is being recorded. Aaron Gable is taking notes. ### Document Status No new RFCs. #### acme-authority-token and acme-authority-token-tnauthlist * acme-authority-token has new version -08 * acme-authority-token-tnauthlist has current version from 2021-03-26 * Discussion: * Do we still want to advance this and tnauthlist in lockstep? (yes) * The tnauthlist document has not advanced in a long time. * The tnauthlist document still has outstanding blocking comments. * Energy for tnauthlist document has been low. * Action items: * Deb Cooley to follow up with tnauthlist authors. * Once that draft is updated, do a short WGLC for both drafts, cc'ing the STIR WG. * Sean Turner offered to review the docs when updated. #### acme-integrations and acme-subdomains * Both just completed last call ### Work Items #### draft-ietf-acme-dtnnodeid (Brian Sipos) * Latest version is -09 * Few changes since last IETF, but also little feedback since then. * Went to IETF last call, a few breaking changes made as a result. * Just need eyes on those few changes to re-affirm last call. * Action items: * Deb Cooley to reiterate request for review * Aaron Gable (and others) to review #### draft-aaron-acme-ari (Aaron Gable) * Latest version is -03 * Minor changes since previous version * Call for adoption on mailing list garnered two statements of support. * Ran in-meetecho poll for call for adoption: * 17 hands raised in favor, 0 votes against * Action items: * Chairs to send email to mailing list asking for objections ### New Work #### draft-bweeks-acme-device-attest (Brandon Weeks) * Describes how the WebAuthn attestation statement format can be integrated with a new ACME challenge type to attest client control over a particular device. Intended for use in issuing client certificates. * Why ACME? SCEP (current IETF standard) is the primary enrollment protocol, but is difficult to use. ACME is easy to use cross-platform, has library support, and already has extension points built in. * Why now? The majority of devices deployed today finally incorporate device key attestation. * WebAuthn is becoming the defacto format for encapsulating attestations across vendors: Apple AppAttest, WebAuth, draft-fossati-tls-attestation-00, draft-wallace-lamps-key-attestation-ext-00. Has widespread library support. * This document defines: * New challenge: device-attest-01 * Notably, client passes attestation to ACME server inside the challenge fulfillment request, rather than having the server reach out to retrieve this information separately. No other challenge type does this, but RFC 8555 has language specifically allowing for it. * Two new identifier types: permanent-identifier (RFC 4043), hardware-module (RFC 4108) * Additional guidance for using External Account Binding * Question: Kathleen Moriarty asked if this draft should this be combined with the existing acme-client draft? * This document is more narrowly scoped, and only uses WebAuthn as an encapsulation format. This draft doesn't address code signing or keys for users. * Current implementations: * A patched version of Smallstep supports the new challenge type * iOS 16 beta includes the client side * Android has already committed to include the client side * Open questions: * Where should we specify how to include key properties in the issued certificate? * Maybe just create a registry and leave it at that. * How should CAs choose what trust anchors to trust when validation attestations, and how should they perform validation? * Very hard to specify this correctly (cf. RFC 5280). * Eventually it all falls back to trusting that the TPM vendor has implemented their secure enclave correctly. * Some sort of informative text would be very helpful, but this document is probably not the right place for a normative specification of how to perform this validation. * Call for adoption? * Given that platform vendors are already implementing this, moving quickly here would be well-advised. * Action items: * Author to update the draft. * Chairs to send out call for adoption on mailing list.