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 PoP. This was the target for 1.3 with signatures. -Ekr On Wed, Oct 5, 2022 at 6:47 AM Russ Housley <hous...@vigilsec.com> wrote: > 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 <m...@lowentropy.net> 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 these complications... > > > > On Wed, Oct 5, 2022, at 03:05, Russ Housley wrote: > >> 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). > >> > >> Russ > >> > >> > >>> On Oct 4, 2022, at 11:05 AM, Blumenthal, Uri - 0553 - MITLL < > u...@ll.mit.edu> wrote: > >>> > >>> TL;DR > >>> Need to create a CSR for a key pair whose algorithm does not allow > signing (either because it’s something like Kyber, or because restriction > enforced by HSM). How to do it? > >>> > >>> Longer version: > >>> > >>> There are several use cases that require certifying long-term > asymmetric keys that are only capable of encryption/decryption – but not > signing/verification. That could be either because the algorithm itself > does not do signing, or because the private key is generated and kept in a > secure hardware that enforces usage restriction. > >>> > >>> One example of a protocol that needs this is KEMTLS - which I hope is > accepted, either as-is, or with simplification. > >>> > >>> CSR is supposed to be signed by the corresponding private key to prove > possession. Obviously, it cannot be done with a key such as described > above. How is this problem addressed in the real world? With AuthKEM and > KEMTLS, how would these protocols get their certificates? > >>> > >>> A short discussion of this issue on the OpenSSL mailing list brought > up Certificate Management Protocol (CMP) and CRMF format. Is that where > we're heading? Are the "big CAs" on board with it? > >>> > >>> Thanks! > >>> -- > >>> V/R, > >>> Uri > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
