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.sc...@miracl.com
<mailto:mike.sc...@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.aba...@docusign.com <mailto:erwann.aba...@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.sc...@miracl.com
<mailto:mike.sc...@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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
