On Fri, Aug 11, 2023 at 10:47:12AM -0700, Aaron Gable wrote: > > Making it explicit: Introduce a new identifier type "keypair-KEM". > When included in a newOrder request, an identifier of that type > would have a value that is the full KEM public key. The Server would > then create an Authorization for that identifier, and the Challenge > object(s) for that Authorization would contain a ciphertext encrypted > to that public key. The Client would then POST to the Challenge URL > with a body containing the plaintext (very similar to the non-empty > Challenge POST body from draft-ietf-acme-onion-00's onion-csr-01 > validation method). > > Very similar flows could be adopted for other keypair types as well.
Yeah, for signature keys, one could send nonce and signature. > The only additional requirement I see is that, especially for those > other keypairs, the CA would have to verify that the public key in > the CSR matches the public key provided in the Order. Profile, name list, public key... What is that CSR needed for? And it seems like that can be extended that to cases where ACME does not require POP by just having the ACME server immediately accept the pseudo-authorization. -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
