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

["Liuchunchi(Peter)" <[e-mail]>]

From the past IETF session discussions and email discussions, it is safe to say (at least for me) the pk replacement problem and CSR-less optimization benefit is well understood. The -06 version provides a concise and straightforward solution with sufficient implementable details, and I therefore support adoption. It will be interesting to see this work forward and im happy to provide further review feedbacks.

Best,
Peter

> -----Original Message-----
> From: Mike Ounsworth via Datatracker <[e-mail]>
> Sent: Wednesday, April 29, 2026 7:00 AM
> To: [e-mail]; [e-mail]; draft-geng-acme-public-
> [e-mail]
> Subject: Call for adoption: draft-geng-acme-public-key-06 (Ends 2026-05-12)
> 
> 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