date:20160630

Re: [openssl-users] self-signed certificate won't work in my app but works with s_client

2016-06-30 Thread Matthew Donald

"error 18:self signed certificate" is the expected result if you are
validating a self-signed cert.

In certificate verification, the code needs to check for X509_V_OK,
X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT
and  X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY.

X509_V_OK is a normal cert verification and the connection can
proceed.  X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY
indicates that an otherwise valid cert has been processed, but the issuer
is unknown.  X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT indicates that a
self-signed cert was read.  Any other return value is a fatal error
(signature failure etc).

Matthew


On 1 July 2016 at 05:34, Carl Heyendal  wrote:

> I am working with the example apps in the "Networking Security with
> OpenSSL" book and up until now have been able to get client/server examples
> 1,2,3 to work. But now I'm trying to connect to an in-house tool but I'm
> getting the error "error 18:self signed certificate". Despite this error
> when I run my app (essentially client3), when I use s_client with the very
> same credentials...it works.
>
> I suspect that it has something to do with the ssl/tls api combination
> that I use in my 'client3' app.
>
> Here's the command and output for s_client that connects to the in-house
> tool which works:
>
> > openssl s_client -connect 192.168.1.99:16001 -CAfile
> ../_security/SipInspector/certificate.pem -key ../_security/client.pem
>   Enter pass phrase for ../_security/client.pem:
>   CONNECTED(0003)
>   depth=0 C = CA, ST = Ontario, L = Ottawa, O = SIP Inspector Ltd, OU
>  = Development, CN = 192.168.1.99
>   verify return:1
>   ---
>   Certificate chain
>0 s:/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector
> Ltd/OU=Development/CN=192.168.1.99
>  i:/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector
> Ltd/OU=Development/CN=192.168.1.99
>   ---
>   Server certificate
>   -BEGIN CERTIFICATE-
>   MIIFxTCCA62gAwIBAgIJALKQ3J5SEyjPMA0GCSqGSIb3DQEBCwUAMHkxCzAJBgNV
>   BAYTAkNBMRAwDgYDVQQIDAdPbnRhcmlvMQ8wDQYDVQQHDAZPdHRhd2ExGjAYBgNV
> (snip)
>   pt/q5/gKqRFbjyL0LDNz49vaSUYvbu3mgF2480Or4X+GPwemwdxJaF1pQw4C1WaF
>   RyfVjDrLNhTvv+zKCbEPyrjXCweNVRVcp8lZ8R0HmXwfgevlCNz/GQo=
>   -END CERTIFICATE-
>   subject=/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector
> Ltd/OU=Development/CN=192.168.1.99
>   issuer=/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector
> Ltd/OU=Development/CN=192.168.1.99
>   ---
>   No client certificate CA names sent
>   ---
>   SSL handshake has read 2309 bytes and written 509 bytes
>   ---
>   New, TLSv1/SSLv3, Cipher is ECDHE-RSA-DES-CBC3-SHA
>   Server public key is 4096 bit
>   Secure Renegotiation IS supported
>   Compression: NONE
>   Expansion: NONE
>   SSL-Session:
>   Protocol  : TLSv1.2
>   Cipher: ECDHE-RSA-DES-CBC3-SHA
>   Session-ID:
>  5755C781D91CF3177DF624EA3599EE430DAB4790F325FAD9378FEAE7731C4497
>   Session-ID-ctx:
>   Master-Key:
> D149008E43E29D658D29418C9F770B3D6018B1D7CA2F493027B0AC7C3BA8E53B572B68C371153568B8988A1E5F351839
>   Key-Arg   : None
>   PSK identity: None
>   PSK identity hint: None
>   SRP username: None
>   Start Time: 1465239425
>   Timeout   : 300 (sec)
>   Verify return code: 0 (ok)
>---
>
>
> Here's the command and output when I run my app that tries to connect to
> the same in-house tool which fails:
>
> > ./client3 192.168.1.99
> Enter PEM pass phrase:
> connecting to 192.168.1.99:16001
>  -Error with certificate at depth: 0
>issuer   = /C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector
> Ltd/OU=Development   /CN=192.168.1.99
>subject  = /C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector
> Ltd/OU=Development/CN=192.168.1.99
>err 18:self signed certificate
>  ** client3.c:94 Error connecting SSL object
> 139788992993088:error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
> failed:s3_clnt.c:1180:
> >
>
> Here are the api's I call in the my app that utilize the same credentials
> used by the s_client command:
>
>  SSL_CTX_new(SSLv23_method());
>  SSL_CTX_load_verify_locations(ctx,
> "../_security/SipInspector/certificate.pem", NULL)
>  SSL_CTX_use_PrivateKey_file(ctx, "../_security/client.pem",
> SSL_FILETYPE_PEM)
>  SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback);
>  SSL_CTX_set_verify_depth(ctx, 4);
>  SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2);
>
> And also I used the openssl verify command to double check the certificate
> against itself (not sure if this really does anything).
>
> Any help would be appreciated.
>
>
>
> Carl Heyendal | Software Developer
> 1826 Robertson Road | Ottawa, ON K2H 5Z6 | CANADA
> Office: +1 613-725-2980 x149
>
>
>
>
>
> ***  Please note that this message and any attachments may contain
> confidential and proprietary material and information and are intended on

[openssl-users] self-signed certificate won't work in my app but works with s_client

2016-06-30 Thread Carl Heyendal

I am working with the example apps in the "Networking Security with OpenSSL" 
book and up until now have been able to get client/server examples 1,2,3 to 
work. But now I'm trying to connect to an in-house tool but I'm getting the 
error "error 18:self signed certificate". Despite this error when I run my app 
(essentially client3), when I use s_client with the very same credentials...it 
works.

I suspect that it has something to do with the ssl/tls api combination that I 
use in my 'client3' app.

Here's the command and output for s_client that connects to the in-house tool 
which works:

> openssl s_client -connect 192.168.1.99:16001 -CAfile 
../_security/SipInspector/certificate.pem -key ../_security/client.pem
  Enter pass phrase for ../_security/client.pem:
  CONNECTED(0003)
  depth=0 C = CA, ST = Ontario, L = Ottawa, O = SIP Inspector Ltd, OU   =   
  Development, CN = 192.168.1.99
  verify return:1
  ---
  Certificate chain
   0 s:/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
 i:/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
  ---
  Server certificate
  -BEGIN CERTIFICATE-
  MIIFxTCCA62gAwIBAgIJALKQ3J5SEyjPMA0GCSqGSIb3DQEBCwUAMHkxCzAJBgNV
  BAYTAkNBMRAwDgYDVQQIDAdPbnRhcmlvMQ8wDQYDVQQHDAZPdHRhd2ExGjAYBgNV
(snip)
  pt/q5/gKqRFbjyL0LDNz49vaSUYvbu3mgF2480Or4X+GPwemwdxJaF1pQw4C1WaF
  RyfVjDrLNhTvv+zKCbEPyrjXCweNVRVcp8lZ8R0HmXwfgevlCNz/GQo=
  -END CERTIFICATE-
  subject=/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
  issuer=/C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 2309 bytes and written 509 bytes
  ---
  New, TLSv1/SSLv3, Cipher is ECDHE-RSA-DES-CBC3-SHA
  Server public key is 4096 bit
  Secure Renegotiation IS supported
  Compression: NONE
  Expansion: NONE
  SSL-Session:
  Protocol  : TLSv1.2
  Cipher: ECDHE-RSA-DES-CBC3-SHA
  Session-ID:   
5755C781D91CF3177DF624EA3599EE430DAB4790F325FAD9378FEAE7731C4497
  Session-ID-ctx: 
  Master-Key: 
D149008E43E29D658D29418C9F770B3D6018B1D7CA2F493027B0AC7C3BA8E53B572B68C371153568B8988A1E5F351839
  Key-Arg   : None
  PSK identity: None
  PSK identity hint: None
  SRP username: None
  Start Time: 1465239425
  Timeout   : 300 (sec)
  Verify return code: 0 (ok)
   ---


Here's the command and output when I run my app that tries to connect to the 
same in-house tool which fails:

> ./client3 192.168.1.99
Enter PEM pass phrase:
connecting to 192.168.1.99:16001
 -Error with certificate at depth: 0
   issuer   = /C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector Ltd/OU=Development  
 /CN=192.168.1.99
   subject  = /C=CA/ST=Ontario/L=Ottawa/O=SIP Inspector 
Ltd/OU=Development/CN=192.168.1.99
   err 18:self signed certificate
 ** client3.c:94 Error connecting SSL object
139788992993088:error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:1180:
> 

Here are the api's I call in the my app that utilize the same credentials used 
by the s_client command:

 SSL_CTX_new(SSLv23_method());
 SSL_CTX_load_verify_locations(ctx, 
"../_security/SipInspector/certificate.pem", NULL)
 SSL_CTX_use_PrivateKey_file(ctx, "../_security/client.pem", SSL_FILETYPE_PEM)
 SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback);
 SSL_CTX_set_verify_depth(ctx, 4);
 SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2);

And also I used the openssl verify command to double check the certificate 
against itself (not sure if this really does anything).

Any help would be appreciated.



Carl Heyendal | Software Developer 
1826 Robertson Road | Ottawa, ON K2H 5Z6 | CANADA
Office: +1 613-725-2980 x149





***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are 
hereby notified that any review, use, disclosure, dissemination, distribution 
or copying of this message and any attachments is strictly prohibited. If you 
have received this email in error, please immediately notify the sender and 
destroy this e-mail and any attachments and all copies, whether electronic or 
printed. Please also note that any views, opinions, conclusions or commitments 
expressed in this message are those of the individual sender and do not 
necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are 
not binding on Fortinet and only a writing manually signed by Fortinet's 
General Counsel can be a binding commitment of Fortinet to Fortinet's customers 
or partners. Thank you. *** 


-- 
openssl-users maili

Re: [openssl-users] Creating an X25519-based Certificate

2016-06-30 Thread Erwann Abalea

Maybe we just didn’t. At least not with the command line tools.
The CHANGES file lists a merge between « dh », « gendh », and « dhparam » in 
2000, but no evolution since then.
The oldest version I could find is 0.9.6, and there’s no command-line DH key 
generation.

Cordialement,
Erwann Abalea

Le 30 juin 2016 à 16:58, Jakob Bohm 
mailto:jb-open...@wisemo.com>> a écrit :

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>
 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 
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>
 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

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] OpenSSL s_time output meaning

2016-06-30 Thread Michael Wojcik

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of danigrosu
> Sent: Tuesday, June 28, 2016 22:57
> To: openssl-users@openssl.org
> Subject: [openssl-users] OpenSSL s_time output meaning
> 
> Using the `$ openssl s_time -connect localhost:443 -new -time 30` command
> gives this output:
> 
> No CIPHER specified
> Collecting connection statistics for 30 seconds
> ** etc.
> 8102 connections in 12.65s; 640.47 connections/user sec, bytes read 0
> 8102 connections in 31 real seconds, 0 bytes read per connection
> 
> What is the difference between 8102 connections in 12.65s and 8102
> connections in 31 real seconds ?

Use the source, Luke.

Yes, the output is confusing; "real seconds" is not a particularly meaningful 
term. (What, the imaginary part is zero?) The value that's displayed there is 
the "wall-clock time" elapsed between the start of the test and when the report 
is produced. It's the sum of the time specified by -time (or the 30s default) 
plus the overhead that's not counted while timing actual OpenSSL operations, 
rounded to 1-second granularity.

The 12.65s in the first line is the value of "totalTime", which is the 
accumulator for the timer the openssl command uses for timing the test. The 
s_time command starts this timer before the connection loop and stops it after 
the loop. The timer (in this case) counts only "user" time, that is time the 
process spends in user mode; that's why that line says "user sec".

So this is telling you that your system uses about 1.5ms of user-mode CPU time 
per connection, and that it was able to make about 270 connections per second.

I'm not sure what use that information might be to you, since you haven't told 
us why you're running s_time in the first place.

-- 
Michael Wojcik
Technology Specialist, Micro Focus
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Creating an X25519-based Certificate

2016-06-30 Thread Michael Scott

On Thu, Jun 30, 2016 at 5:11 PM, Matt Caswell  wrote:

>
>
> On 30/06/16 16:54, Salz, Rich wrote:
> >> Since X25519 is not the first "encrypt-only" algorithm in the
> >> OpenSSL universe, how was requesting certificates handled for
> >> such algorithms in the past?
> >
> > It wasn't.
> >
> >> For example how would one request a DH certificate?
> >
> > You couldn't.
> >
> > I don't recall anyone ever asking for such a thing on the public lists.
> >
>
> There is no standardised way of requesting a DH certificate that I know of.
>
> Nonetheless OpenSSL does support the generation of DH certificates, but
> it's a bit nasty:
>
>
> https://security.stackexchange.com/questions/44251/openssl-generate-different-types-of-self-signed-certificate/82868#82868
>
>

That seems to be exactly what I was looking for! So create a bogus RSA cert
and create its self-signed certificate request. But then use the
-force_pubkey flag to substitute my own X25519 public key for the RSA
public key, just prior to getting it signed by the CA.

Reminds me of the cuckoo..

I would worry about the damage that could be done if -force_pubkey fell
into the wrong hands :)

Thanks!


Mike


> Matt
> --
> 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

Re: [openssl-users] Creating an X25519-based Certificate

2016-06-30 Thread Matt Caswell



On 30/06/16 16:54, Salz, Rich wrote:
>> Since X25519 is not the first "encrypt-only" algorithm in the 
>> OpenSSL universe, how was requesting certificates handled for 
>> such algorithms in the past?
> 
> It wasn't.
> 
>> For example how would one request a DH certificate?
> 
> You couldn't.
> 
> I don't recall anyone ever asking for such a thing on the public lists.
> 

There is no standardised way of requesting a DH certificate that I know of.

Nonetheless OpenSSL does support the generation of DH certificates, but
it's a bit nasty:

https://security.stackexchange.com/questions/44251/openssl-generate-different-types-of-self-signed-certificate/82868#82868

Matt
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Creating an X25519-based Certificate

2016-06-30 Thread Salz, Rich

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

It wasn't.

> For example how would one request a DH certificate?

You couldn't.

I don't recall anyone ever asking for such a thing on the public lists.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Creating an X25519-based Certificate

2016-06-30 Thread 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 > 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 
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 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

Re: [openssl-users] Creating an X25519-based Certificate

2016-06-30 Thread Michael Scott

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 
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  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  > 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  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
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Creating an X25519-based Certificate

2016-06-30 Thread Erwann Abalea

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 
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.


Mike



On Wed, Jun 29, 2016 at 4:27 PM, Erwann Abalea 
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.

Cordialement,
Erwann Abalea

Le 29 juin 2016 à 16:46, Michael Scott 
mailto:mike.sc...@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

Re: [openssl-users] self-signed certificate won't work in my app but works with s_client

[openssl-users] self-signed certificate won't work in my app but works with s_client

Re: [openssl-users] Creating an X25519-based Certificate

Re: [openssl-users] OpenSSL s_time output meaning

Re: [openssl-users] Creating an X25519-based Certificate

Re: [openssl-users] Creating an X25519-based Certificate

Re: [openssl-users] Creating an X25519-based Certificate

Re: [openssl-users] Creating an X25519-based Certificate

Re: [openssl-users] Creating an X25519-based Certificate

Re: [openssl-users] Creating an X25519-based Certificate

10 matches

Site Navigation

Mail list logo

Footer information