Yes, I can certainly program my way out of the problem, but it would be
nice if the command line tool allowed me a way to do it.
Thanks!
Mike
On Thu, Jun 30, 2016 at 9:37 AM, Erwann Abalea <Erwann.Abalea at docusign.com>
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.
>
> Cordialement,
> Erwann Abalea
>
> Le 29 juin 2016 ? 19:17, Michael Scott <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.
>
>
> Mike
>
>
>
> On Wed, Jun 29, 2016 at 4:27 PM, Erwann Abalea <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.
>>
>> Cordialement,
>> Erwann Abalea
>>
>> Le 29 juin 2016 ? 16:46, Michael Scott <mike.scott at miracl.com> a ?crit :
>>
>> Hello,
>>
>>
>> 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.)
>>
>>
>> Mike
>>
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160630/ca07f48f/attachment-0001.html>
