I concur with what the others have said here. My overarching concern is that this draft seems *too* PQC-specific: the general capabilities it describes are useful outside the context of PQC, and the general ideas herein should be standardized in a more flexible manner.
The issue of confirmation of control of the private key is a non-issue that does not need to be addressed by this document. The ACME protocol as it stands (not to mention most other non-standardized issuance protocols) does not prove that the Applicant controls the private key corresponding to the public key they request to have in their certificate. Presentation of a signed CSR does not prove control of the corresponding private key, as CSRs are public information and anyone can present any CSR they find lying around the web. 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. 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. Again, I think an approach like this covers the use-cases supposed by this draft, but generalizes much wider than just PQC algorithm selection. Aaron On Sun, Aug 6, 2023 at 6:39 AM Seo Suchan <tjtn...@gmail.com> wrote: > thoughs in no particular order: > > 1. I don't think section 3's 1RTT mode works. CA already signed the > certificate if it can give out encrypted version of it, then client can get > certificate from CT log. > > 2. is there a reason to include just PQC algos on list of supported > algorithm endpoint? I think there is no reason to not include classical > algorithms there, as those have parameters CA may refuse (rsa keysize, > ecdsa curves) > > 3. LE doesn't consider CSR as proof of possession of private key (so you > need sign revoke request with certs privkey to use reason key compromise), > and TLS CA/B BR doesn't actually require to check it. > 2023-08-06 오후 8:00에 Alexandre Augusto 이(가) 쓴 글: > > Dear chairs and WG, > > I would like to share our proposal for improving ACME with algorithm > negotiation support. The main features are: > - Flexibility: allows clients to know (in advance) if their desired > algorithm is supported by the server; > - Automated Issuance of KEM certificates: currently not supported in ACME, > our proposal specifies two ways to allow clients asking for such a > certificate. > > Link: https://datatracker.ietf.org/doc/draft-giron-acme-pqcnegotiation/ > > If there is any interest, doubts, please let me know. I'll be happy to > discuss it with you. > > Best regards, > -- > Alexandre Augusto Giron > Federal University of Technology - Parana (UTFPR > <https://coenc.td.utfpr.edu.br/%7Egiron/>) > PhD Student at Federal University of Santa Catarina (UFSC) > > > > _______________________________________________ > Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
