> That said, I believe CT is not actually problematic because public CAs > (typically? always?) publish precerts in the SCT which are only the > TBSCertificate with no CA signature, so > the CT log does not actually contain enough data to successfully respond to > the PoP challenge
That is not so in CT v1. CT v1, RFC6962, is the version in use on the Internet today, with no (to my knowledge) schedule to move to CT v2. Precertificates are real signed certificates, just that they include a critical Poison extension to prevent them from being used as the real certificates. Currently to my knowledge, all precertificates in use today are signed using the CAs signing key. Precertificates, the same "base" TBSCertificate as the final cert + Poison extension, is signed by the CA, sent to CT logs, who then return SCT, which are included as extensions in the final certificate, which are then sent back to the subscriber. This work-flow safely ensures logging of CA signed precertificates before the final cert is received by the subscriber. Cheers, Tomas ________________________________ From: Spasm <spasm-boun...@ietf.org> on behalf of Mike Ounsworth <Mike.Ounsworth=40entrust....@dmarc.ietf.org> Sent: Thursday, October 6, 2022 3:21 PM To: Thom Wiggers <t...@thomwiggers.nl>; von Oheimb, David <david.von.ohe...@siemens.com> Cc: u...@ll.mit.edu <u...@ll.mit.edu>; openssl-us...@openssl.org <openssl-us...@openssl.org>; morgan...@dataio.com <morgan...@dataio.com>; sp...@ietf.org <sp...@ietf.org>; tls@ietf.org <tls@ietf.org> Subject: Re: [lamps] [EXTERNAL] Re: [TLS] Q: Creating CSR for encryption-only cert? CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email info...@keyfactor.com with any questions. Hi Thom, > Yeah, that's something that came up a few times while we were working on > KEMTLS (and it eventually resulted in this paper by Güneysu, Hodges, Land, > Ounsworth, Stebila, and Zaverucha [1]). They also have some nice references > for the kinds of attacks that "sloppy" issuance could lead to in Appendix A. Whether or not PoP at issuing time is actually providing any tangible security seems to be the biggest can of worms in the PKI world; going all the way back to the original meetings in the ‘90’s with many opinions and no clear resolution. As you point out about the indirect PoP mechanisms: using the final cert as the challenge text seems like it should be problematic. It’s certainly annoying for the CA because you have to hold off on things like putting the cert in your audit logs, or publishing it to a enterprise LDAP until the client has completed the challenge response. That said, I believe CT is not actually problematic because public CAs (typically? always?) publish precerts in the SCT which are only the TBSCertificate with no CA signature, so the CT log does not actually contain enough data to successfully respond to the PoP challenge. --- Mike Ounsworth From: Spasm <spasm-boun...@ietf.org> On Behalf Of Thom Wiggers Sent: October 6, 2022 5:08 AM To: von Oheimb, David <david.von.ohe...@siemens.com> Cc: u...@ll.mit.edu; openssl-us...@openssl.org; morgan...@dataio.com; sp...@ietf.org; tls@ietf.org Subject: [EXTERNAL] Re: [lamps] [TLS] Q: Creating CSR for encryption-only cert? WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. ________________________________ Hi David, Thanks for your email; you sent it right on time as I'd just started composing a similar email based on my reading of section 4.2 of RFC4211. Op do 6 okt. 2022 om 09:58 schreef Thom Wiggers <t...@thomwiggers.nl<mailto:t...@thomwiggers.nl>>: We weren't aware of CRMF, so it seems I've got some reading to do as I write some paragraphs on KEM certificates in my PhD thesis :) Digging into RFC4211 and as David just wrote, my interpretation of the "indirect method" specified there mostly lines up with the "encrypt certificate" approach I described in my previous email. CRMF, as an interactive protocol, does require that you prove to the issuer that you decrypted correctly, as David wrote, so I suppose that this makes it important that the protocol that implements CRMF delays submitting to the CT logs until after they've received confirmation, to avoid the "attack" that I described. Of course, that still means that the "encrypt certificate" message does not work for the kinds of "non-interactive" issuance that CSRs allow. I'll continue my reading with your pointers, thanks :) Cheers, Thom Any email and files/attachments transmitted with it are confidential and 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
