[Acme] Call for adoption: draft-geng-acme-public-key-06 (Ends 2026-05-12)

[Mike Ounsworth via Datatracker <[e-mail]>]

This message starts a acme WG Call for Adoption of:
draft-geng-acme-public-key-06

This Working Group Call for Adoption ends on 2026-05-12

Chair Note #1:
The most recent version of the draft has significantly scoped-down the content from what was presented at IETF 125. This draft is now purely focused on the pk-01 challenge type towards the goal of being able to remove the ASN.1 CSR from an ACME flow.

I remind the WG that this is a call-for-adoption, not a WGLC, so the relevant adoption questions are:

1) Does the WG want to work on a new ACME challenge for public key proof-of-possession towards goals such as removing the CSR, enrolling KEM certificates, and potentially other applications?

2) Does the WG feel that this draft is a reasonable starting point for discussing and designing a solution to (1)?


Chair Note #2: IPR

I wish to draw the WG's attention to the IPR filings on this draft: 1 filed by Huawei, and 2 filed by me (Mike Ounsworth), pertaining to a total of 4 different but related patents. I am not a lawyer, and I make no claim as to whether or not these patents apply to the given draft; simply that they appear to be related. I mention this as part of the CfA in case it affects anyone's opinion on whether this draft is a suitable starting point.


Abstract:
   The current ACME protocol [RFC8555] requires applicants to submit a
   PKCS#10 Certificate Signing Request (CSR) during the finalization
   phase.  The construction, ASN.1 encoding, and transmission of the CSR
   impose additional implementation burdens on both the client
   (especially resource-constrained devices) and the server.  Moreover,
   the CSR cannot prevent a public key from being replaced by an
   intermediary at the protocol level.

   This document introduces the "pk-01" challenge extension based on the
   ACME protocol.  Its core mechanism is as follows: the applicant
   declares the public key to be authenticated during the "newOrder"
   phase and completes the Proof of Possession (PoP) by signing with the
   private key during the challenge phase.  Since the public key is
   declared when the order is created and verified during the challenge
   phase, there is no need to submit a CSR during the finalization
   phase; the ACME server can issue the certificate directly based on
   the verified public key, thereby eliminating the CSR at the protocol
   level.

   The "pk-01" challenge supports two verification modes via the
   pop_mode field:

Please reply to this message and indicate whether or not you support adoption
of this Internet-Draft by the acme WG. Comments to explain your preference
are greatly appreciated. Please reply to all recipients of this message and
include this message in your response.

Authors, and WG participants in general, are reminded of the Intellectual
Property Rights (IPR) disclosure obligations described in BCP 79 [2].
Appropriate IPR disclosures required for full conformance with the provisions
of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
Sanctions available for application to violators of IETF IPR Policy can be
found at [3].

Thank you.
[1] https://datatracker.ietf.org/doc/bcp78/
[2] https://datatracker.ietf.org/doc/bcp79/
[3] https://datatracker.ietf.org/doc/rfc6701/

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-geng-acme-public-key/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-geng-acme-public-key-06.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-geng-acme-public-key-06