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
