Shouldn't it be possible to delay the addition to the CT log until the confirmation (which may be based on decrypting the new cert or any other challenge) by the EE has arrived at the CA?
Looks like anyway all known PoP mechanisms for keys that cannot be used for signing appear to require a second protocol step (except for the non-acceptable disclosure of the private key to the CA): * For the encrypted challenge by the CA, this is obvious. * Also for the encrypted cert, as I mentioned before, the CA needs to receive the hash value of the decrypted cert in order to learn the PoP. I agree with Tomas that a 2nd protocol step (i.e., a 2nd upstream message by the EE) is not nice (for several reasons, in particular the need to keep in between a transaction state), but I don't see any way to avoid it. Yet I think that at least a full 2nd round trip (such as the CMP pkiConf ack message by the CA) is not needed (well, unless the general protocol design, as for CMP, demands that all upstream messages are answered). David On Thu, 2022-10-06 at 17:09 +0000, John Gray wrote: 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. On Thu, 2022-10-06 at 11:37 +0000, Tomas Gustavsson wrote: 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
