On Fri, Aug 11, 2023 at 9:00 AM Ilari Liusvaara <[email protected]> wrote:
> 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. > > To be clear, I meant an *optional* proof-of-posession mechanism. Absolutely agreed that it would be bad to require it, but having the option there would be nice. > > > 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. > > Yes, I already have a draft with essentially this mechanism in the works. I've been discussing the design with other folks for a while now, and I hope to introduce it to the mailing list here in the near future. Aaron
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
