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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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://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@xxxxxxxxxxx.
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/BN0P110MB141960C4C230AF2B6D3D47C69008A%40BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM.

Attachment: smime.p7s
Description: S/MIME cryptographic signature


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux