Hi Thom, On Thu, 2022-10-06 at 12:07 +0200, Thom Wiggers wrote:
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 <[email protected]<mailto:[email protected]>>: 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. Yes. The 2nd round trip using CMP certConf/pkiConf messages usually is done already for a reason that applies to all key types: to confirm to the CA that the EE received the new cert and is happy with it. Only then should the cert be published and used. This is something not supported by a simple round trip (including the typical use of PKCS #10 CSRs), which you referred to as "non-interactive" issuance. Of course, that still means that the "encrypt certificate" message does not work for the kinds of "non-interactive" issuance that CSRs allow. Please note that the term CSR is actually broader that just PKCS #10 - it applies also to other formats, such as CRMF. I've just made this clear in https://en.wikipedia.org/wiki/Certificate_signing_request and pointed out there the main limitation of the PKCS #10 format. I'll continue my reading with your pointers, thanks :) Happy reading on CRMF and alternative forms of PoP [:-)] Yet the novelties in the upcoming RFCs that I also mentioned do not include new contents regarding PoP. Regards, David
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
