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
