[Acme] 回复：Re: 回复：Re: 回复：Re: 回复：Re: I-D Action: draft-geng-acme-public-key-07.txt

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

Hi Greg,


This has always been a very interesting topic. There is an ancient saying in China: learn from the past to forsee the future.


See more insightful discussions in the past, please refer to the discussion on "[Acme] Internet-Draft: PQC Algorithm negotiation in ACME" (https://mailarchive.ietf.org/arch/msg/acme/FEZYTUfhSeur-wKQI6H2xytSkvY/)


The lesson I've learned from this is that when have newcomers take on historical topic (as I previously mail pointed out, we authors were guided into this meaningful work), it's best for them to spend more time understanding the past. :-)


I also like Alexandre Augusto Giron's draft and paper eprint 2023/1921.


So let's just do it, bring this work to a conclusion.


Best regards,


Feng



---原始邮件---
发件人: "Greg T. Wallace"<[e-mail]&gt;
发送时间: 2026年8月23日(周日) 凌晨3:51
收件人: "acme"<[e-mail]&gt;;
主题: [Acme] Re: 回复：Re: 回复：Re: 回复：Re: I-D Action: draft-geng-acme-public-key-07.txt


Why not use finalize?

If a server supports this non-csr method and you want a requirement that the client prove current possession, add a keyPopNonce field to all orders. The added field would indicate to clients that the server supports this extension and the client can adjust automatically.e.g.,
{
... [order] ...
" keyPopNonce": "Kz3mVpQeRd9fLwYbN5hXuT6oJsIc0vAg2nEp1yMrFqZ"
}


Client sees there is a keyPopNonce and knows it can use the non-csr method to finalize. Then in the finalize post payload, the client instead posts 'proof' and is required to omit the csr:
&nbsp;{ "proof": "<base64url signature&gt;" }


State machine remains, finalize is used in a way that makes sense, and no weird shoe horning stuff into auths or challenges.


Greg






---
Greg T. Wallace
Sent via Webmail



On Thu, Aug 20, 2026 at 11:15 AM 皮皮猪 <507069=[e-mail]&gt; wrote:

Thanks for the thoughtful follow-up.


On option (a) vs (b): We chose (a) because it reuses the existing authorization state machine rather than introducing a new order-level wait condition. The multiplicity issue (identifiers are *, PK is ?) is real, but we think it's acceptable — the pop identifier is explicitly auxiliary, cardinality one per order, following acme-rats precedent. It also gives OPAQUE-01 a clean reuse path.


On MTC: You're right that MTC itself can use CSRs. I think I initially misunderstood the concern. We've reframed the tertiary motivation accordingly.


On proxy-swapping: Exactly. By moving PoP proof into the order via pop authorization, we eliminate the window where a proxy could swap out the CSR after authorizations complete. Because the certificate key is declared and proven at order creation time, there is no CSR left to swap at finalization. We'll highlight this in Security Considerations.


On autofinalization: We agree it's more aggressive. We opted for pop authorization because it's less invasive — it keeps the order state machine closer to RFC 8555 semantics.


Feng
         原始邮件
         
       
发件人：Ilari Liusvaara <[e-mail]&gt;
发件时间：2026年8月20日 22:03
收件人：acme <[e-mail]&gt;
主题：[Acme] Re: 回复：Re: 回复：Re: I-D Action: draft-geng-acme-public-key-07.txt



       On&nbsp;Thu,&nbsp;Aug&nbsp;20,&nbsp;2026&nbsp;at&nbsp;09:09:01PM&nbsp;+0800,&nbsp;皮皮猪&nbsp;wrote:
&gt;&nbsp;
&gt;&nbsp;In&nbsp;next&nbsp;-08,&nbsp;we&nbsp;aim&nbsp;to&nbsp;first&nbsp;answer&nbsp;a&nbsp;foundational&nbsp;question:&nbsp;where
&gt;&nbsp;should&nbsp;an&nbsp;independent&nbsp;proof-of-possession&nbsp;live&nbsp;in&nbsp;the&nbsp;ACME&nbsp;protocol?
&gt;&nbsp;Is&nbsp;it&nbsp;a&nbsp;separate&nbsp;protocol&nbsp;layer?&nbsp;An&nbsp;order-level&nbsp;condition?&nbsp;Or&nbsp;an
&gt;&nbsp;authorization&nbsp;disguised&nbsp;as&nbsp;an&nbsp;identifier?

I&nbsp;see&nbsp;two&nbsp;ways&nbsp;to&nbsp;do&nbsp;this:

a)&nbsp;Have&nbsp;new&nbsp;identifier&nbsp;type&nbsp;for&nbsp;a&nbsp;public&nbsp;key.&nbsp;Then&nbsp;have&nbsp;authorization
for&nbsp;it,&nbsp;and&nbsp;hang&nbsp;the&nbsp;PoP&nbsp;challenge&nbsp;as&nbsp;challenge&nbsp;off&nbsp;that&nbsp;authorization.

This&nbsp;has&nbsp;issue&nbsp;that&nbsp;the&nbsp;natural&nbsp;multiplicity&nbsp;class&nbsp;for&nbsp;identifiers&nbsp;is
*,&nbsp;but&nbsp;PK&nbsp;has&nbsp;multiplicity&nbsp;class&nbsp;?.&nbsp;Another&nbsp;issue&nbsp;is&nbsp;representing&nbsp;the
no-confirmation&nbsp;case&nbsp;(tho&nbsp;I&nbsp;suppose&nbsp;one&nbsp;could&nbsp;use&nbsp;valid&nbsp;PoP&nbsp;challenge).


b)&nbsp;Have&nbsp;public&nbsp;key&nbsp;be&nbsp;a&nbsp;new&nbsp;field&nbsp;in&nbsp;order.&nbsp;Then&nbsp;return&nbsp;the&nbsp;PoP
challenge&nbsp;and&nbsp;URL&nbsp;to&nbsp;submit&nbsp;it&nbsp;to&nbsp;as&nbsp;another&nbsp;new&nbsp;field&nbsp;in&nbsp;order&nbsp;object.

This&nbsp;has&nbsp;issue&nbsp;that&nbsp;it&nbsp;alters&nbsp;the&nbsp;order&nbsp;processing&nbsp;state&nbsp;machine:&nbsp;The
order&nbsp;needs&nbsp;to&nbsp;wait&nbsp;for&nbsp;something&nbsp;that&nbsp;is&nbsp;not&nbsp;an&nbsp;authorization.&nbsp;However,
there&nbsp;is&nbsp;no&nbsp;way&nbsp;this&nbsp;can&nbsp;be&nbsp;used&nbsp;if&nbsp;either&nbsp;side&nbsp;is&nbsp;unaware&nbsp;of&nbsp;the&nbsp;new
semantics&nbsp;(so&nbsp;this&nbsp;is&nbsp;not&nbsp;a&nbsp;serious&nbsp;problem).

The&nbsp;no-confirmation&nbsp;case&nbsp;is&nbsp;represented&nbsp;by&nbsp;reflecting&nbsp;the&nbsp;public&nbsp;key
but&nbsp;not&nbsp;having&nbsp;a&nbsp;challenge.


&gt;&nbsp;Building&nbsp;on&nbsp;Ilari's&nbsp;insight&nbsp;that&nbsp;"such&nbsp;a&nbsp;device&nbsp;doesn't&nbsp;want&nbsp;to&nbsp;use
&gt;&nbsp;CSR&nbsp;because&nbsp;the&nbsp;order&nbsp;should&nbsp;fully&nbsp;specify&nbsp;the&nbsp;generated
&gt;&nbsp;certificate,"&nbsp;we're&nbsp;also&nbsp;adding&nbsp;a&nbsp;tertiary&nbsp;motivation&nbsp;in&nbsp;-08:
&gt;&nbsp;Alignment&nbsp;with&nbsp;issuance&nbsp;models&nbsp;where&nbsp;the&nbsp;order&nbsp;fully&nbsp;specifies&nbsp;the
&gt;&nbsp;certificate.&nbsp;In&nbsp;deployments&nbsp;involving&nbsp;Merkle&nbsp;Tree&nbsp;Certificates&nbsp;(MTCs)
&gt;&nbsp;[I-D.ietf-plants-merkle-tree-certs]&nbsp;or&nbsp;other&nbsp;batch-oriented&nbsp;issuance
&gt;&nbsp;models,&nbsp;the&nbsp;certificate&nbsp;is&nbsp;allocated&nbsp;by&nbsp;the&nbsp;CA&nbsp;based&nbsp;on&nbsp;the&nbsp;order's
&gt;&nbsp;identifiers&nbsp;and&nbsp;policy,&nbsp;not&nbsp;constructed&nbsp;by&nbsp;the&nbsp;client&nbsp;via&nbsp;CSR.&nbsp;

I&nbsp;was&nbsp;thinking&nbsp;about&nbsp;messes&nbsp;like&nbsp;proxy&nbsp;swapping&nbsp;CSR&nbsp;between&nbsp;orders
(the&nbsp;PK&nbsp;PoP&nbsp;binds&nbsp;the&nbsp;order,&nbsp;but&nbsp;not&nbsp;CSR).

I&nbsp;do&nbsp;not&nbsp;see&nbsp;how&nbsp;MTC&nbsp;is&nbsp;relevant&nbsp;for&nbsp;this.&nbsp;MTC&nbsp;can&nbsp;use&nbsp;CSRs&nbsp;like&nbsp;X.509.
Altough&nbsp;there&nbsp;are&nbsp;cases&nbsp;where&nbsp;the&nbsp;ACME&nbsp;client&nbsp;definitely&nbsp;does&nbsp;not&nbsp;want
an&nbsp;MTC.

One&nbsp;way&nbsp;of&nbsp;elminating&nbsp;the&nbsp;CSR&nbsp;is&nbsp;via&nbsp;"autofinalization":&nbsp;Alter&nbsp;the&nbsp;order
state&nbsp;machine,&nbsp;so&nbsp;that&nbsp;any&nbsp;transition&nbsp;to&nbsp;ready&nbsp;goes&nbsp;to&nbsp;processing
instead.&nbsp;This&nbsp;obviously&nbsp;requires&nbsp;the&nbsp;public&nbsp;key&nbsp;in&nbsp;order.


&gt;&nbsp;The&nbsp;CSR&nbsp;is&nbsp;inherently&nbsp;redundant&nbsp;--&nbsp;the&nbsp;order&nbsp;already&nbsp;contains&nbsp;all
&gt;&nbsp;information&nbsp;needed.&nbsp;Requiring&nbsp;a&nbsp;CSR&nbsp;forces&nbsp;the&nbsp;client&nbsp;to&nbsp;duplicate
&gt;&nbsp;information&nbsp;or&nbsp;fabricate&nbsp;one&nbsp;for&nbsp;a&nbsp;certificate&nbsp;whose&nbsp;attributes
&gt;&nbsp;aren't&nbsp;known&nbsp;at&nbsp;request&nbsp;time.&nbsp;The&nbsp;CSR-less&nbsp;flow&nbsp;enables&nbsp;ACME&nbsp;to
&gt;&nbsp;support&nbsp;such&nbsp;models&nbsp;natively.

Yes,&nbsp;most&nbsp;of&nbsp;the&nbsp;stuff&nbsp;in&nbsp;CSR&nbsp;is&nbsp;redundant.&nbsp;And&nbsp;redundant&nbsp;information&nbsp;is
a&nbsp;legendary&nbsp;source&nbsp;of&nbsp;security&nbsp;problems.

The&nbsp;ACME&nbsp;client&nbsp;I&nbsp;have&nbsp;written&nbsp;emulates&nbsp;CSR-up-front:&nbsp;It&nbsp;takes&nbsp;a&nbsp;CSR
up&nbsp;front,&nbsp;and&nbsp;extracts&nbsp;the&nbsp;order&nbsp;parameters&nbsp;(e.g.,&nbsp;identifiers)&nbsp;off
that.




-Ilari

_______________________________________________
Acme&nbsp;mailing&nbsp;list&nbsp;--&nbsp;[e-mail]
To&nbsp;unsubscribe&nbsp;send&nbsp;an&nbsp;email&nbsp;to&nbsp;[e-mail]
 

_______________________________________________
 Acme mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]