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
