Returning it as part of the protocol makes more sense to me than trying to stuff it into DNS. One could imagine including it as part of some sort of extension in the CSR that optionally proves possession (if desired), for example.
One of the challenges we often have with issuance protocols is that the part of the organization that controls the keys and is setting up servers is often different from the part of organization that can change DNS, and they can't always coordinate their work for reasons that should be familiar to anyone with the misfortune of ever working for a large company. -Tim > -----Original Message----- > From: Acme <[email protected]> On Behalf Of Russ Housley > Sent: Friday, August 11, 2023 12:57 PM > To: IETF ACME <[email protected]> > Subject: Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME > > Thinking about KEM PoP in the context of ACME. The subject must provide > the KEM subject public key as part of the certificate request. A new > challenge > could be defined (for example, dns-kem-00) where the token is a KEM > ciphertext, and the subject needs to put the corresponding plaintext in to > DNS. This proves possession of the KEM private key as well as administrative > control over the domain. > > This does not totally match the flow in RFC 8555, which is: > > 1. Submit an order for a certificate to be issued > > 2. Prove control of any identifiers requested in the certificate > > 3. Finalize the order by submitting a CSR > > 4. Await issuance and download the issued certificate > > The KEM public key would need to be provided in step 1. I guess it is not a > big > deal for the KEM public key to be repeated in step 3, as long as the ACME > server checked for a match. > > Russ > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
