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.