On Tue, Aug 08, 2023 at 09:44:20AM -0700, Aaron Gable wrote: > > I think it's a good idea for the ACME protocol to have a mechanism to > prove control of the cert private key, probably by having the CSR > contain an additional high-entropy field which is provided by the CA > in the new-order response. But this is generalizable to all certs, not > just KEM certs.
One can not carry private key proof-of-possession for KEM certificates that way. The simplest way to do that would be to to have client decapsulate a challenge ciphertext and return the result to the server. And then there is the separate matter that private key proof-of- possession would cause major issues for secure environments where the ACME client does not have any access to private keys. > Similarly, this idea of algorithm negotiation feels far too specific. > What ACME needs is not PQC algorithm selection, but generic *profile* > selection. A CA should be able to advertise various profiles (e.g. > signature algorithms, EKUs, validity periods, etc) in the Directory > object, and the client should be able to select a profile via one or > more fields in the new-order request. Concrete idea: Have profiles member (array of strings) in directory that lists the global supported profiles, and optional profiles member (array of strings) in account object that contains additional applicant- specific supported profiles. Then the client can include one of those values in "profile" member of new order request. E.g., a CA could then have "RSA", "ECDSA", "RSA-shortlived" and "ECDSA-shortlived" profiles, that control if the certificate is issued from RSA and ECDSA intermediate and if it has default or short lifetime, without any hacky manually maintained lists of special accounts. -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
