ACME Session IETF 126

Note-taker: Peter Liu

CHAIR ACTIONS

• {: .task-list-item} Short Re-WGLC on device-attest about the
  UPDATES 8555 change
• {: .task-list-item} Close out WGLC for dns-account-label
• {: .task-list-item} Start another CfA for pk-01
• {: .task-list-item} Do a CfA for the PQ Profile topic; which boils
  down to "What should we do about the ES256 MTI in 8555" --> the
  discussion could have more than one possible outcome.
  

In IESG

draft-ietf-acme-integrations

• Blocked in the same cluster as ANIMA and BRSKI
• Deb suggested ways to not be blocked, like removing blocking
  normative references. Told a joke about ANIMA has lived very long.

draft-ietf-acme-device-attest

• Working through IESG reviews (not blocked)

Working Group Documents

draft-ietf-acme-authority-token-jwtclaimcon

• Russ provided reviews from JWT expert perspective
• Mike suggested need at least 1 ACME expert's review

draft-ietf-acme-dns-account-label

• Has been stable for years
• Multiple implementations in use
• Should be ready to ship

draft-ietf-acme-dns-persist

• About: A long-lived DNS TXT record, carrying an accounturi and a
  persistUntil expiry, authorizes one CA account to issue for a
  domain with no action needed at each issuance
• Authors asked objections to the star-form proposal? Input for the
  rollover design? No objection is brought to mic.
• Next step: Publish -02 after key rollover and binding is done.
• Aaron: Very happy with the direction of this draft -- dropping the
  non-hashed version, etc. Some questions about the design of the
  rollover parts. Slight preference for not requiring CAs to support
  rollover because of interactions with keys reported to the CA as
  compromised.
• Tim: Rollover is a complex problem that need more discussion.

draft-ietf-acme-profiles – [10 mins]

• Update: Will publish new version after 126 addressing 125 problems,
  should be ready for LC after?

• Fabien: Does this draft support a single profile, or a collection of
  profiles?

• Aaron: this draft is a single profile. David Benjamin has a separate
  Profile Sets draft.

draft-ietf-acme-rats – [10 mins]

• Update: The authors implemented the proposed draft with both
  ACME-Client and ACME-Server, to have end-to-end demostration. Code
  are intended to be production-ready.
• One design suggestion is suggested: one challenge per one
  authorization at a time. No objections with the suggestion.
• No further comments / questions on the presentation.

draft-ietf-acme-openid-federation – [no presentation]

New Business

draft-geng-acme-public-key – Xin Chen [10 mins]

• Purpose of this draft: Prove possession of the certificate key.
• Focused on KEM keys. Secondary goal of leaner clients - no need for
  PKCS#10 support. Added PoPkeys and Proof in protocol flow.
• Authors brought up a design choice question: where should
  order-bound PoP live? Asked for another adoption call.

• Mike mentioned the draft changed (concised) a lot compared to
  previous versions. Mike asked WG to consider adoption question.

  • Aaron support adoption and support 3rd design option of
    where-does-PoP-live.
  • Russ think do need a PoP mechanism.
  • Guilin think KEM is a good idea.

• Mike calls for adoption for this draft, YES-19, NO-2. An adoption
  call will follow on the mailing list.

PLANTS / MTC (draft-ietf-plants-merkle-tree-certs-04, Section 9) – David Benjamin [10 mins]

• Not a ACME document, it is a PLANTS document but section 9 is
  related to ACME.

• About: Introduced the "landmark certificate", an optimization
  (smaller) for clients that can process it. Issurance process of
  landmark certificate should not block standalone certificate.

  • The ACME Client should know "landmark certificates" are
    optional.

    • Tim: Needs more specification on this part.

  • Certificates needs new provision metadata to be identified if it
    is L/S certificate.

• Yoav: Keep the document in PLANTS.

• Mike: MTC people should keep ACME people updated about progress.

draft-ar-acme-pqc-tlsjws – Aritra [10 mins]

• About: Current ACME deployments depend on classical publickey
  cryptography in TLS and JWS, therefore prone to quantum computers.
  This document defines quantum-ready ACME deployment profiles
  supporting both pure PQC and PQ/T hybrid cryptography.

• There will be 2 different profiles to allow non-PQ to continue to
  work, or enforce strict PQ-only authentication.

• Tadahiko: what information must be protected? Certificates would not
  be that confidentiality-critical?
• Tim: Does this defines time to transit?

• Deb: There is no explicit ciphersuite requirement in RFC8555? It
  references TLS?

  • Aaron: Section 6.2 includes Json web signatures. It says the
    server MUST/SHOULD implement ES256 ciphersuites. Aaron suggested
    no more than several sentence changes in original document.

• Some discussion in-chat about whether the correct action is to
  simply delete the "MTI ES256" sentence from 8555 and default to
  anything allowed by JWS. Some discussion about whether that could be
  done as an Eratta on 8555, but no, it would need a real document.

• Mike asked it should be done by profile or bis?
  • People suggested taking to the list.
  • Deb (as AD): Should push JWS and TLS PQ-migration documents to
    forward, reference some PQ-done documents. Some more streamlined
    method to avoid redo-ing stuff or continuous alignments.

draft-vicente-acme-pqc-agility-profile – Brian?

No presentation submitted.

New mechanism for “I lost my account key, let me re-do DNS-01 / HTTP-01 and then kick all keys currently authorized against that domain” (see discussion on-list titled “RFC 8555 Last Call Draft Change Request”)

• About: Like a password-reset flow for ACME.

• Aaron: Suggested use new keys to do new challenges, invalidate
  lost/outdated keys. Revoking certificates could be doable, by
  applying for new ones.

  • Approach 1: Revoke other people's authorization

    • Is opposed by Tim as it allows attack tools

  • Approach 2: CAA Account Binding

    • Is supported by Tim, Andrew

• Mike invites people to write a draft.

Support for SM2 in ACME -- Guilin Wang

• draft-geng-acme-sm2dualcert-extension-00
• draft-geng-acme-sm2dualcert-rotation-00
• About: dual-certificate--one signature certificate and one
  encryption certificate
• Authors want to do 1. SM2 dual-certificate issuance framework, and
  2. STAR extension for key rotation.

Some discussion about why this needs an international standard, and
about how this draft interacts with the IETF's "No backdoored
technologies" policies -- RFC2804 and RFC1984?