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

[皮皮猪 <[e-mail]>]

Hi Michael,

To clarify the architectural reasoning behind the pk-01 proposal, I would like to outline how we see the verification dimensions in ACME.

ACME [RFC8555] models certificate enrollment as an order containing a set of identifiers. Each identifier maps to an authorization that carries a set of challenges. Existing challenges such as dns-01 and http-01 address Domain Control Validation (DCV).

Early versions of the pk-01 draft (prior to -05) also explored Identity Control Validation (ICV) for non-DCV scenarios. This line of exploration originated from the sso-01 draft and several subsequent related drafts.At that stage, public-key identity binding and Proof-of-Possession (PoP) were interleaved, aiming to shift the paradigm from "controlling communication resources" toward "controlling the claimed identity."

Following extensive discussion, beginning around draft -05/-06, community feedback converged on the view that PoP should be fully decoupled as an independent component. The central question, therefore, is not whether to replace the CSR, but rather: what mechanism should prove possession of a public key, and how can that mechanism be combined orthogonally with both the existing DCV framework in ACME and any future ICV?

In short, the ACME protocol suite comprises three independent verification dimensions, each supported by its own protocol framework. DCV and ICV stand as parallel capabilities; either can independently satisfy identifier validation and support certificate issuance. PoP is an independent verification dimension. It may be used together with DCV or ICV and may also serve alone as the basis for certificate requests when an order contains only the "pk" identifier.

In my understanding, the three are fully orthogonal to each other.
                        ACME identifier
                                  |
          +------------+------------+
          |                       |                     |
         dns-01            pk-01            idp-01
          |                       |                     |
          v                     v                    v
         DCV              PoP                ICV
          |       (fully decoupled)          |
          +------------+------------+
          |                                             |
 DCV + (PoP)                          ICV + (PoP)


DCV [RFC8555]: Do you control this domain name?
ICV (idp-01): Do you control this identity?
PoP (pk-01): Do you possess this private key?


Best regards 
Geng Feng         
         原始邮件
         
       
发件人：Michael Richardson <[e-mail]&gt;
发件时间：2026年5月5日 23:16
抄送：[e-mail] <[e-mail]&gt;, [e-mail] <[e-mail]&gt;, [e-mail] <[e-mail]&gt;
主题：Re: [Acme] Call for adoption: draft-geng-acme-public-key-06 (Ends 2026-05-12)




palos.chen&nbsp;<[e-mail]&gt;&nbsp;wrote:
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&gt;&nbsp;It&nbsp;seems&nbsp;that&nbsp;this&nbsp;almost&nbsp;suffers&nbsp;from&nbsp;the&nbsp;same&nbsp;mis-understanding&nbsp;of
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&gt;&nbsp;challenges&nbsp;as&nbsp;acme-rats&nbsp;originally&nbsp;did.&nbsp;At&nbsp;least&nbsp;though,&nbsp;the&nbsp;intention
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&gt;&nbsp;is&nbsp;that&nbsp;it&nbsp;is&nbsp;pk-01&nbsp;OR&nbsp;dns-01&nbsp;OR&nbsp;http-01&nbsp;OR&nbsp;...&nbsp;(not&nbsp;AND&nbsp;as&nbsp;rats
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&gt;&nbsp;needed)

&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;In&nbsp;-07,&nbsp;pk-01&nbsp;is&nbsp;no&nbsp;longer&nbsp;entangled&nbsp;with&nbsp;identifier&nbsp;validation.&nbsp;We
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;introduced&nbsp;a&nbsp;new&nbsp;"pk"&nbsp;identifier&nbsp;type&nbsp;(Section&nbsp;3);&nbsp;pk-01&nbsp;is&nbsp;bound&nbsp;to
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;"pk"&nbsp;identifiers&nbsp;and&nbsp;proves&nbsp;possession&nbsp;of&nbsp;the&nbsp;certificate&nbsp;private&nbsp;key
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;only.&nbsp;Existing&nbsp;challenges&nbsp;(dns-01,&nbsp;http-01,&nbsp;...)&nbsp;remain&nbsp;bound&nbsp;to&nbsp;their
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;own&nbsp;identifier&nbsp;types&nbsp;per&nbsp;[RFC8555]&nbsp;without&nbsp;modification.

But,&nbsp;it's&nbsp;the&nbsp;wrong&nbsp;approach.
You&nbsp;have&nbsp;to&nbsp;change&nbsp;pk-01&nbsp;each&nbsp;time&nbsp;someone&nbsp;comes&nbsp;along&nbsp;with&nbsp;a&nbsp;new&nbsp;challenge
type.&nbsp;&nbsp;&nbsp;What&nbsp;you&nbsp;are&nbsp;doing&nbsp;is&nbsp;orthogonal&nbsp;to&nbsp;the&nbsp;challenge.

&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;The&nbsp;async/sync&nbsp;modes&nbsp;of&nbsp;-06&nbsp;are&nbsp;entirely&nbsp;removed&nbsp;in&nbsp;-07.&nbsp;pk-01&nbsp;no
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;longer&nbsp;carries&nbsp;any&nbsp;identifier&nbsp;control&nbsp;role.&nbsp;Existing&nbsp;extensions
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;(onion-csr-01,&nbsp;subdomain,&nbsp;dns-persist,&nbsp;etc.)&nbsp;continue&nbsp;to&nbsp;operate
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;unchanged&nbsp;alongside&nbsp;pk-01.

okay,&nbsp;but&nbsp;I&nbsp;still&nbsp;think&nbsp;this&nbsp;is&nbsp;the&nbsp;wrong&nbsp;direction.
I&nbsp;think&nbsp;that&nbsp;what&nbsp;you&nbsp;are&nbsp;proposing&nbsp;is&nbsp;useful,&nbsp;but&nbsp;it's&nbsp;a&nbsp;fundamental&nbsp;change
to&nbsp;ACME,&nbsp;and&nbsp;should&nbsp;be&nbsp;treated&nbsp;that&nbsp;way.

&nbsp;&nbsp;&nbsp;&nbsp;&gt;&gt;&nbsp;Replacing&nbsp;the&nbsp;CSR&nbsp;with&nbsp;something&nbsp;better,&nbsp;something&nbsp;that&nbsp;can&nbsp;deal&nbsp;with
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&gt;&nbsp;keys&nbsp;that&nbsp;can't&nbsp;make&nbsp;signatures&nbsp;(either&nbsp;do&nbsp;to&nbsp;math&nbsp;or&nbsp;policy)&nbsp;is
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&gt;&nbsp;important.&nbsp;I&nbsp;had&nbsp;proposed&nbsp;work&nbsp;like&nbsp;this&nbsp;if/when&nbsp;we&nbsp;start&nbsp;RFC7030bis.

&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;We&nbsp;share&nbsp;this&nbsp;motivation.&nbsp;KEM-key&nbsp;support&nbsp;is&nbsp;in&nbsp;fact&nbsp;one&nbsp;of&nbsp;the
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;primary&nbsp;reasons&nbsp;for&nbsp;a&nbsp;dedicated&nbsp;PoP&nbsp;mechanism&nbsp;rather&nbsp;than&nbsp;relying&nbsp;on
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;the&nbsp;CSR&nbsp;self-signature,&nbsp;which&nbsp;is&nbsp;impossible&nbsp;for&nbsp;KEM-only&nbsp;keys.&nbsp;-07
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;supports&nbsp;ML-KEM-512/768/1024&nbsp;via&nbsp;a&nbsp;Decapsulate&nbsp;+&nbsp;HKDF&nbsp;+&nbsp;HMAC&nbsp;PoP&nbsp;—&nbsp;see
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;Section&nbsp;5.2&nbsp;(KEM&nbsp;PoP&nbsp;construction)&nbsp;and&nbsp;Section&nbsp;5.4&nbsp;(KEM&nbsp;algorithm
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;registry).

Then,&nbsp;let's&nbsp;fix/replace&nbsp;CSR.

&nbsp;&nbsp;&nbsp;&nbsp;&gt;&gt;&nbsp;The&nbsp;ACME&nbsp;server&nbsp;should&nbsp;simply&nbsp;announce&nbsp;the&nbsp;set&nbsp;of&nbsp;POP&nbsp;methods&nbsp;that&nbsp;it
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&gt;&nbsp;can&nbsp;support,&nbsp;with&nbsp;CSR&nbsp;being&nbsp;the&nbsp;default.&nbsp;I&nbsp;don't&nbsp;think&nbsp;a&nbsp;new&nbsp;challenge
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&gt;&nbsp;method&nbsp;is&nbsp;the&nbsp;correct&nbsp;way&nbsp;to&nbsp;negotiate&nbsp;this.

&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;This&nbsp;is&nbsp;the&nbsp;one&nbsp;architectural&nbsp;point&nbsp;where&nbsp;we've&nbsp;taken&nbsp;a&nbsp;different
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;direction,&nbsp;following&nbsp;the&nbsp;chair's&nbsp;earlier&nbsp;guidance&nbsp;and&nbsp;the&nbsp;model&nbsp;that
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;ACME&nbsp;has&nbsp;consistently&nbsp;used:&nbsp;challenges&nbsp;bound&nbsp;to&nbsp;identifier&nbsp;types
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;(dns-01&nbsp;for&nbsp;dns,&nbsp;http-01&nbsp;for&nbsp;dns-via-http,&nbsp;onion-csr-01&nbsp;for&nbsp;onion,
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;etc.).&nbsp;-07&nbsp;introduces&nbsp;a&nbsp;"pk"&nbsp;identifier&nbsp;type&nbsp;and&nbsp;a&nbsp;pk-01&nbsp;challenge
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;bound&nbsp;to&nbsp;it,&nbsp;which&nbsp;keeps&nbsp;the&nbsp;architecture&nbsp;modular&nbsp;and&nbsp;aligned&nbsp;with&nbsp;how
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;the&nbsp;working&nbsp;group&nbsp;has&nbsp;handled&nbsp;similar&nbsp;extensions.

I&nbsp;think&nbsp;the&nbsp;chairs&nbsp;are&nbsp;wrong&nbsp;here&nbsp;:-)

I&nbsp;don't&nbsp;think&nbsp;this&nbsp;is&nbsp;a&nbsp;good&nbsp;direction&nbsp;to&nbsp;go,&nbsp;because&nbsp;I&nbsp;don't&nbsp;think&nbsp;your
needs&nbsp;are&nbsp;not&nbsp;the&nbsp;same&nbsp;as,&nbsp;for&nbsp;instance,&nbsp;.onion.


--
Michael&nbsp;Richardson&nbsp;<[e-mail]&gt;&nbsp;&nbsp;&nbsp;.&nbsp;o&nbsp;O&nbsp;(&nbsp;IPv6&nbsp;IøT&nbsp;consulting&nbsp;)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Sandelman&nbsp;Software&nbsp;Works&nbsp;Inc,&nbsp;Ottawa&nbsp;and&nbsp;Worldwide

**&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;My&nbsp;working&nbsp;hours&nbsp;and&nbsp;your&nbsp;working&nbsp;hours&nbsp;may&nbsp;be&nbsp;different.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**
**&nbsp;Please&nbsp;do&nbsp;not&nbsp;feel&nbsp;obligated&nbsp;to&nbsp;reply&nbsp;outside&nbsp;your&nbsp;normal&nbsp;working&nbsp;hours&nbsp;**