Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME

[Ilari Liusvaara <[e-mail]>]

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