creating CSR for encryption-only cert?

[David von Oheimb]

My pleasure!
OpenSSL supports CRMF and CMP since version 3.0.
EJBCA supports these since long, and there are also other CAs that support CMP and thus CRMF., such as the Insta CA.
Yet the support for encryption-based PoP by now likely is not strong - mostly because so far there was not much interest for it.
The OpenSSL CMP client implemenation does support sending cert requests without PoP,
and it should also support using encryption-based PoP, but I cannot recall having tried it out.
For simple examples of using CMP with the OpenSSL CLI, see at the bottom of the openssl-cmp man page.

David



On Mon, 2022-10-03 at 19:48 +0000, Blumenthal, Uri - 0553 - MITLL wrote:

David,

 

Thank you! That’s a great answer. It looks like OpenSSL does support CRMF? Would you or somebody else have an example of how to work with CRMF (to create it, and to process/sign it)?

 

Do you happen to know if CRMF is accepted by the “big players” in the CA field?

 

*Thank you again!*

-- 

V/R,

Uri

/ /

/There are two ways to design a system. One is to make it so simple there are obviously no deficiencies./

/The other is to make it so complex there are no obvious deficiencies./

/                                                                                                                                     -  C. A. R. Hoare/

 

 

*From: *David von Oheimb <it at von-Oheimb.de>
*Date: *Monday, October 3, 2022 at 15:13
*To: *Uri Blumenthal <uri at ll.mit.edu>, openssl-users <openssl-users at openssl.org>
*Subject: *Re: Q: creating CSR for encryption-only cert?

 

Requesting a cert in a CSR for a key pair that cannot be used for signing is indeed impossible in the widely used PKCS#10 format
(except if one break sthe PKCS#10 requirement of a self-signature, e.g., by applying a dummy signature).

A viable solution is to use a different CSR format, such as CRMF.
This format is the preferred one by CMP and CMC (while they also support PKCS#10) because it is much more flexible.
CRMF does not strictly require to provide a proof-of-possession (PoP), and it offeres also indirect ways of doing a PoP.
For instance, for encryption keys the new cert can be returned by the CA in encrypted form (using the new public key) to the EE,
and the EE will only be able to make use of the cert if it is able to decrypt it, which proves possession of the private key.

David


On Mon, 2022-10-03 at 15:11 +0000, Blumenthal, Uri - 0553 - MITLL wrote:

> TLDR;
> 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?
>  
> 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.
>  
> 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?
>  
> Thanks!
> --
> V/R,
> Uri Blumenthal                              Voice: (781) 981-1638 
> Secure Resilient Systems and Technologies   Cell:  (339) 223-5363
> MIT Lincoln Laboratory                     
> 244 Wood Street, Lexington, MA  02420-9108      
>  
> Web:     https://www.ll.mit.edu/biographies/uri-blumenthal
> Root CA: https://www.ll.mit.edu/llrca2.pem
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221003/5fd2e170/attachment.htm>