Creating an X25519 client certificate

[Robert Moskowitz]

On 3/17/21 7:22 PM, Viktor Dukhovni wrote:
> On Wed, Mar 17, 2021 at 05:50:41PM -0400, Robert Moskowitz wrote:
>
>> I have created my X25519 pub/priv keypair with:
>>
>> openssl genpkey -algorithm X25519\
>>       -out $dir/private/$clientemail-X.key.$format
> Are you sure you didn't want ed25519 instead?  X25519 is a key agreement
> menthod, not a signature method.

My limited understanding is that for encrypted S/MIME, and ECDH cert is 
needed.  Thus if ED25519 is used for signing said S/MIME, X25519 is used 
for encrypting.

I have seen CA Cert policies for "Device Encryption Certificates" that 
use:  id-ecPublicKey {1 2 840 10045 2 1}; I need to talk to the CP 
author more about this and what he sees the equiv Edward cert would look 
like.

>
>> openssl req -config $dir/openssl-intermediate.cnf\
>>       -key $dir/private/$clientemail-X.key.$format \
>>       -subj "$DN" -new -out $dir/csr/$clientemail-X.csr.$format
>>
>> which is what I used for ED25519 client certs.  But I get an error:
>>
>> 140487683954496:error:0608D096:digital envelope
>> routines:EVP_PKEY_sign_init:operation not supported for this
>> keytype:crypto/evp/pmeth_fn.c:39:
> Not surprising, why do you expect this to work?

Shooting from the hip, a bit.  If I am going to have an X25519 cert, 
then I need a csr and this is the command to make one.  So try it and 
see what it does.  Not too well, it turns out.

>
>> Can someone point me to what I am missing?
>>
>> Oh, and I am ASSuMEing that a CA cert of ED25519 signs an X25519 client
>> cert.  Haven't found instructions on this, but it seems reasonable...
> https://crypto.stackexchange.com/questions/27866/why-curve25519-for-encryption-but-ed25519-for-signatures
>
very familiar with this point and did look at this response during my 
searches today.

I quite understand in TLS the use of EdDSA certs that allow 
keyEncipherment and ?dataEncipherment? to permit an ECDHE exchange.

but my limited research claims that for S/MIME you can have an X25519 
cert for static ECDH, rather than ephemeral, saving supposedly the 
exchange of keys before sending encrypted S/MIME.