Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?

2022-10-06 Thread von Oheimb, David
Hi Thom, Tomas, and Mike, On Thu, 2022-10-06 at 16:05 +0200, Thom Wiggers wrote: Good discussion today, I'm learning some new things :D me too, namely regarding CT in relation to certificate conformation [:-)] Yet please let's keep openssl-us...@openssl.org ou

Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?

2022-10-06 Thread Thom Wiggers
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>: > 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

Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?

2022-10-06 Thread von Oheimb, David
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 mailto:t...@thomwiggers.nl>>: We weren'

Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?

2022-10-06 Thread Tomas Gustavsson
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 issue

Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?

2022-10-06 Thread Hanno Böck
On Wed, 05 Oct 2022 13:39:32 +1100 "Martin Thomson" wrote: > The integrity of TLS doesn't depend on the key holder presenting > proof of possession toward the issuing CA. Perhaps we could define > an extension that produced an empty signature, so that it could be > used for any algorithm without

Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?

2022-10-06 Thread Thom Wiggers
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 : > > We weren't aware of CRMF, so it seems I've got some reading to do as I > write some paragr

Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?

2022-10-06 Thread von Oheimb, David
Hi Thom, Uri, et al, I had responded to Uri on the openssl-users list on Oct 3rd at 21:12 +0200 as follows: Requesting a cert in a CSR for a key pair that cannot be used for signing is indeed impossible in the widely used PKCS#10 format (except if one break sthe PKCS#10 requirement of a self-si

Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?

2022-10-05 Thread Eric Rescorla
I wonder if MT is thinking forward to something like KEMTLS which used a KEM to prove possession to the peer? In any case, I think it would be good design criterion for TLS that it offer the same level of security -- including against identity misbinding attacks -- even if the CA does not verify P

Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?

2022-10-05 Thread Russ Housley
Martin: In TLS 1.3, this is not an issue because only the signature key gets certified. Russ > On Oct 4, 2022, at 10:39 PM, Martin Thomson wrote: > > The integrity of TLS doesn't depend on the key holder presenting proof of > possession toward the issuing CA. Perhaps we could define an exten

Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?

2022-10-04 Thread Martin Thomson
The integrity of TLS doesn't depend on the key holder presenting proof of possession toward the issuing CA. Perhaps we could define an extension that produced an empty signature, so that it could be used for any algorithm without these complications... On Wed, Oct 5, 2022, at 03:05, Russ Housl

Re: [TLS] [lamps] Q: Creating CSR for encryption-only cert?

2022-10-04 Thread Russ Housley
Uri: You cannot do it with PKCS#10. That is why CRMF (RFC 4211) was created. RFC 2875 and RFC 6955 talk about the proof-of-possession (PoP) of 2875 Diffie-Hellman keys. A similar PoP specification will be needed for Kyber, and some folks agreed to write the -00 version before IETF 115 (nudge