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
