[Acme] 回复：Re: CfA for draft-geng-acme-public-key (until 24-Aug)

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

Hi Seo,


Thanks for the careful reading.


You quoted the draft correctly: in a typical Web PKI flow, PoP by itself does not stop an attacker who has already passed identifier validation. 


Deployment-specific value of PoP: 
The value of PoP varies by context: in a typical Web PKI flow, an attacker who can satisfy identifier validation can usually generate a fresh key pair, so PoP mainly prevents issuance of a key the requester cannot prove possession of; in device-attestation deployments, the pop authorization supplies that proof alongside the attestation authorization; and for KEM-only keys it is the only available proof, since the [RFC8555] finalization self-signature does not exist.


The main motivation for this extension:
A KEM key cannot produce the self-signature that RFC 8555 finalization relies on, so without it there is no CSR-based issuance path for such keys at all.


On your BR point: 
You are right that the BR do not require the CA to verify the applicant’s control of the private key as a separate issuance precondition. In the standard flow, that control is demonstrated by the CSR self-signature. This extension does not change that baseline; it only provides an alternative proof mechanism for keys that cannot produce such a signature.


So, to answer your question directly: this draft does not define a mode in which the CA skips PoP. When the CSR-less flow is used, the pop-01 challenge is always required.


Happy to discuss further.


Feng Geng 
on behalf of the authors


         原始邮件
         
       
发件人：Seo Suchan <[e-mail]&gt;
发件时间：2026年9月1日 04:01
收件人：acme <[e-mail]&gt;
主题：[Acme] Re: CfA for draft-geng-acme-public-key (until 24-Aug)




for naming of this, Will always require possession of public key,       or could there a mode of this that CA not bother client actually       has secret key and declaring a public key it want in cert is       enough? Author already said in WebPKI context PoP is mostly       meaningless because attacker just use a new keypair anyway. and       IIRC BR doesn't need to check client actually control public key       at all (I think there was discussion in old       mozilla.dev.security.policy , but it 429s so I can't search)
26. 9. 1. 04:27에 Yoav Nir 이(가) 쓴 글:
 
              Hi, all 

 
I let the CfA go for another week. We’ve had several “yes”         responses, and no dissents. &nbsp;We believe this represents WG         consensus to adopt.

 
The current authors have agreed to keep holding the pen as         editors of the WG draft.

 
Authors, please submit the next version of the draft as         draft-ietf-acme-pop-00.

 
Yoav
(on behalf of the chairs)
 

 
On 10 Aug 2026, at 0:18, Yoav Nir  <[e-mail]&gt;&nbsp;wrote:

 Hi. 

 
During the meeting in Vienna, there was plenty of                   interest in the room for running another adoption call                   for the subject draft.

 
For convenience, here’s a link:

 
https://datatracker.ietf.org/doc/draft-geng-acme-public-key/

 
A bit of history: we have tried this before. We                   have run a call for adoption from April 29th to May                   12th. There was little comment and practically nobody                   answered the CfA question positively, so that despite                   the two-week extension, we had to conclude that the                   call for adoption failed:

Mike’s chair notes at the start of the CfA: https://mailarchive.ietf.org/arch/msg/acme/CNxmhtOI37AMGQOM_XjV2Bhe9QM/

Mike’s conclusion: https://mailarchive.ietf.org/arch/msg/acme/OC74LkERC0DpyzoLWtZpbkGCFwg/

 

 
However, due to the generally positive mood of the                   room, we are starting this second attept at a call for                   adoption.

 
Please send your comments, and conclusion (to                   adopt; or not to adopt) to the list over the next two                   weeks.

 
The CfA Ends on EOD Monday, August 24th.&nbsp;

 
Thanks

 
Yoav

 

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