Hi Uri, > Need to create a CSR for a key pair whose algorithm does not allow signing
I believe you don't. I believe that CSR (aka PKCS#10, aka RFC 2986) requires a *signature*. A couple of years ago I attempted to summarize the state of IETF cert enrollment protocols for non-signing keys: see slides 27-28 of my Jan 2021 LAMPS presentation: https://datatracker.ietf.org/doc/slides-interim-2021-lamps-01-sessa-position-presentation-by-mike-ounsworth/ Summary: Yes: CMP, EST-with-full-CMC. No: Lightweight CMP, EST. ACME should also be here since it requires a CSR. Shameless plug: I recently did some work with Güneysu, Hodges, Land, Stebila, Zaverucha developing a ZKP-based "verifiable generation" KEM PoP mechanism for FrodoKEM and Kyber. https://eprint.iacr.org/2022/703 --- Mike Ounsworth -----Original Message----- From: Spasm <spasm-boun...@ietf.org> On Behalf Of Blumenthal, Uri - 0553 - MITLL Sent: October 4, 2022 10:06 AM To: sp...@ietf.org; tls@ietf.org Subject: [EXTERNAL] [lamps] 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. ______________________________________________________________________ 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 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls