Mike: Enterprises that do face-to-face enrollment and issue a token that contains a signature certificate and a key management certificate do not need a PoP protocol for the key management private key.
Russ > On Aug 8, 2023, at 6:38 PM, Mike Ounsworth > <[email protected]> wrote: > > 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 <[email protected] <mailto:[email protected]>> On Behalf > Of Tim Hollebeek > Sent: Tuesday, August 8, 2023 1:54 PM > To: Aaron Gable <[email protected] > <mailto:[email protected]>>; Seo Suchan > <[email protected] <mailto:[email protected]>> > Cc: Alexandre Augusto <[email protected] > <mailto:[email protected]>>; [email protected] <mailto:[email protected]>; > Lucas Pandolfo Perin <[email protected] <mailto:[email protected]>>; > Ricardo Custódio <[email protected] > <mailto:[email protected]>>; [email protected] > <mailto:[email protected]> > 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 <[email protected] <mailto:[email protected]>> On Behalf > Of Aaron Gable > Sent: Tuesday, August 8, 2023 12:44 PM > To: Seo Suchan <[email protected] <mailto:[email protected]>> > Cc: Alexandre Augusto <[email protected] > <mailto:[email protected]>>; [email protected] <mailto:[email protected]>; > Lucas Pandolfo Perin <[email protected] <mailto:[email protected]>>; > Ricardo Custódio <[email protected] > <mailto:[email protected]>>; [email protected] > <mailto:[email protected]> > 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 <[email protected] > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > 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 > [email protected] <mailto:[email protected]> > 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 > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
