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

Reply via email to