Q: creating CSR for encryption-only cert?

[Blumenthal, Uri - 0553 - MITLL]

Thank you - and it’s great to see that 100% PQ Key Exchange is working with the existing code (I assume - based on liboqs?). 

But generating signature is not acceptable in my use case, which is why we settled on a KEMTLS-like approach. Or, conceptually, like MQV/HMQV. Authenticating the peer implicitly by having its long-term (certified) public key participating in the Key Exchange. 

I fully realize that the current TLS-1.3 does not support this kind of Key Exchange. Which is fine, because we’re not using TLS. :-)

Thanks

Regards,
Uri

> On Oct 3, 2022, at 17:02, Mark Hack <markhack at markhack.com> wrote:
> 
> 
> In this case you need to look at certificate / signature generation separately from the key exchange.  In classical terms, I can have anRSA key with a RSA-SHA256 signature and use DHE elliptic curves to exchange a secret without knowing the elliptic curve public private key pair.
> 
> For example to use Dilthium public/private keys and a Dilithium signature , you can use the following to generate a csr ( or self sign):
> 
> openssl req -new -newkey dilithium2  -keyout qsc.key -config openssl.cnf -nodes 
> 
> 
> After you have the signed certificate, TLS uses that certificate but specifies Kyber for the key exchanges.
> 
> I self signed a dilithium certificate and started a server using:
> openssl s_server -cert  dilithium.crt -key dilithium.key -groups kyber768 
> 
> 
> Then connected with a client using:
> openssl s_client -connect 127.0.0.1:4433  -groups kyber768
> 
> This return a good connection:
> 
> No client certificate CA names sent
> Peer signature type: Dilithium2
> Server Temp Key: kyber768
> ---
> SSL handshake has read 7911 bytes and written 1589 bytes
> Verification error: self signed certificate
> ---
> New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
> Server public key is 10496 bit
> 
> 
> Regards
> Mark Hack
> 
> 
> 
>> 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
>>  
>> 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
>>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221003/0506345b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5819 bytes
Desc: not available
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221003/0506345b/attachment-0001.p7s>