Re: [EXT] Re: How to generate ML-KEM key-pair?

> Is there a good ("convenient") example of a text file that contains
> extensions (a) suitable for a CA (that would be for the ML-DSA
> "keyholder"), and (b) suitable for a TLS or IPsec peer (that would for
> the ML-KEM cert holder)? Something in a format
> "ready-for-OpenSSL-consumption"? 

Perhaps the below will help?

https://docs.google.com/presentation/d/1xU2-U_6uUW4gB3j_v7EQC81t1RZ_slHyY_91MLlMDEg/edit#slide=id.g2b4be0ee06d_0_0 <https://docs.google.com/presentation/d/1xU2-U_6uUW4gB3j_v7EQC81t1RZ_slHyY_91MLlMDEg/edit#slide=id.g2b4be0ee06d_0_0>
https://www.youtube.com/watch?v=OuH4vwmzP_o <https://www.youtube.com/watch?v=OuH4vwmzP_o> 

Oh, it absolutely does – thank you! 

$ openssl x509 -new -key prkey-dsa.pem -out dsa-ca.pem -force_pubkey pubkey-dsa.pem -set_issuer "/CN=Experimental_PQ_CA" -set_subject "/CN=Experimental_PQ_CA" -days 360 -extfile <(printf "basicConstraints=critical,CA:true,pathlen:1\n") 
$ 
$ openssl x509 -new -key prkey-dsa.pem -force_pubkey pubkey-kem.pem -out kem-cert.pem -subj "/CN=PQ_KEM_Entity" -set_issuer "/CN=Experimental_PQ_CA" -days 360 -extfile <(printf "keyUsage=keyEncipherment\n") 
Warning: Signature key and public key of cert do not match 
$ 
$ openssl verify -show_chain -CAfile dsa-ca.pem kem-cert.pem 
kem-cert.pem: OK 
Chain: 
depth=0: CN=PQ_KEM_Entity (untrusted) 
depth=1: CN=Experimental_PQ_CA 
$ 
$ 
$ openssl verify -show_chain -trusted dsa-ca.pem kem-cert.pem 
kem-cert.pem: OK 
Chain: 
depth=0: CN=PQ_KEM_Entity (untrusted) 
depth=1: CN=Experimental_PQ_CA 
$ 

The above – worked, thanks! 

Perhaps you could clue me in regarding “(untrusted)” in the above? 

Also, am I correct to assume that if I choose to prepare extension templates, those files would look like: 
For CA template (ca-template.txt): 
basicConstraints = critical, CA:TRUE, pathlen:1 
keyUsage = critical, digitalSignature, nonRepudiation, keyCertSign 

For KEM cert template (kem-template.txt): 
basicConstraints = critical, CA:FALSE 
keyUsage = critical, keyEncipherment 

and I’d be able to refer to them in the “openssl x509 …..” command above as “-extfile kem-template.txt”? 

If the format of the above files should be more elaborate – I’d appreciate being “clued in”! 

> Since my use case is similar to KEMTLS, I’m perfectly happy with being
> unable to sign with the subject key. Implicit authentication is all I
> need here. 

Then, assuming it still makes sense for the payload to be an X.509
certificate, and not something much simpler (like a delegated
credential), you should be all set. 

Unless I’m mistaken, delegated credentials are supposed to have very short lifetime, and be “renewed” (re-“retrieved”) quite often. My use case suggests (reasonably) long-term certificates, whose main difference from the traditional PKI for TLS or IPsec is that they’re used in implicit authentication, rather than for generating dynamic signatures during the handshake. 

Perhaps, I need to understand “delegated credentials” better. Though there’d be a question of whether my infrastructure is ready and willing to embrace that concept, and the workflows it would require… 

Thank you!! 





-- 
You received this message because you are subscribed to the Google Groups "openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-users+unsubscribe-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/BN0P110MB141960C4C230AF2B6D3D47C69008A%40BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM.