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>
