For CT logs as in 'CT used for public web sites' there is no possibility to delay submitting. The only currently used mechanism is submission to CT logs of pre-certificates, before the final certificate is signed. So CT log entries will always be there, and so must the final certificate be issued and responded to for OCSP requests, revoked or not. The only thing you can do in the Public TLS eco system is to revoke if something goes wrong after the pre-certificate submission.
Two step protocols for certificate issuance is hard to scale up to large scale in a robust way imho. Not my favorite. Cheers, Tomas ________________________________ From: Spasm <spasm-boun...@ietf.org> on behalf of Thom Wiggers <t...@thomwiggers.nl> Sent: Thursday, October 6, 2022 12:07 PM To: 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] [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 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
