This draft raises an interesting side-question: do we actually need ACME for KEM certs? If so, for which use-cases? The flippant answer is “We never needed to support ECDH PoP, so why do we need to support KEM PoP?”.
I think for TLS certs, ACME needs to support KEM certs if-and-only-if draft-celi-wiggers-tls-authkem gets adopted by the TLS WG. For S/MIME we clearly need to support KEM certs, which I assume would fall under RFC8823 which says “just do a CSR for your encryption-only key” – although I notice that 8823 does not tell me how I’m supposed to sign my “encryption-only CSR”. I would bet $50, or a beverage of your choice in Prague, that there exist almost no S/MIME clients or CAs that support ECDH certs, so in practice we just cheat and sign the CSR with the RSA encryption key. If that’s true that S/MIME just entirely skipped over ECDH as a technology, then we may actually have a novel problem to solve here in the form of “How do you do a CSR for a key that can’t sign?”. --- Mike Ounsworth Software Security Architect, Entrust From: Acme <acme-boun...@ietf.org> On Behalf Of Tim Hollebeek Sent: Tuesday, August 8, 2023 1:54 PM To: Aaron Gable <aaron=40letsencrypt....@dmarc.ietf.org>; Seo Suchan <tjtn...@gmail.com> Cc: Alexandre Augusto <alexandre.a.gi...@gmail.com>; acme@ietf.org; Lucas Pandolfo Perin <lucas.pe...@tii.ae>; Ricardo Custódio <ricardo.custo...@ufsc.br>; victor.va...@grad.ufsc.br Subject: [EXTERNAL] Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME I agree that generic support for profile selection and migration between protocols is superior. PQC isn’t actually particularly special or relevant to ACME, and we should avoid putting PQC-specific stuff into protocols that don’t need it, because I agree that generic support for profile selection and migration between protocols is superior. PQC isn’t actually particularly special or relevant to ACME, and we should avoid putting PQC-specific stuff into protocols that don’t need it, because we’ll be maintaining some of these protocols far into the future, when we might be more worried about the transition to Imperial Galactic Standard Certificates instead of PQC. -Tim From: Acme <acme-boun...@ietf.org<mailto:acme-boun...@ietf.org>> On Behalf Of Aaron Gable Sent: Tuesday, August 8, 2023 12:44 PM To: Seo Suchan <tjtn...@gmail.com<mailto:tjtn...@gmail.com>> Cc: Alexandre Augusto <alexandre.a.gi...@gmail.com<mailto:alexandre.a.gi...@gmail.com>>; acme@ietf.org<mailto:acme@ietf.org>; Lucas Pandolfo Perin <lucas.pe...@tii.ae<mailto:lucas.pe...@tii.ae>>; Ricardo Custódio <ricardo.custo...@ufsc.br<mailto:ricardo.custo...@ufsc.br>>; victor.va...@grad.ufsc.br<mailto:victor.va...@grad.ufsc.br> Subject: Re: [Acme] Internet-Draft: PQC Algorithm negotiation in ACME 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<mailto: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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-giron-acme-pqcnegotiation/__;!!FJ-Y8qCqXTj2!Z6yUOEWR0uj5__zd5h6OuV32KbMZsdOIo1LG1S1Ytwjtw92vDUNfPkoeaEhD09QA-ENn_uKx9ENTEsoOS1E0XM3xbIpbcdW1wzH5$> 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://urldefense.com/v3/__https:/coenc.td.utfpr.edu.br/*7Egiron/__;JQ!!FJ-Y8qCqXTj2!Z6yUOEWR0uj5__zd5h6OuV32KbMZsdOIo1LG1S1Ytwjtw92vDUNfPkoeaEhD09QA-ENn_uKx9ENTEsoOS1E0XM3xbIpbcYZ7IpX9$>) PhD Student at Federal University of Santa Catarina (UFSC) _______________________________________________ Acme mailing list Acme@ietf.org<mailto:Acme@ietf.org> https://www.ietf.org/mailman/listinfo/acme<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!Z6yUOEWR0uj5__zd5h6OuV32KbMZsdOIo1LG1S1Ytwjtw92vDUNfPkoeaEhD09QA-ENn_uKx9ENTEsoOS1E0XM3xbIpbcbbjojgv$> _______________________________________________ Acme mailing list Acme@ietf.org<mailto:Acme@ietf.org> https://www.ietf.org/mailman/listinfo/acme<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!Z6yUOEWR0uj5__zd5h6OuV32KbMZsdOIo1LG1S1Ytwjtw92vDUNfPkoeaEhD09QA-ENn_uKx9ENTEsoOS1E0XM3xbIpbcbbjojgv$> Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
