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

On Sun, Dec 29, 2024 at 05:58:01PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:

> 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

otherwise there are always the x509v3_config(5) and x509(1) manpages.

> $ openssl x509 -new -key /tmp/ed.pem -force_pubkey /tmp/ml-512-pub.pem \
>       -out /tmp/ml-cert.pem -subj / -days 30 -extfile <(
>       printf "keyUsage = keyEncipherment\n'
>       printf "subjectKeyIdentifier = none\n"
>       )
> 
> Thank you!! Yes, this works! 

If you need the subject and issuer to be different, you can instead try
some variant of:

    $ openssl x509 -new -key /tmp/ed.pem \
        -out /tmp/ml-cert.pem \
        -force_pubkey /tmp/ml-512-pub.pem \
        -set_issuer "/CN=Viktor Dukhovni" \
        -set_subject "/CN=viktor" \
        -days 30 -extfile <(
                printf "keyUsage = keyEncipherment\n'
                printf "subjectKeyIdentifier = none\n"
                printf "authorityKeyIdentifier = none\n"
            )

And end up with, say:

    $ openssl x509 -in /tmp/ml-cert.pem -noout -text \
        -certopt no_sigdump,no_serial,no_validity |
        sed -ne '1,/pub:/p;/extensions/,$p'
        Certificate:
        Data:
            Version: 3 (0x2)
            Signature Algorithm: ED25519
            Issuer: CN=Viktor Dukhovni
            Subject: CN=viktor
            Subject Public Key Info:
                Public Key Algorithm: ML-KEM-512
                    ML-KEM-512 Public-Key:
                    pub:
            X509v3 extensions:
                X509v3 Key Usage:
                    Key Encipherment

> > Perhaps you're looking to implement KEMTLS "delegated credentials"? 
> 
> Well, not exactly, not really – but I can see the similarity.
> 
> 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.

-- 
    Viktor.

-- 
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/Z3GWxwtl1EEYtg7I%40chardros.imrryr.org.