[openssl-users] Creating an X25519-based Certificate

[Jakob Bohm]

Which brings back my generalized question from yesterday:

Since X25519 is not the first "encrypt-only" algorithm in the
OpenSSL universe, how was requesting certificates handled for
such algorithms in the past?

For example how would one request a DH certificate?

Whatever was defined back then might be trivially extended
to also handle X25519.


On 30/06/2016 10:37, Erwann Abalea wrote:
> Ok, you’re talking about OpenSSL command line tool only, I missed that 
> part.
>
> The solution should then be to modify apps/ca.c:certify() function to 
> add an arg, and avoid the call to X509_REQ_verify when desired.
>
>> Le 29 juin 2016 à 19:17, Michael Scott <mike.scott at miracl.com 
>> <mailto:mike.scott at miracl.com>> a écrit :
>>
>> Thanks Erwann, but that's not an answer to my question.
>>
>> To get the CA to sign (using RSA or anything) a certificate that 
>> contains an X25519 public key, that certificate must first submit to 
>> the CA something called a "Certificate request". This takes the form 
>> of the supplicant certificate, which is self-signed. However you 
>> cannot self-sign with an X25519 key (using the openssl command line 
>> tool), as it objects that X25519 does not support signature.
>>
>> So the issue arises around the "certificate request" process. There 
>> is I agree no problem in creating the certificate itself.
>>
>> On Wed, Jun 29, 2016 at 4:27 PM, Erwann Abalea 
>> <Erwann.Abalea at docusign.com <mailto:Erwann.Abalea at docusign.com>> wrote:
>>
>>     Bonjour,
>>
>>     You may have a classic certificate containing your
>>     {X,Ed}{25519,448,whatever} public key once:
>>
>>       * an OID is allocated to identify this type of public key (it
>>         will go into tbs.subjectPublicKeyInfo.algorithm.algorithm)
>>       * a set of associated optional parameters are defined for this
>>         OID (to go into tbs.subjectPublicKeyInfo.algorithm.parameters)
>>       * a canonical encoding for this type of public key is defined,
>>         so the key material can be enclosed into
>>         tbs.subjectPublicKeyInfo.subjectPublicKey
>>
>>
>>     This certificate may be RSA-signed or ECDSA-signed (or
>>     whatever-signed, in fact).
>>
>>     For a CA to be able to Ed{25519,448,whatever}-sign something, the
>>     previous steps must have been done, plus:
>>
>>       * an OID is allocated to identify the signature algorithm to
>>         apply (it will not be ECDSA) -> cert.signatureAlgorithm.algorithm
>>       * a set of associated optional parameters are defined for this
>>         OID -> cert.signatureAlgorithm.parameters
>>       * a canonical encoding for the signature value is defined, so
>>         it can be enclosed into cert.signatureValue
>>
>>
>>     All this is being discussed at CFRG.
>>
>>>     Le 29 juin 2016 à 16:46, Michael Scott <mike.scott at miracl.com
>>>     <mailto:mike.scott at miracl.com>> a écrit :
>>>
>>>     How do I do this? Using the OpenSSL command line tool, a
>>>     certificate request must be self-signed, but the X25519 elliptic
>>>     curve (newly supported in version 1.1.0), doesn't do signature,
>>>     it can only be used for key exchange.
>>>
>>>     (Of course the X25519 Montgomery curve is birationally
>>>     equivalent to an Edwards curve which can do signature. And
>>>     indeed it is our intention to use the Edwards curve. But first I
>>>     need a CA-signed X25519 cert. But because of the above catch-22
>>>     problem, I cannot create one.)
>>>
Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160630/60740c16/attachment.html>