This is indeed an interesting discussion. So from my reading and understanding, the Encrypted POP would NOT be ideal when paired with a CT log is because the preCertificate would already be logged before the entity requesting certification was able to do proof possession of the private key. If the end-entity does not have the private key, they can never decrypt the certificate and thus the CT log has an entry for a failed certificate. This could obviously be exploited by bad actors.
From 4211 section 4.2: POP for key encipherment keys is accomplished by one of three different methods. The private key can be provided to the CA/RA, an encrypted challenge from the CA/RA can be decrypted (direct method), or the created certificate can be returned encrypted and used as the challenge response (indirect method). For a use case like an HSM or TPM where private keys can never leave rules out option 1 (plus who wants to send their private key anyway unless it is for server backup or escrow purposes). Option 3 would work but is bad for CT log spamming. Option 2 of using an encrypted challenge seems like the best choice, but obviously causes a 2nd round trip. There doesn’t seem to be an ideal solution. I tried to think about whether using a KEM POP would be any better, but so far have concluded that it would have the same issues. Cheers, John Gray From: Spasm <spasm-boun...@ietf.org> On Behalf Of Mike Ounsworth Sent: Thursday, October 6, 2022 12:05 PM To: Thom Wiggers <t...@thomwiggers.nl>; Tomas Gustavsson <tomas.gustavs...@keyfactor.com> Cc: von Oheimb, David <david.von.ohe...@siemens.com>; u...@ll.mit.edu; openssl-us...@openssl.org; morgan...@dataio.com; sp...@ietf.org; tls@ietf.org Subject: Re: [lamps] [EXTERNAL] Re: [TLS] Q: Creating CSR for encryption-only cert? > Precertificates, the same "base" TBSCertificate as the final cert + Poison > extension, is signed by the CA Right. Same end result though: you can not use the CT precertificate to satisfy an indirect encryption PoP challenge where the final certificate is the challenge text. --- Mike Ounsworth From: Spasm <spasm-boun...@ietf.org<mailto:spasm-boun...@ietf.org>> On Behalf Of Thom Wiggers Sent: October 6, 2022 9:06 AM To: Tomas Gustavsson <tomas.gustavs...@keyfactor.com<mailto:tomas.gustavs...@keyfactor.com>> Cc: von Oheimb, David <david.von.ohe...@siemens.com<mailto:david.von.ohe...@siemens.com>>; u...@ll.mit.edu<mailto:u...@ll.mit.edu>; openssl-us...@openssl.org<mailto:openssl-us...@openssl.org>; morgan...@dataio.com<mailto:morgan...@dataio.com>; sp...@ietf.org<mailto:sp...@ietf.org>; tls@ietf.org<mailto: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 Tomas, all, Good discussion today, I'm learning some new things :D Op do 6 okt. 2022 om 13:37 schreef Tomas Gustavsson <tomas.gustavs...@keyfactor.com<mailto:tomas.gustavs...@keyfactor.com>>: For CT logs as in 'CT used for public web sites' there is no possibility to delay submitting. Ah, of course it does. I must've been low on coffee when I forgot that the SCT is obviously computed through submission to a log, rather than over a promise to submit. I suppose that pretty much rules out the "implicit" challenge-is-encrypted-cert method described in CMRF/CMP for web certificates then. Otherwise one might spam CT logs? Cheers and thanks, 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
