From matthew.b.donald at gmail.com  Fri Jul  1 04:09:29 2016
From: matthew.b.donald at gmail.com (Matthew Donald)
Date: Fri, 1 Jul 2016 14:09:29 +1000
Subject: [openssl-users] self-signed certificate won't work in my app
 but works with s_client
In-Reply-To: <CF8C1824A5EBA84CAB54AD048E722F50482CE1E3@FGT-EXCH-MBX231.fortinet-us.com>
References: <CF8C1824A5EBA84CAB54AD048E722F50482CE1E3@FGT-EXCH-MBX231.fortinet-us.com>
Message-ID: <CAAopbanx8o6MKKPSQCW4+5t7bciwEwAYQi2pKcnOubjaAu2Abw@mail.gmail.com>

"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 <cheyendal at fortinet.com> 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(00000003)
>       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 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/20160701/f24f405f/attachment.html>

From pepone.onrez at gmail.com  Fri Jul  1 10:24:28 2016
From: pepone.onrez at gmail.com (pepone.onrez)
Date: Fri, 1 Jul 2016 12:24:28 +0200
Subject: [openssl-users] OpenSSL-1.1-pre5 SSL_CTX_set_tmp_dh_callback
Message-ID: <CAPwwpXHZGzv==1TxM22ZNAGVFh27iaoUEB5cqRDvPqnONa-CYg@mail.gmail.com>

Hi,

I trying to update my software to use OpenSSL-1.1 and I having problems
with DH callbacks

When build with 1.1.0-pre5 the callback set with SSL_CTX_set_tmp_dh_callback
is not being called, when using 1.0.x it is called as expected.

I have build 1.1.0-pre5 from sources with default configuration, do I
need any special build option for this to work?

In my test the server and client enables only ADH ciphers, I see the
following ciphers are enabled:

   ADH-AES256-GCM-SHA384
   ADH-AES128-GCM-SHA256
   ADH-AES256-SHA256
   ADH-CAMELLIA256-SHA256
   ADH-AES128-SHA256
   ADH-CAMELLIA128-SHA256
   ADH-AES256-SHA
   ADH-CAMELLIA256-SHA
   ADH-AES128-SHA
   ADH-SEED-SHA
   ADH-CAMELLIA128-SHA
   ADH-DES-CBC3-SHA


The connection fails with

error # = 337002677
message = error:141640B5:SSL routines:tls_construct_client_hello:no
ciphers available

I assume this is related to the DH callback not being called, and so
ADH ciphers cannot be used?

Any ideas why the DH callback is not being called, as I say the code
works fine with all previous OpenSSL versions.

Regards,
Jos?

From matt at openssl.org  Fri Jul  1 10:31:31 2016
From: matt at openssl.org (Matt Caswell)
Date: Fri, 1 Jul 2016 11:31:31 +0100
Subject: [openssl-users] OpenSSL-1.1-pre5 SSL_CTX_set_tmp_dh_callback
In-Reply-To: <CAPwwpXHZGzv==1TxM22ZNAGVFh27iaoUEB5cqRDvPqnONa-CYg@mail.gmail.com>
References: <CAPwwpXHZGzv==1TxM22ZNAGVFh27iaoUEB5cqRDvPqnONa-CYg@mail.gmail.com>
Message-ID: <57764683.9060104@openssl.org>



On 01/07/16 11:24, pepone.onrez wrote:
> Hi,
> 
> I trying to update my software to use OpenSSL-1.1 and I having problems
> with DH callbacks
> 
> When build with 1.1.0-pre5 the callback set with SSL_CTX_set_tmp_dh_callback
> is not being called, when using 1.0.x it is called as expected.
> 
> I have build 1.1.0-pre5 from sources with default configuration, do I
> need any special build option for this to work?
> 
> In my test the server and client enables only ADH ciphers, I see the
> following ciphers are enabled:

1.1.0 has the concept of security levels to stop you from accidentally
configuring bad things. The default security level is 1. ADH ciphers are
in security level 0 (because they are considered insecure) and are
therefore disabled by default, i.e. even if you configure them, if the
security level isn't right then they won't get used.

To set the security level differently you can either append
"@SECLEVEL=0" to the end of the cipher string, or call
SSL_set_security_level()/SSL_CTX_set_security_level().

See:
https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_security_level.html

and

https://www.openssl.org/docs/manmaster/apps/ciphers.html

Matt


> 
>    ADH-AES256-GCM-SHA384
>    ADH-AES128-GCM-SHA256
>    ADH-AES256-SHA256
>    ADH-CAMELLIA256-SHA256
>    ADH-AES128-SHA256
>    ADH-CAMELLIA128-SHA256
>    ADH-AES256-SHA
>    ADH-CAMELLIA256-SHA
>    ADH-AES128-SHA
>    ADH-SEED-SHA
>    ADH-CAMELLIA128-SHA
>    ADH-DES-CBC3-SHA
> 
> 
> The connection fails with
> 
> error # = 337002677
> message = error:141640B5:SSL routines:tls_construct_client_hello:no
> ciphers available
> 
> I assume this is related to the DH callback not being called, and so
> ADH ciphers cannot be used?
> 
> Any ideas why the DH callback is not being called, as I say the code
> works fine with all previous OpenSSL versions.
> 
> Regards,
> Jos?
> 

From dni.grosu at gmail.com  Fri Jul  1 10:54:27 2016
From: dni.grosu at gmail.com (Daniel Grosu)
Date: Fri, 1 Jul 2016 13:54:27 +0300
Subject: [openssl-users] OpenSSL s_time output meaning
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C18088015E667B03@prvxmb03.microfocus.com>
References: <1467176234459-67092.post@n7.nabble.com>
 <B550B44BF8AF314BB00C4E2AC1C18088015E667B03@prvxmb03.microfocus.com>
Message-ID: <CAGYz=CzBjPjEEZsb2VnyWEzszqqTJ2SUwp2f2iEwVCUrZ3ZKUA@mail.gmail.com>

I've created an OpenSSL engine in order to use the GPU for RSA operations
(modular exponentiation) and I have integrated this engine with mod_ssl in
the Apache web server.
So, knowing about s_time command, I wanted to obtain the number of secured
connections per sec that Apache can handle using my engine.

Thank you for the support.

Best wishes,
Dani Grosu
On 30 Jun 2016 22:00, "Michael Wojcik" <Michael.Wojcik at microfocus.com>
wrote:

> > From: openssl-users [mailto:[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=67153&i=0>] On Behalf
> > Of danigrosu
> > Sent: Tuesday, June 28, 2016 22:57
> > To: [hidden email] <http:///user/SendEmail.jtp?type=node&node=67153&i=1>
> > 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
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://openssl.6102.n7.nabble.com/OpenSSL-s-time-output-meaning-tp67092p67153.html
> To unsubscribe from OpenSSL s_time output meaning, click here
> <http://openssl.6102.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=67092&code=ZG5pLmdyb3N1QGdtYWlsLmNvbXw2NzA5MnwtMTk3MTUwMDcxNg==>
> .
> NAML
> <http://openssl.6102.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160701/8e257bd8/attachment-0001.html>

From sahilgandhi87 at gmail.com  Fri Jul  1 11:40:26 2016
From: sahilgandhi87 at gmail.com (Sahil Gandhi)
Date: Fri, 1 Jul 2016 17:10:26 +0530
Subject: [openssl-users] Regarding FIPS capable openssl (I want to
 combine libcrypto.a and libssl.a)
In-Reply-To: <CAFtxU9kNgKrEVW3_pckby4CErALNj0ukJ+SDfs7xfCtte0dGPA@mail.gmail.com>
References: <CAFtxU9nmvTXyk43r2My_8mH8MSJweH1oSMeTxVQvZYNkTW_7=A@mail.gmail.com>
 <4a324a98-f1c1-286b-747b-d5dd2724d034@wisemo.com>
 <CAFtxU9==jE8QR2wpGWdHiPTpUseTogAnSJKzGvEhVYGQzxzxWQ@mail.gmail.com>
 <576D0F29.5050701@openssl.com>
 <CAFtxU9njiCFCf9o3bfEaeMoX10O=oxQzvAmXOTxRTf2=KF+Tug@mail.gmail.com>
 <df8cac3a-bf9e-96bd-3653-f90b82e225f6@wisemo.com>
 <CAFtxU9k+A8_seXDEBErCXabamqvwrSCoCa0P15erLS+PKePdfQ@mail.gmail.com>
 <CAFtxU9kOUJ4mTEZC1NmKQ1f9WvuneGzAf4A5N-5YL0B=RG2uKA@mail.gmail.com>
 <CAAQPBEbnM-D6UeWvdke_qkONpmXnGvnG8uVqaZyA8RXiwwOxKg@mail.gmail.com>
 <CAFtxU9nj6RCD9HMZRheCak0iDXSJh_jvky+7BDW3kbguD9K5bA@mail.gmail.com>
 <5773C541.60704@openssl.com>
 <CAFtxU9kNgKrEVW3_pckby4CErALNj0ukJ+SDfs7xfCtte0dGPA@mail.gmail.com>
Message-ID: <CAFtxU9m0y920j0i89myCbw1T4v5Pif=Sjw4+dJK9TCWJ4wukig@mail.gmail.com>

Hi All,

I am now able to solve this problem, myself.
We need to do changes in fipsld script.
Change 'crypto' or 'libcrypto' to whatever name (u want to specify for the
lib) in fipsld utility script and that's it.

Thanks,
-Sahil Gandhi

On Thu, Jun 30, 2016 at 9:28 AM, Sahil Gandhi <sahilgandhi87 at gmail.com>
wrote:

> Hi Steve,
>
> Thanks for the reply.
>
> Regards,
> Sahil
>
> On Wed, Jun 29, 2016 at 6:25 PM, Steve Marquess <marquess at openssl.com>
> wrote:
>
>> On 06/29/2016 07:09 AM, Sahil Gandhi wrote:
>> > Hi Ken,
>> >
>> > Sorry for the late reply. I really appreciate your suggestion but I some
>> > how need to have static library not the dynamic one.
>>
>> You can statically link an application with the FIPS module, using the
>> special "fipsld" link process, but you cannot put the FIPS module in a
>> conventional static library (as managed with "ar").
>>
>> Unfortunately the requirements of FIPS 140-2 conflict in several ways
>> with standard software engineering practice; it is the tail that wags
>> the dog.
>>
>> -Steve M.
>>
>> --
>> Steve Marquess
>> OpenSSL Validation Services, Inc.
>> 1829 Mount Ephraim Road
>> Adamstown, MD  21710
>> USA
>> +1 877 673 6775 s/b
>> +1 301 874 2571 direct
>> marquess at openssl.com
>> gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
>
> --
> Sahil Gandhi
> Project Engineer
> R&D CDAC, Pune
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160701/6a3f7312/attachment.html>

From pepone.onrez at gmail.com  Fri Jul  1 13:19:34 2016
From: pepone.onrez at gmail.com (pepone.onrez)
Date: Fri, 1 Jul 2016 15:19:34 +0200
Subject: [openssl-users] OpenSSL-1.1-pre5 SSL_CTX_set_tmp_dh_callback
In-Reply-To: <57764683.9060104@openssl.org>
References: <CAPwwpXHZGzv==1TxM22ZNAGVFh27iaoUEB5cqRDvPqnONa-CYg@mail.gmail.com>
 <57764683.9060104@openssl.org>
Message-ID: <CAPwwpXG6o6YPWMZGJd0b5G9Zc+=rVJk=Lum05Fsf538f5XeAqA@mail.gmail.com>

On 1 July 2016 at 12:31, Matt Caswell <matt at openssl.org> wrote:
>
>
> On 01/07/16 11:24, pepone.onrez wrote:
>> Hi,
>>
>> I trying to update my software to use OpenSSL-1.1 and I having problems
>> with DH callbacks
>>
>> When build with 1.1.0-pre5 the callback set with SSL_CTX_set_tmp_dh_callback
>> is not being called, when using 1.0.x it is called as expected.
>>
>> I have build 1.1.0-pre5 from sources with default configuration, do I
>> need any special build option for this to work?
>>
>> In my test the server and client enables only ADH ciphers, I see the
>> following ciphers are enabled:
>
> 1.1.0 has the concept of security levels to stop you from accidentally
> configuring bad things. The default security level is 1. ADH ciphers are
> in security level 0 (because they are considered insecure) and are
> therefore disabled by default, i.e. even if you configure them, if the
> security level isn't right then they won't get used.
>
> To set the security level differently you can either append
> "@SECLEVEL=0" to the end of the cipher string, or call
> SSL_set_security_level()/SSL_CTX_set_security_level().
>
> See:
> https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_security_level.html
>
> and
>
> https://www.openssl.org/docs/manmaster/apps/ciphers.html
>
> Matt

Thanks Matt that was it, setting SECLEVEL=0" make the test work
>
>
>>
>>    ADH-AES256-GCM-SHA384
>>    ADH-AES128-GCM-SHA256
>>    ADH-AES256-SHA256
>>    ADH-CAMELLIA256-SHA256
>>    ADH-AES128-SHA256
>>    ADH-CAMELLIA128-SHA256
>>    ADH-AES256-SHA
>>    ADH-CAMELLIA256-SHA
>>    ADH-AES128-SHA
>>    ADH-SEED-SHA
>>    ADH-CAMELLIA128-SHA
>>    ADH-DES-CBC3-SHA
>>
>>
>> The connection fails with
>>
>> error # = 337002677
>> message = error:141640B5:SSL routines:tls_construct_client_hello:no
>> ciphers available
>>
>> I assume this is related to the DH callback not being called, and so
>> ADH ciphers cannot be used?
>>
>> Any ideas why the DH callback is not being called, as I say the code
>> works fine with all previous OpenSSL versions.
>>
>> Regards,
>> Jos?
>>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From pepone.onrez at gmail.com  Fri Jul  1 13:29:53 2016
From: pepone.onrez at gmail.com (pepone.onrez)
Date: Fri, 1 Jul 2016 15:29:53 +0200
Subject: [openssl-users] DSA with OpenSSL-1.1
Message-ID: <CAPwwpXHjDaCevZCOsrBQrV=ZHgpzKhzs7jDeGqQ2jzUSWJi4Hw@mail.gmail.com>

Hi,

After upgrade my software to use OpenSSL-1.1 one of the test is
failing, the test in question client and server are configured to use
DSA certificates. The server is configured to request a client
certificate.

   SSL error occurred for new outgoing connection:
   remote address = 127.0.0.1:47812
   error # = 336151568
   message = error:14094410:SSL routines:ssl3_read_bytes:reason(1040)
   location = ssl/record/rec_layer_s3.c, 1467
   data = SSL alert number 40

When using OpenSSL 1.0.1 the connection success

   cipher = DHE-DSS-AES256-GCM-SHA384
   bits = 256
   remote address = 127.0.0.1:43629
   protocol = TLSv1.2


I try to set security level to 0 for 1.1 but that doesn't make any
difference here, any ideas what could be the issue?

From matt at openssl.org  Fri Jul  1 13:39:02 2016
From: matt at openssl.org (Matt Caswell)
Date: Fri, 1 Jul 2016 14:39:02 +0100
Subject: [openssl-users] DSA with OpenSSL-1.1
In-Reply-To: <CAPwwpXHjDaCevZCOsrBQrV=ZHgpzKhzs7jDeGqQ2jzUSWJi4Hw@mail.gmail.com>
References: <CAPwwpXHjDaCevZCOsrBQrV=ZHgpzKhzs7jDeGqQ2jzUSWJi4Hw@mail.gmail.com>
Message-ID: <57767276.6070802@openssl.org>



On 01/07/16 14:29, pepone.onrez wrote:
> Hi,
> 
> After upgrade my software to use OpenSSL-1.1 one of the test is
> failing, the test in question client and server are configured to use
> DSA certificates. The server is configured to request a client
> certificate.
> 
>    SSL error occurred for new outgoing connection:
>    remote address = 127.0.0.1:47812
>    error # = 336151568
>    message = error:14094410:SSL routines:ssl3_read_bytes:reason(1040)
>    location = ssl/record/rec_layer_s3.c, 1467
>    data = SSL alert number 40

Is this the error you get on the server or the client? The above
indicates the connection was aborted because a HandshakeFailure alert
was received from the peer. Therefore you need to look at the other end
of the communication and see if there is some error message that
indicates why the alert was sent.

Matt




> 
> When using OpenSSL 1.0.1 the connection success
> 
>    cipher = DHE-DSS-AES256-GCM-SHA384
>    bits = 256
>    remote address = 127.0.0.1:43629
>    protocol = TLSv1.2
> 
> 
> I try to set security level to 0 for 1.1 but that doesn't make any
> difference here, any ideas what could be the issue?
> 

From rsalz at akamai.com  Fri Jul  1 14:22:14 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 1 Jul 2016 14:22:14 +0000
Subject: [openssl-users] OpenSSL s_time output meaning
In-Reply-To: <CAGYz=CzBjPjEEZsb2VnyWEzszqqTJ2SUwp2f2iEwVCUrZ3ZKUA@mail.gmail.com>
References: <1467176234459-67092.post@n7.nabble.com>
 <B550B44BF8AF314BB00C4E2AC1C18088015E667B03@prvxmb03.microfocus.com>
 <CAGYz=CzBjPjEEZsb2VnyWEzszqqTJ2SUwp2f2iEwVCUrZ3ZKUA@mail.gmail.com>
Message-ID: <a390ef696d5749fba82a4128552cb8aa@usma1ex-dag1mb1.msg.corp.akamai.com>

Not answering the question, but that is a pretty cool thing you built!

From pepone.onrez at gmail.com  Fri Jul  1 14:22:33 2016
From: pepone.onrez at gmail.com (pepone.onrez)
Date: Fri, 1 Jul 2016 16:22:33 +0200
Subject: [openssl-users] DSA with OpenSSL-1.1
In-Reply-To: <57767276.6070802@openssl.org>
References: <CAPwwpXHjDaCevZCOsrBQrV=ZHgpzKhzs7jDeGqQ2jzUSWJi4Hw@mail.gmail.com>
 <57767276.6070802@openssl.org>
Message-ID: <CAPwwpXGMcZzFGbJgyksHk7nV79ttxpOP-1Bfid=qUYKNSzKAnA@mail.gmail.com>

On 1 July 2016 at 15:39, Matt Caswell <matt at openssl.org> wrote:
>
>
> On 01/07/16 14:29, pepone.onrez wrote:
>> Hi,
>>
>> After upgrade my software to use OpenSSL-1.1 one of the test is
>> failing, the test in question client and server are configured to use
>> DSA certificates. The server is configured to request a client
>> certificate.
>>
>>    SSL error occurred for new outgoing connection:
>>    remote address = 127.0.0.1:47812
>>    error # = 336151568
>>    message = error:14094410:SSL routines:ssl3_read_bytes:reason(1040)
>>    location = ssl/record/rec_layer_s3.c, 1467
>>    data = SSL alert number 40
>
> Is this the error you get on the server or the client? The above
> indicates the connection was aborted because a HandshakeFailure alert
> was received from the peer. Therefore you need to look at the other end
> of the communication and see if there is some error message that
> indicates why the alert was sent.
>
> Matt
That was on the client, looking at the server I see it reports there
is no shared
cipher

   SSL error occurred for new incoming connection:
   remote address = 127.0.0.1:36951
   error # = 337092801
   message = error:1417A0C1:SSL
routines:tls_post_process_client_hello:no shared cipher

I have try to enable all ciphers with ALL:@SECLEVEL=0, but still get
the same error,
it is not clear why server client don't find a common cipher here.

Regards,
Jos?
>
>
>
>
>>
>> When using OpenSSL 1.0.1 the connection success
>>
>>    cipher = DHE-DSS-AES256-GCM-SHA384
>>    bits = 256
>>    remote address = 127.0.0.1:43629
>>    protocol = TLSv1.2
>>
>>
>> I try to set security level to 0 for 1.1 but that doesn't make any
>> difference here, any ideas what could be the issue?
>>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From dni.grosu at gmail.com  Fri Jul  1 13:21:14 2016
From: dni.grosu at gmail.com (danigrosu)
Date: Fri, 1 Jul 2016 06:21:14 -0700 (MST)
Subject: [openssl-users] OpenSSL s_time output meaning
In-Reply-To: <a390ef696d5749fba82a4128552cb8aa@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <1467176234459-67092.post@n7.nabble.com>
 <B550B44BF8AF314BB00C4E2AC1C18088015E667B03@prvxmb03.microfocus.com>
 <CAGYz=CzBjPjEEZsb2VnyWEzszqqTJ2SUwp2f2iEwVCUrZ3ZKUA@mail.gmail.com>
 <a390ef696d5749fba82a4128552cb8aa@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CAGYz=CyoS=KtGbdCqbzWGkKMHsihW+uAPo=z+beiqFaBsvYeuw@mail.gmail.com>

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

So that is why I am running s_time, to benchmark my customised Apache
server.
I had a little difficulty with its output. :D

Best wishes,
Dani Grosu

On 1 July 2016 at 16:12, Salz, Rich [via OpenSSL] <
ml-node+s6102n67168h47 at n7.nabble.com> wrote:

> Not answering the question, but that is a pretty cool thing you built!
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://openssl.6102.n7.nabble.com/OpenSSL-s-time-output-meaning-tp67092p67168.html
> To unsubscribe from OpenSSL s_time output meaning, click here
> <http://openssl.6102.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=67092&code=ZG5pLmdyb3N1QGdtYWlsLmNvbXw2NzA5MnwtMTk3MTUwMDcxNg==>
> .
> NAML
> <http://openssl.6102.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-s-time-output-meaning-tp67092p67170.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160701/01fe8695/attachment.html>

From matt at openssl.org  Fri Jul  1 14:40:17 2016
From: matt at openssl.org (Matt Caswell)
Date: Fri, 1 Jul 2016 15:40:17 +0100
Subject: [openssl-users] DSA with OpenSSL-1.1
In-Reply-To: <CAPwwpXGMcZzFGbJgyksHk7nV79ttxpOP-1Bfid=qUYKNSzKAnA@mail.gmail.com>
References: <CAPwwpXHjDaCevZCOsrBQrV=ZHgpzKhzs7jDeGqQ2jzUSWJi4Hw@mail.gmail.com>
 <57767276.6070802@openssl.org>
 <CAPwwpXGMcZzFGbJgyksHk7nV79ttxpOP-1Bfid=qUYKNSzKAnA@mail.gmail.com>
Message-ID: <577680D1.6040900@openssl.org>



On 01/07/16 15:22, pepone.onrez wrote:
> On 1 July 2016 at 15:39, Matt Caswell <matt at openssl.org> wrote:
>>
>>
>> On 01/07/16 14:29, pepone.onrez wrote:
>>> Hi,
>>>
>>> After upgrade my software to use OpenSSL-1.1 one of the test is
>>> failing, the test in question client and server are configured to use
>>> DSA certificates. The server is configured to request a client
>>> certificate.
>>>
>>>    SSL error occurred for new outgoing connection:
>>>    remote address = 127.0.0.1:47812
>>>    error # = 336151568
>>>    message = error:14094410:SSL routines:ssl3_read_bytes:reason(1040)
>>>    location = ssl/record/rec_layer_s3.c, 1467
>>>    data = SSL alert number 40
>>
>> Is this the error you get on the server or the client? The above
>> indicates the connection was aborted because a HandshakeFailure alert
>> was received from the peer. Therefore you need to look at the other end
>> of the communication and see if there is some error message that
>> indicates why the alert was sent.
>>
>> Matt
> That was on the client, looking at the server I see it reports there
> is no shared
> cipher
> 
>    SSL error occurred for new incoming connection:
>    remote address = 127.0.0.1:36951
>    error # = 337092801
>    message = error:1417A0C1:SSL
> routines:tls_post_process_client_hello:no shared cipher
> 
> I have try to enable all ciphers with ALL:@SECLEVEL=0, but still get
> the same error,
> it is not clear why server client don't find a common cipher here.

Did you successfully load a DSA certificate and key into the server? If
the server doesn't like the cert/key for some reason then it won't make
any DSS ciphersuites available.

Also, I see you are trying to use a DHE based ciphersuite. Did you set
DH parameters to be used? If so how did you do it?

Matt


> 
> Regards,
> Jos?
>>
>>
>>
>>
>>>
>>> When using OpenSSL 1.0.1 the connection success
>>>
>>>    cipher = DHE-DSS-AES256-GCM-SHA384
>>>    bits = 256
>>>    remote address = 127.0.0.1:43629
>>>    protocol = TLSv1.2
>>>
>>>
>>> I try to set security level to 0 for 1.1 but that doesn't make any
>>> difference here, any ideas what could be the issue?
>>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From hanno at hboeck.de  Fri Jul  1 14:40:19 2016
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Fri, 1 Jul 2016 16:40:19 +0200
Subject: [openssl-users] DSA with OpenSSL-1.1
In-Reply-To: <CAPwwpXHjDaCevZCOsrBQrV=ZHgpzKhzs7jDeGqQ2jzUSWJi4Hw@mail.gmail.com>
References: <CAPwwpXHjDaCevZCOsrBQrV=ZHgpzKhzs7jDeGqQ2jzUSWJi4Hw@mail.gmail.com>
Message-ID: <20160701164019.7a2b3b16@pc1>

Hi,

On Fri, 1 Jul 2016 15:29:53 +0200
"pepone.onrez" <pepone.onrez at gmail.com> wrote:

> After upgrade my software to use OpenSSL-1.1 one of the test is
> failing, the test in question client and server are configured to use
> DSA certificates. The server is configured to request a client
> certificate.

I can't answer your question, but I have one to you: Why do you use DSA?

There was a discussion in the TLS working group a while ago about DSA
support and there was overwhelming support to remove it in TLS 1.3.
The rationale was basically that DSA in TLS is rarely used at all, is
often used with insecure key sizes (1024 bit) and has a severe weakness
when it comes to bad random numbers. On top of that it has basically no
advantage over the much more widely used RSA. The original reason
(in the early 90s) to use DSA over RSA were patent issues, but those are
long expired.

So my (and I think most others) impression is that DSA in TLS is as
dead as it can be and probably the most sane move for OpenSSL would be
to just remove it. Given that I'd like to know why you seem to have
chosen to still use DSA.

-- 
Hanno B?ck
https://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: BBB51E42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160701/5c5a425c/attachment.sig>

From stm at pdflib.com  Fri Jul  1 14:40:34 2016
From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=)
Date: Fri, 1 Jul 2016 16:40:34 +0200
Subject: [openssl-users] Unable to decrypt CMS object encrypted with EC
	prime256v1 certificate
Message-ID: <cdc66922-e976-7023-164c-3872418ff54d@pdflib.com>

Hi,

we are testing OpenSSL interoperability with a third-party application, 
and we cannot decrypt a CMS object that is encrypted by the third-party 
application with a prime256v1 elliptic-curve certificate.

I have attached the following files:

demo_signer_ec_secp256r1.cms.der: DER-encoded CMS object
demo_signer_ec_secp256r1.cert.pem: recipient certificate
demo_signer_ec_secp256r1.pkey.pem. recipient private key (no password)

I try to decrypt the CMS object with the following command using OpenSSL 
1.0.2:

$ openssl version
OpenSSL 1.0.2h  3 May 2016
$ openssl cms -decrypt -in demo_signer_ec_secp256r1.cms.der  -inform DER 
-recip  demo_signer_ec_secp256r1.cert.pem  -inkey 
demo_signer_ec_secp256r1.pkey.pem
Error decrypting CMS using private key

When I use OpenSSL 1.1.0 beta from today's HEAD of the master branch, I 
see an additional error message:

$ openssl version
OpenSSL 1.1.0-pre6-dev  xx XXX xxxx
$ openssl cms -decrypt -in demo_signer_ec_secp256r1.cms.der  -inform DER 
-recip  demo_signer_ec_secp256r1.cert.pem  -inkey 
demo_signer_ec_secp256r1.pkey.pem
Error decrypting CMS using private key
140735294530304:error:0D06E0A4:asn1 encoding 
routines:asn1_do_adb:unsupported any defined by 
type:crypto/asn1/tasn_utl.c:238:

Is the CMS object broken, or is this a problem in OpenSSL?

Thanks

--
Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: demo_signer_ec_secp256r1.cert.pem
Type: application/x-x509-ca-cert
Size: 1301 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160701/d50781fb/attachment.crt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: demo_signer_ec_secp256r1.cms.der
Type: application/x-x509-ca-cert
Size: 364 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160701/d50781fb/attachment-0001.crt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: demo_signer_ec_secp256r1.pkey.pem
Type: application/x-x509-ca-cert
Size: 365 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160701/d50781fb/attachment-0002.crt>

From pepone.onrez at gmail.com  Fri Jul  1 14:51:40 2016
From: pepone.onrez at gmail.com (pepone.onrez)
Date: Fri, 1 Jul 2016 16:51:40 +0200
Subject: [openssl-users] DSA with OpenSSL-1.1
In-Reply-To: <577680D1.6040900@openssl.org>
References: <CAPwwpXHjDaCevZCOsrBQrV=ZHgpzKhzs7jDeGqQ2jzUSWJi4Hw@mail.gmail.com>
 <57767276.6070802@openssl.org>
 <CAPwwpXGMcZzFGbJgyksHk7nV79ttxpOP-1Bfid=qUYKNSzKAnA@mail.gmail.com>
 <577680D1.6040900@openssl.org>
Message-ID: <CAPwwpXGJgL=aoUwUVvaDTWcF6VBgSUGHvHXwngbH-nRzaVDBxA@mail.gmail.com>

On 1 July 2016 at 16:40, Matt Caswell <matt at openssl.org> wrote:
>
>
> On 01/07/16 15:22, pepone.onrez wrote:
>> On 1 July 2016 at 15:39, Matt Caswell <matt at openssl.org> wrote:
>>>
>>>
>>> On 01/07/16 14:29, pepone.onrez wrote:
>>>> Hi,
>>>>
>>>> After upgrade my software to use OpenSSL-1.1 one of the test is
>>>> failing, the test in question client and server are configured to use
>>>> DSA certificates. The server is configured to request a client
>>>> certificate.
>>>>
>>>>    SSL error occurred for new outgoing connection:
>>>>    remote address = 127.0.0.1:47812
>>>>    error # = 336151568
>>>>    message = error:14094410:SSL routines:ssl3_read_bytes:reason(1040)
>>>>    location = ssl/record/rec_layer_s3.c, 1467
>>>>    data = SSL alert number 40
>>>
>>> Is this the error you get on the server or the client? The above
>>> indicates the connection was aborted because a HandshakeFailure alert
>>> was received from the peer. Therefore you need to look at the other end
>>> of the communication and see if there is some error message that
>>> indicates why the alert was sent.
>>>
>>> Matt
>> That was on the client, looking at the server I see it reports there
>> is no shared
>> cipher
>>
>>    SSL error occurred for new incoming connection:
>>    remote address = 127.0.0.1:36951
>>    error # = 337092801
>>    message = error:1417A0C1:SSL
>> routines:tls_post_process_client_hello:no shared cipher
>>
>> I have try to enable all ciphers with ALL:@SECLEVEL=0, but still get
>> the same error,
>> it is not clear why server client don't find a common cipher here.
>
> Did you successfully load a DSA certificate and key into the server? If
> the server doesn't like the cert/key for some reason then it won't make
> any DSS ciphersuites available.
>

Yes I using SSL_CTX_use_certificate and SSL_CTX_use_PrivateKey and
reading the pkcs12 cert with PKCS12_parse, that works fine with the rest
of my test suite.

> Also, I see you are trying to use a DHE based ciphersuite. Did you set
> DH parameters to be used? If so how did you do it?
>

I'm using a DH callback to set the DH parameters

DH*
IceSSL_opensslDHCallback(SSL* ssl, int /*isExport*/, int keyLength)
{
#  if OPENSSL_VERSION_NUMBER >= 0x10100000L
    SSL_CTX* ctx = SSL_get_SSL_CTX(ssl);
#  else
    SSL_CTX* ctx = ssl->ctx;
#  endif
    OpenSSLEngine* p =
reinterpret_cast<OpenSSLEngine*>(SSL_CTX_get_ex_data(ctx, 0));
    return p->dhParams(keyLength);
}
#  endif
}

SSL_CTX_set_options(_ctx, SSL_OP_SINGLE_DH_USE);
SSL_CTX_set_tmp_dh_callback(_ctx, IceSSL_opensslDHCallback);

And for default parameters I'm using d2i_DHparams to restore the DH
parameters I previously
saved with i2d_DHparams


> Matt
>
>
>>
>> Regards,
>> Jos?
>>>
>>>
>>>
>>>
>>>>
>>>> When using OpenSSL 1.0.1 the connection success
>>>>
>>>>    cipher = DHE-DSS-AES256-GCM-SHA384
>>>>    bits = 256
>>>>    remote address = 127.0.0.1:43629
>>>>    protocol = TLSv1.2
>>>>
>>>>
>>>> I try to set security level to 0 for 1.1 but that doesn't make any
>>>> difference here, any ideas what could be the issue?
>>>>
>>> --
>>> 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

From pepone.onrez at gmail.com  Fri Jul  1 14:53:19 2016
From: pepone.onrez at gmail.com (pepone.onrez)
Date: Fri, 1 Jul 2016 16:53:19 +0200
Subject: [openssl-users] DSA with OpenSSL-1.1
In-Reply-To: <20160701164019.7a2b3b16@pc1>
References: <CAPwwpXHjDaCevZCOsrBQrV=ZHgpzKhzs7jDeGqQ2jzUSWJi4Hw@mail.gmail.com>
 <20160701164019.7a2b3b16@pc1>
Message-ID: <CAPwwpXFPgfgTv-JEU9qS53kz8O7+Dt2Qk82F4HLgGM6ZJExusQ@mail.gmail.com>

On 1 July 2016 at 16:40, Hanno B?ck <hanno at hboeck.de> wrote:
> Hi,
>
> On Fri, 1 Jul 2016 15:29:53 +0200
> "pepone.onrez" <pepone.onrez at gmail.com> wrote:
>
>> After upgrade my software to use OpenSSL-1.1 one of the test is
>> failing, the test in question client and server are configured to use
>> DSA certificates. The server is configured to request a client
>> certificate.
>
> I can't answer your question, but I have one to you: Why do you use DSA?
>
> There was a discussion in the TLS working group a while ago about DSA
> support and there was overwhelming support to remove it in TLS 1.3.
> The rationale was basically that DSA in TLS is rarely used at all, is
> often used with insecure key sizes (1024 bit) and has a severe weakness
> when it comes to bad random numbers. On top of that it has basically no
> advantage over the much more widely used RSA. The original reason
> (in the early 90s) to use DSA over RSA were patent issues, but those are
> long expired.
>
> So my (and I think most others) impression is that DSA in TLS is as
> dead as it can be and probably the most sane move for OpenSSL would be
> to just remove it. Given that I'd like to know why you seem to have
> chosen to still use DSA.

That is part of a large test suite for a library, just trying to
ensure that everithg
still works with OpenSSL 1.1.0

>
> --
> Hanno B?ck
> https://hboeck.de/
>
> mail/jabber: hanno at hboeck.de
> GPG: BBB51E42
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>

From stm at pdflib.com  Fri Jul  1 14:55:31 2016
From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=)
Date: Fri, 1 Jul 2016 16:55:31 +0200
Subject: [openssl-users] How to turn on certain elements in CMS objects
Message-ID: <34ef0c81-bc5f-d97d-2a92-3774924763c9@pdflib.com>

Hi,

this message is related to another question that I sent with subject 
"Unable to decrypt CMS object encrypted with EC prime256v1 certificate".

Below I have included the full ASN.1 dump of the CMS object generated by 
a third-party application.

The CMS object has two properties that I so far was not able to 
reproduce when creating CMS objects with OpenSSL:

First the AlgorithmIdentifier includes the EC curve name:

   40   19:               SEQUENCE {
   42    7:                 OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 
2 1)
   51    8:                 OBJECT IDENTIFIER ansiX9p256r1 (1 2 840 
10045 3 1 7)
          :                 }

In CMS objects created with OpenSSL with the same recipient certificate, 
the curve name is always omitted. Is it possible to make OpenSSL emit 
the curve name as well?

Second the following:

  129   10:           [1] {
  131    8:             OCTET STRING B1 04 4A FD FC 8B 70 6D
          :             }

If I match this correctly to RFC 5652, this is

ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL

inside the KeyAgreeRecipientInfo SEQUENCE (see 
https://tools.ietf.org/html/rfc5652#section-6.2.2).

Can OpenSSL emit this optional element? What is the purpose of the "ukm" 
field?

Thank you
Stephan

Full ASN.1 dump follows:

    0  360: SEQUENCE {
    4    9:   OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
   15  345:   [0] {
   19  341:     SEQUENCE {
   23    1:       INTEGER 2
   26  256:       SET {
   30  253:         [1] {
   33    1:           INTEGER 3
   36   91:           [0] {
   38   89:             [1] {
   40   19:               SEQUENCE {
   42    7:                 OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 
2 1)
   51    8:                 OBJECT IDENTIFIER ansiX9p256r1 (1 2 840 
10045 3 1 7)
          :                 }
   61   66:               BIT STRING
          :                 04 0E 81 BC 28 63 C8 5A 1E 09 7D 47 1F D3 24 92
          :                 15 6D 94 8A 8D 88 82 CC 65 1F FD 57 B4 B8 DD 77
          :                 97 AB E7 D0 1D 8E C1 FE F6 CB C4 C5 9D B7 7B DE
          :                 60 0E 84 F2 35 4E 19 42 EB B4 D9 F5 71 58 4F 53
          :                 89
          :               }
          :             }
  129   10:           [1] {
  131    8:             OCTET STRING B1 04 4A FD FC 8B 70 6D
          :             }
  141   21:           SEQUENCE {
  143    6:             OBJECT IDENTIFIER '1 3 132 1 11 1'
  151   11:             SEQUENCE {
  153    9:               OBJECT IDENTIFIER aes128-wrap (2 16 840 1 101 
3 4 1 5)
          :               }
          :             }
  164  120:           SEQUENCE {
  166  118:             SEQUENCE {
  168   90:               SEQUENCE {
  170   85:                 SEQUENCE {
  172   11:                   SET {
  174    9:                     SEQUENCE {
  176    3:                       OBJECT IDENTIFIER countryName (2 5 4 6)
  181    2:                       PrintableString 'DE'
          :                       }
          :                     }
  185   15:                   SET {
  187   13:                     SEQUENCE {
  189    3:                       OBJECT IDENTIFIER localityName (2 5 4 7)
  194    6:                       UTF8String 'Munich'
          :                       }
          :                     }
  202   20:                   SET {
  204   18:                     SEQUENCE {
  206    3:                       OBJECT IDENTIFIER organizationName (2 
5 4 10)
  211   11:                       UTF8String 'PDFlib GmbH'
          :                       }
          :                     }
  224   31:                   SET {
  226   29:                     SEQUENCE {
  228    3:                       OBJECT IDENTIFIER commonName (2 5 4 3)
  233   22:                       UTF8String 'PDFlib GmbH Demo CA G2'
          :                       }
          :                     }
          :                   }
  257    1:                 INTEGER 5
          :                 }
  260   24:               OCTET STRING
          :                 2E 27 CB 94 64 71 E7 05 96 51 08 34 67 92 34 D7
          :                 12 B1 69 8F 20 E9 F1 11
          :               }
          :             }
          :           }
          :         }
  286   76:       SEQUENCE {
  288    9:         OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
  299   29:         SEQUENCE {
  301    9:           OBJECT IDENTIFIER aes128-CBC (2 16 840 1 101 3 4 1 2)
  312   16:           OCTET STRING
          :             88 E4 52 8D 63 2F A9 A5 49 0E 8B FE 7D D0 93 F9
          :           }
  330   32:         [0]
          :           06 E8 97 3B AD 11 F8 49 41 C9 D6 C3 FD B4 22 4A
          :           89 DF AB 86 95 A7 D1 E0 C8 BF E5 8F 4D 79 7D D3
          :         }
          :       }
          :     }
          :   }


From Michael.Wojcik at microfocus.com  Fri Jul  1 15:22:59 2016
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 1 Jul 2016 15:22:59 +0000
Subject: [openssl-users] DSA with OpenSSL-1.1
In-Reply-To: <20160701164019.7a2b3b16@pc1>
References: <CAPwwpXHjDaCevZCOsrBQrV=ZHgpzKhzs7jDeGqQ2jzUSWJi4Hw@mail.gmail.com>
 <20160701164019.7a2b3b16@pc1>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088015E6683D0@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Hanno B?ck
> Sent: Friday, July 01, 2016 08:40
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] DSA with OpenSSL-1.1
> 
> I can't answer your question, but I have one to you: Why do you use DSA?
> 
> There was a discussion in the TLS working group a while ago about DSA
> support and there was overwhelming support to remove it in TLS 1.3.
> The rationale was basically that DSA in TLS is rarely used at all, is
> often used with insecure key sizes (1024 bit) and has a severe weakness
> when it comes to bad random numbers. On top of that it has basically no
> advantage over the much more widely used RSA. The original reason
> (in the early 90s) to use DSA over RSA were patent issues, but those are
> long expired.
> 
> So my (and I think most others) impression is that DSA in TLS is as
> dead as it can be and probably the most sane move for OpenSSL would be
> to just remove it. Given that I'd like to know why you seem to have
> chosen to still use DSA.

We have US Federal customers who require DSA. They have existing DSA certificates, their certificate process generates DSA certificates, and they're not showing any inclination to change, regardless of what crypto experts think.

Of course, this being the US Federal Government, it's entirely possible that tomorrow someone will issue a directive forbidding further use of DSA. But then it's also very likely that any such directive would be delayed for years. The wheels of US government cryptography grind slowly.

In short: Removing support for DSA in OpenSSL would prevent some of our products from updating to 1.1.x for a significant length of time, probably years.

-- 
Michael Wojcik
Technology Specialist, Micro Focus


From rsalz at akamai.com  Fri Jul  1 15:54:45 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 1 Jul 2016 15:54:45 +0000
Subject: [openssl-users] DSA with OpenSSL-1.1
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C18088015E6683D0@prvxmb03.microfocus.com>
References: <CAPwwpXHjDaCevZCOsrBQrV=ZHgpzKhzs7jDeGqQ2jzUSWJi4Hw@mail.gmail.com>
 <20160701164019.7a2b3b16@pc1>
 <B550B44BF8AF314BB00C4E2AC1C18088015E6683D0@prvxmb03.microfocus.com>
Message-ID: <c48116daf4494019b6e57b1dd639b28e@usma1ex-dag1mb1.msg.corp.akamai.com>


> In short: Removing support for DSA in OpenSSL would prevent some of our
> products from updating to 1.1.x for a significant length of time, probably
> years.

We have no plans to do that.

From pepone.onrez at gmail.com  Fri Jul  1 15:57:47 2016
From: pepone.onrez at gmail.com (pepone.onrez)
Date: Fri, 1 Jul 2016 17:57:47 +0200
Subject: [openssl-users] DSA with OpenSSL-1.1
In-Reply-To: <CAPwwpXGJgL=aoUwUVvaDTWcF6VBgSUGHvHXwngbH-nRzaVDBxA@mail.gmail.com>
References: <CAPwwpXHjDaCevZCOsrBQrV=ZHgpzKhzs7jDeGqQ2jzUSWJi4Hw@mail.gmail.com>
 <57767276.6070802@openssl.org>
 <CAPwwpXGMcZzFGbJgyksHk7nV79ttxpOP-1Bfid=qUYKNSzKAnA@mail.gmail.com>
 <577680D1.6040900@openssl.org>
 <CAPwwpXGJgL=aoUwUVvaDTWcF6VBgSUGHvHXwngbH-nRzaVDBxA@mail.gmail.com>
Message-ID: <CAPwwpXHEc6RhYNkx_cQ34iVpoD481L9gc0BMKEuy3XQhKzm+bg@mail.gmail.com>

On 1 July 2016 at 16:51, pepone.onrez <pepone.onrez at gmail.com> wrote:
> On 1 July 2016 at 16:40, Matt Caswell <matt at openssl.org> wrote:
>>
>>
>> On 01/07/16 15:22, pepone.onrez wrote:
>>> On 1 July 2016 at 15:39, Matt Caswell <matt at openssl.org> wrote:
>>>>
>>>>
>>>> On 01/07/16 14:29, pepone.onrez wrote:
>>>>> Hi,
>>>>>
>>>>> After upgrade my software to use OpenSSL-1.1 one of the test is
>>>>> failing, the test in question client and server are configured to use
>>>>> DSA certificates. The server is configured to request a client
>>>>> certificate.
>>>>>
>>>>>    SSL error occurred for new outgoing connection:
>>>>>    remote address = 127.0.0.1:47812
>>>>>    error # = 336151568
>>>>>    message = error:14094410:SSL routines:ssl3_read_bytes:reason(1040)
>>>>>    location = ssl/record/rec_layer_s3.c, 1467
>>>>>    data = SSL alert number 40
>>>>
>>>> Is this the error you get on the server or the client? The above
>>>> indicates the connection was aborted because a HandshakeFailure alert
>>>> was received from the peer. Therefore you need to look at the other end
>>>> of the communication and see if there is some error message that
>>>> indicates why the alert was sent.
>>>>
>>>> Matt
>>> That was on the client, looking at the server I see it reports there
>>> is no shared
>>> cipher
>>>
>>>    SSL error occurred for new incoming connection:
>>>    remote address = 127.0.0.1:36951
>>>    error # = 337092801
>>>    message = error:1417A0C1:SSL
>>> routines:tls_post_process_client_hello:no shared cipher
>>>
>>> I have try to enable all ciphers with ALL:@SECLEVEL=0, but still get
>>> the same error,
>>> it is not clear why server client don't find a common cipher here.

I was not correctly setting the ciphers, Adding DHE to my ciphers and things
work fine.

With 1.0.0 I only have DEFAULT:DSS, I guess DHE is not longer in the DEFAULT
set

>>
>> Did you successfully load a DSA certificate and key into the server? If
>> the server doesn't like the cert/key for some reason then it won't make
>> any DSS ciphersuites available.
>>
>
> Yes I using SSL_CTX_use_certificate and SSL_CTX_use_PrivateKey and
> reading the pkcs12 cert with PKCS12_parse, that works fine with the rest
> of my test suite.
>
>> Also, I see you are trying to use a DHE based ciphersuite. Did you set
>> DH parameters to be used? If so how did you do it?
>>
>
> I'm using a DH callback to set the DH parameters
>
> DH*
> IceSSL_opensslDHCallback(SSL* ssl, int /*isExport*/, int keyLength)
> {
> #  if OPENSSL_VERSION_NUMBER >= 0x10100000L
>     SSL_CTX* ctx = SSL_get_SSL_CTX(ssl);
> #  else
>     SSL_CTX* ctx = ssl->ctx;
> #  endif
>     OpenSSLEngine* p =
> reinterpret_cast<OpenSSLEngine*>(SSL_CTX_get_ex_data(ctx, 0));
>     return p->dhParams(keyLength);
> }
> #  endif
> }
>
> SSL_CTX_set_options(_ctx, SSL_OP_SINGLE_DH_USE);
> SSL_CTX_set_tmp_dh_callback(_ctx, IceSSL_opensslDHCallback);
>
> And for default parameters I'm using d2i_DHparams to restore the DH
> parameters I previously
> saved with i2d_DHparams
>
>
>> Matt
>>
>>
>>>
>>> Regards,
>>> Jos?
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> When using OpenSSL 1.0.1 the connection success
>>>>>
>>>>>    cipher = DHE-DSS-AES256-GCM-SHA384
>>>>>    bits = 256
>>>>>    remote address = 127.0.0.1:43629
>>>>>    protocol = TLSv1.2
>>>>>
>>>>>
>>>>> I try to set security level to 0 for 1.1 but that doesn't make any
>>>>> difference here, any ideas what could be the issue?
>>>>>
>>>> --
>>>> 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

From matt at openssl.org  Fri Jul  1 16:17:35 2016
From: matt at openssl.org (Matt Caswell)
Date: Fri, 1 Jul 2016 17:17:35 +0100
Subject: [openssl-users] DSA with OpenSSL-1.1
In-Reply-To: <CAPwwpXHEc6RhYNkx_cQ34iVpoD481L9gc0BMKEuy3XQhKzm+bg@mail.gmail.com>
References: <CAPwwpXHjDaCevZCOsrBQrV=ZHgpzKhzs7jDeGqQ2jzUSWJi4Hw@mail.gmail.com>
 <57767276.6070802@openssl.org>
 <CAPwwpXGMcZzFGbJgyksHk7nV79ttxpOP-1Bfid=qUYKNSzKAnA@mail.gmail.com>
 <577680D1.6040900@openssl.org>
 <CAPwwpXGJgL=aoUwUVvaDTWcF6VBgSUGHvHXwngbH-nRzaVDBxA@mail.gmail.com>
 <CAPwwpXHEc6RhYNkx_cQ34iVpoD481L9gc0BMKEuy3XQhKzm+bg@mail.gmail.com>
Message-ID: <5776979F.8030308@openssl.org>



On 01/07/16 16:57, pepone.onrez wrote:
> On 1 July 2016 at 16:51, pepone.onrez <pepone.onrez at gmail.com> wrote:
>> On 1 July 2016 at 16:40, Matt Caswell <matt at openssl.org> wrote:
>>>
>>>
>>> On 01/07/16 15:22, pepone.onrez wrote:
>>>> On 1 July 2016 at 15:39, Matt Caswell <matt at openssl.org> wrote:
>>>>>
>>>>>
>>>>> On 01/07/16 14:29, pepone.onrez wrote:
>>>>>> Hi,
>>>>>>
>>>>>> After upgrade my software to use OpenSSL-1.1 one of the test is
>>>>>> failing, the test in question client and server are configured to use
>>>>>> DSA certificates. The server is configured to request a client
>>>>>> certificate.
>>>>>>
>>>>>>    SSL error occurred for new outgoing connection:
>>>>>>    remote address = 127.0.0.1:47812
>>>>>>    error # = 336151568
>>>>>>    message = error:14094410:SSL routines:ssl3_read_bytes:reason(1040)
>>>>>>    location = ssl/record/rec_layer_s3.c, 1467
>>>>>>    data = SSL alert number 40
>>>>>
>>>>> Is this the error you get on the server or the client? The above
>>>>> indicates the connection was aborted because a HandshakeFailure alert
>>>>> was received from the peer. Therefore you need to look at the other end
>>>>> of the communication and see if there is some error message that
>>>>> indicates why the alert was sent.
>>>>>
>>>>> Matt
>>>> That was on the client, looking at the server I see it reports there
>>>> is no shared
>>>> cipher
>>>>
>>>>    SSL error occurred for new incoming connection:
>>>>    remote address = 127.0.0.1:36951
>>>>    error # = 337092801
>>>>    message = error:1417A0C1:SSL
>>>> routines:tls_post_process_client_hello:no shared cipher
>>>>
>>>> I have try to enable all ciphers with ALL:@SECLEVEL=0, but still get
>>>> the same error,
>>>> it is not clear why server client don't find a common cipher here.
> 
> I was not correctly setting the ciphers, Adding DHE to my ciphers and things
> work fine.
> 
> With 1.0.0 I only have DEFAULT:DSS, I guess DHE is not longer in the DEFAULT
> set

There are DHE ciphersuites in the default set, but there are no DSS
ciphersuites.

"DEFAULT" is treated as a special case when processing a cipher string -
and works completely differently to other keywords that you might use.
Most keywords are aliases for a set of ciphersuites, so "DHE" is the set
of all ciphersuites that use DHE; "DSS" is the set of all ciphersuites
that use DSS; "AES" is the set of all ciphersuites that use AES and so
on. "DEFAULT" on the other hand must appear first in a cipher string and
is just shorthand for saying:

"ALL:!COMPLEMENTOFDEFAULT:!eNULL"

COMPLEMENTOFDEFAULT is the set of ciphersuites that we don't switch on
by default (excluding eNULL based ciphersuites), and the "!" means
permanently switch off. So in other words DEFAULT is shorthand for
saying take ALL ciphersuites, and then permanently remove all of those
in the COMPLEMENTOFDEFAULT set, and permanently remove all of those in
the eNULL set.

All DSS based ciphersuites are in COMPLEMENTOFDEFAULT. Therefore
"DEFAULT:DSS" is permanently removing DSS (because its in
COMPLEMENTOFDEFAULT), and then attempting to add it back in again (which
it won't do because its been permanently removed).

Matt










From kurt at roeckx.be  Sat Jul  2 09:52:34 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 2 Jul 2016 11:52:34 +0200
Subject: [openssl-users] DSA with OpenSSL-1.1
In-Reply-To: <c48116daf4494019b6e57b1dd639b28e@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAPwwpXHjDaCevZCOsrBQrV=ZHgpzKhzs7jDeGqQ2jzUSWJi4Hw@mail.gmail.com>
 <20160701164019.7a2b3b16@pc1>
 <B550B44BF8AF314BB00C4E2AC1C18088015E6683D0@prvxmb03.microfocus.com>
 <c48116daf4494019b6e57b1dd639b28e@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20160702095233.GA8188@roeckx.be>

On Fri, Jul 01, 2016 at 03:54:45PM +0000, Salz, Rich wrote:
> 
> > In short: Removing support for DSA in OpenSSL would prevent some of our
> > products from updating to 1.1.x for a significant length of time, probably
> > years.
> 
> We have no plans to do that.

But we do change defaults, and it no longer works by default.


Kurt


From kurt at roeckx.be  Sat Jul  2 09:53:20 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 2 Jul 2016 11:53:20 +0200
Subject: [openssl-users] DSA with OpenSSL-1.1
In-Reply-To: <5776979F.8030308@openssl.org>
References: <CAPwwpXHjDaCevZCOsrBQrV=ZHgpzKhzs7jDeGqQ2jzUSWJi4Hw@mail.gmail.com>
 <57767276.6070802@openssl.org>
 <CAPwwpXGMcZzFGbJgyksHk7nV79ttxpOP-1Bfid=qUYKNSzKAnA@mail.gmail.com>
 <577680D1.6040900@openssl.org>
 <CAPwwpXGJgL=aoUwUVvaDTWcF6VBgSUGHvHXwngbH-nRzaVDBxA@mail.gmail.com>
 <CAPwwpXHEc6RhYNkx_cQ34iVpoD481L9gc0BMKEuy3XQhKzm+bg@mail.gmail.com>
 <5776979F.8030308@openssl.org>
Message-ID: <20160702095319.GB8188@roeckx.be>

On Fri, Jul 01, 2016 at 05:17:35PM +0100, Matt Caswell wrote:
> 
> "ALL:!COMPLEMENTOFDEFAULT:!eNULL"

Maybe we should use "-" instead of "!"?


Kurt


From ohaya at yahoo.com  Sat Jul  2 12:56:18 2016
From: ohaya at yahoo.com (o haya)
Date: Sat, 2 Jul 2016 12:56:18 +0000 (UTC)
Subject: [openssl-users] Analyze why getting "The file is invalid for use as
 the following: Security Certificate"
References: <1876736139.2276727.1467464178465.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <1876736139.2276727.1467464178465.JavaMail.yahoo@mail.yahoo.com>

Hi,

I have a certificate that I issued using a set of openssl commands and when I use "openssl x509" and "openssl verify" to look at it and verify it, it is ok.

Normally, when I take the certificate PEM with an extension of ".crt" or ".cer" in Windows, I can click on the file and the Windows certificate applet will open and I can view the cert.

But, on this one cert, I get the popup with the error in the Subject line, and I'm trying to figure out why this is?

I wanted to post the PEM to this list so someone might be able to review the cert, but I wanted to ask if that is permissible here?  It would be just the PEM for the cert and it would be just a test cert.

Thanks!

Jim


From igenyar at gmail.com  Sun Jul  3 14:42:44 2016
From: igenyar at gmail.com (Igenyar Saharam)
Date: Sun, 3 Jul 2016 07:42:44 -0700
Subject: [openssl-users] how to unsubscribe
Message-ID: <CAG_RFywBEHJTEGj5d4UUe6n9XcoVEyzeH3DjxV7JwmLV8RSR4A@mail.gmail.com>

Hi,


Sorry to bother. The suggestion I found is to send email to openssl-users
with one line message of "unsubscribe openssl-users". I did that but it
still keeps coming. Could someone kindly instruct me the right way?


Thanks,


I
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160703/3535158c/attachment.html>

From kurt at roeckx.be  Sun Jul  3 14:58:27 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 3 Jul 2016 16:58:27 +0200
Subject: [openssl-users] how to unsubscribe
In-Reply-To: <CAG_RFywBEHJTEGj5d4UUe6n9XcoVEyzeH3DjxV7JwmLV8RSR4A@mail.gmail.com>
References: <CAG_RFywBEHJTEGj5d4UUe6n9XcoVEyzeH3DjxV7JwmLV8RSR4A@mail.gmail.com>
Message-ID: <20160703145827.GA26149@roeckx.be>

On Sun, Jul 03, 2016 at 07:42:44AM -0700, Igenyar Saharam wrote:
> Hi,
> 
> 
> Sorry to bother. The suggestion I found is to send email to openssl-users
> with one line message of "unsubscribe openssl-users". I did that but it
> still keeps coming. Could someone kindly instruct me the right way?

Every message to this list contains the instructions.  There are
are 2 options:
- Go to https://mta.openssl.org/mailman/options/openssl-users
- Mail openssl-users-request at openssl.org with subject unsubscribe


Kurt


From ohaya at yahoo.com  Sun Jul  3 17:38:45 2016
From: ohaya at yahoo.com (o haya)
Date: Sun, 3 Jul 2016 17:38:45 +0000 (UTC)
Subject: [openssl-users] Solved was Re: Analyze why getting "The file is
 invalid for use as the following: Security Certificate"
References: <802394226.2583729.1467567525932.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <802394226.2583729.1467567525932.JavaMail.yahoo@mail.yahoo.com>

Hi,

Although I did not post the PEM, I think I figured out why I was getting that error.  I had the "keyUsage" in the extensions, but I had to set criticality to true on that extension.  After that, I can open the cert in the Windows applet.

Jim


--------------------------------------------
On Sat, 7/2/16, o haya <ohaya at yahoo.com> wrote:

 Subject: Analyze why getting "The file is invalid for use as the following: Security Certificate"
 To: openssl-users at openssl.org
 Cc: ohaya at yahoo.com
 Date: Saturday, July 2, 2016, 8:56 AM
 
 Hi,
 
 I have a certificate that I issued using a set of openssl
 commands and when I use "openssl x509" and "openssl verify"
 to look at it and verify it, it is ok.
 
 Normally, when I take the certificate PEM with an extension
 of ".crt" or ".cer" in Windows, I can click on the file and
 the Windows certificate applet will open and I can view the
 cert.
 
 But, on this one cert, I get the popup with the error in the
 Subject line, and I'm trying to figure out why this is?
 
 I wanted to post the PEM to this list so someone might be
 able to review the cert, but I wanted to ask if that is
 permissible here?? It would be just the PEM for the
 cert and it would be just a test cert.
 
 Thanks!
 
 Jim
 

From c.holper at ades.at  Mon Jul  4 10:29:31 2016
From: c.holper at ades.at (c.holper at ades.at)
Date: Mon, 4 Jul 2016 12:29:31 +0200
Subject: [openssl-users] Padding OAEP
Message-ID: <548148ce-67cd-1731-e378-38a5bf4bda62@ades.at>

Hello!

I try to do some XML-ENC with OpenSSL 
(https://www.w3.org/TR/xmlenc-core1/#sec-RSA-OAEP, section 5.5.2) and I 
have some problems with the padding.
Now I have some problems with decrypting a RSA-encoded string.

For identifier "rsa-oaep-mgf1p" I use RSA_PKCS1_OAEP_PADDING for padding 
and it is fine.
For "http://www.w3.org/2001/04/xmlenc#rsa-1_5" I use RSA_PKCS1_PADDING 
and it is also ok.

But it is not working for "rsa-oaep". I tried any padding setting possible.
Any ideas??

Thanks!
Chris




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

From c.holper at ades.at  Mon Jul  4 12:05:08 2016
From: c.holper at ades.at (c.holper at ades.at)
Date: Mon, 4 Jul 2016 14:05:08 +0200
Subject: [openssl-users]  Padding OAEP
Message-ID: <9d204e11-b575-91fc-04a2-64bd2effa523@ades.at>

I had some further analysis.
I am looking for RSA-decryption with OAEP-padding and MGF1 and digest 
SHA-256.
Is there a way to do it??

Thanks!


From cheyendal at fortinet.com  Mon Jul  4 20:19:31 2016
From: cheyendal at fortinet.com (Carl Heyendal)
Date: Mon, 4 Jul 2016 20:19:31 +0000
Subject: [openssl-users] [Newsletter] Re: self-signed certificate won't
 work in my app but works with s_client
In-Reply-To: <CAAopbanx8o6MKKPSQCW4+5t7bciwEwAYQi2pKcnOubjaAu2Abw@mail.gmail.com>
References: <CF8C1824A5EBA84CAB54AD048E722F50482CE1E3@FGT-EXCH-MBX231.fortinet-us.com>
 <CAAopbanx8o6MKKPSQCW4+5t7bciwEwAYQi2pKcnOubjaAu2Abw@mail.gmail.com>
Message-ID: <CF8C1824A5EBA84CAB54AD048E722F50482CF32A@FGT-EXCH-MBX231.fortinet-us.com>

Thanks Matthew.

However the problem seems to be occurring before the processing of the return codes you mentioned.

The problem occurs from a bad return value from:
    if(SSL_connect(ssl) <= 0)
        int_error("Error connecting SSL object");

A Wireshark trace reveals that the client shuts  down the handshake connection with the reason ?Unknown CA?.

So if the client knows that the cert is self-signed as indicated by the debug logs, why would it issue the above reason for failure when it doesn?t need to know the CA?

Carl



From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matthew Donald
Sent: July-01-16 12:09 AM
To: openssl-users at openssl.org
Subject: [Newsletter] Re: [openssl-users] self-signed certificate won't work in my app but works with s_client

"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 <cheyendal at fortinet.com<mailto:cheyendal at fortinet.com>> 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<http://192.168.1.99:16001> -CAfile ../_security/SipInspector/certificate.pem -key ../_security/client.pem
      Enter pass phrase for ../_security/client.pem:
      CONNECTED(00000003)
      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<http://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 mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



***  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. *** 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160704/8c1c42ab/attachment-0001.html>

From rsalz at akamai.com  Mon Jul  4 21:19:57 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 4 Jul 2016 21:19:57 +0000
Subject: [openssl-users] [Newsletter] Re: self-signed certificate won't
 work in my app but works with s_client
In-Reply-To: <CF8C1824A5EBA84CAB54AD048E722F50482CF32A@FGT-EXCH-MBX231.fortinet-us.com>
References: <CF8C1824A5EBA84CAB54AD048E722F50482CE1E3@FGT-EXCH-MBX231.fortinet-us.com>
 <CAAopbanx8o6MKKPSQCW4+5t7bciwEwAYQi2pKcnOubjaAu2Abw@mail.gmail.com>
 <CF8C1824A5EBA84CAB54AD048E722F50482CF32A@FGT-EXCH-MBX231.fortinet-us.com>
Message-ID: <6908d69baf1146819f856edfb0c3a4a9@usma1ex-dag1mb1.msg.corp.akamai.com>

> A Wireshark trace reveals that the client shuts? down the handshake connection with the reason ?Unknown CA?.

> So if the client knows that the cert is self-signed as indicated by the debug logs, why would it issue the above reason for failure when it doesn?t need to know the CA?

You still have to add the CA to your local trust store.

Otherwise, you'd blindly accept *every* self-signed certificate, right?

From c.holper at ades.at  Tue Jul  5 08:45:42 2016
From: c.holper at ades.at (c.holper at ades.at)
Date: Tue, 5 Jul 2016 10:45:42 +0200
Subject: [openssl-users]  Padding OAEP
Message-ID: <9562496c-01aa-9d1a-a6a1-3b76fcaf756d@ades.at>

Hi!

I had a look into Apache Santuario. A XML-Security-Framework using OpenSSL.
For my eyes it looks like only OAEP with MGF SHA1 is supported out of 
the OpenSSL-box.

Other digests need to be handeled manually.
In Santuario they wrote an own RSA_padding_check_PKCS1_OAEP with 2 new 
parameters for MGF and digest.

Chris

From pbellino at mrv.com  Tue Jul  5 10:18:12 2016
From: pbellino at mrv.com (Philip Bellino)
Date: Tue, 5 Jul 2016 10:18:12 +0000
Subject: [openssl-users] DSA with OpenSSL-1.1
In-Reply-To: <20160702095319.GB8188@roeckx.be>
References: <CAPwwpXHjDaCevZCOsrBQrV=ZHgpzKhzs7jDeGqQ2jzUSWJi4Hw@mail.gmail.com>
 <57767276.6070802@openssl.org>
 <CAPwwpXGMcZzFGbJgyksHk7nV79ttxpOP-1Bfid=qUYKNSzKAnA@mail.gmail.com>
 <577680D1.6040900@openssl.org>
 <CAPwwpXGJgL=aoUwUVvaDTWcF6VBgSUGHvHXwngbH-nRzaVDBxA@mail.gmail.com>
 <CAPwwpXHEc6RhYNkx_cQ34iVpoD481L9gc0BMKEuy3XQhKzm+bg@mail.gmail.com>
 <5776979F.8030308@openssl.org>,<20160702095319.GB8188@roeckx.be>
Message-ID: <AM4PR0301MB2051BC4880DB56527C92C7B2C3390@AM4PR0301MB2051.eurprd03.prod.outlook.com>

Well, since we will never go to 1.1, I guess we don't have to worry about it.

________________________________
From: openssl-users <openssl-users-bounces at openssl.org> on behalf of Kurt Roeckx <kurt at roeckx.be>
Sent: Saturday, July 2, 2016 5:53:20 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] DSA with OpenSSL-1.1

On Fri, Jul 01, 2016 at 05:17:35PM +0100, Matt Caswell wrote:
>
> "ALL:!COMPLEMENTOFDEFAULT:!eNULL"

Maybe we should use "-" instead of "!"?


Kurt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[E-Banner]<http://www.mrv.com/products/os-v>


MRV Communications is a global supplier of packet and optical solutions that power the world's largest networks. Our products combine innovative hardware with intelligent software to make networks smarter, faster and more efficient.



The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160705/c363cf30/attachment.html>

From Michal.Trojnara at stunnel.org  Tue Jul  5 21:37:28 2016
From: Michal.Trojnara at stunnel.org (=?UTF-8?Q?Micha=c5=82_Trojnara?=)
Date: Tue, 5 Jul 2016 23:37:28 +0200
Subject: [openssl-users] stunnel 5.34 released
Message-ID: <577C2898.2090001@stunnel.org>

Dear Users,

I have released version 5.34 of stunnel.
This release includes a major security bugfix.

The ChangeLog entry:

Version 5.34, 2016.07.05, urgency: HIGH
* Security bugfixes
  - Fixed malfunctioning "verify = 4".
* New features
  - Bind sockets with SO_EXCLUSIVEADDRUSE on WIN32.
  - Added three new service-level options: requireCert, verifyChain,
    and verifyPeer for fine-grained certificate verification control.
  - Improved compatibility with the current OpenSSL 1.1.0-dev tree.

Home page: https://www.stunnel.org/
Download:  https://www.stunnel.org/downloads.html

SHA-256 hashes:
786111168a84a5a01188dddfcecb37d8c69a4c725dc3b476fbbd294e86741a55
stunnel-5.34.tar.gz
abddf49a02e810bf618884f6ac8fde2c1e59bda73c65c4fd9a82b724524b4d9f
stunnel-5.34-installer.exe
6ae4aa536b9083da69b5e8905c85f4655db9ebfc95b79c8a67adbf309181c10d
stunnel-5.34-android.zip

Best regards,
    Mike

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160705/74969fe7/attachment.sig>

From steve at openssl.org  Wed Jul  6 03:15:11 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 6 Jul 2016 03:15:11 +0000
Subject: [openssl-users] Unable to decrypt CMS object encrypted with EC
 prime256v1 certificate
In-Reply-To: <cdc66922-e976-7023-164c-3872418ff54d@pdflib.com>
References: <cdc66922-e976-7023-164c-3872418ff54d@pdflib.com>
Message-ID: <20160706031511.GA8035@openssl.org>

On Fri, Jul 01, 2016, Stephan M?hlstrasser wrote:

> Hi,
> 
> we are testing OpenSSL interoperability with a third-party
> application, and we cannot decrypt a CMS object that is encrypted by
> the third-party application with a prime256v1 elliptic-curve
> certificate.
> 
> I have attached the following files:
> 
> demo_signer_ec_secp256r1.cms.der: DER-encoded CMS object
> demo_signer_ec_secp256r1.cert.pem: recipient certificate
> demo_signer_ec_secp256r1.pkey.pem. recipient private key (no password)
> 
> I try to decrypt the CMS object with the following command using
> OpenSSL 1.0.2:
> 
> $ openssl version
> OpenSSL 1.0.2h  3 May 2016
> $ openssl cms -decrypt -in demo_signer_ec_secp256r1.cms.der  -inform
> DER -recip  demo_signer_ec_secp256r1.cert.pem  -inkey
> demo_signer_ec_secp256r1.pkey.pem
> Error decrypting CMS using private key
> 
> When I use OpenSSL 1.1.0 beta from today's HEAD of the master
> branch, I see an additional error message:
> 
> $ openssl version
> OpenSSL 1.1.0-pre6-dev  xx XXX xxxx
> $ openssl cms -decrypt -in demo_signer_ec_secp256r1.cms.der  -inform
> DER -recip  demo_signer_ec_secp256r1.cert.pem  -inkey
> demo_signer_ec_secp256r1.pkey.pem
> Error decrypting CMS using private key
> 140735294530304:error:0D06E0A4:asn1 encoding
> routines:asn1_do_adb:unsupported any defined by
> type:crypto/asn1/tasn_utl.c:238:
> 

The final error is bogus: fixed in current master.

> Is the CMS object broken, or is this a problem in OpenSSL?
> 

Well the OpenSSL version does interop OK with the Bouncy Castle version of
ECDH and CMS. I've checked through your test message and the problem is that
the AES unwrapping algorithm checks fail meaning it can't proceed any further.
That could be down to a CMS problem, an ECDH issue or a problem with the wrap
algorithm either in the version you are testing or OpenSSL.

Is it possible to get any debugging information from the other version you are
using: for example the content encryption key it is expecting or the ECDH
shared secret?

Have you tried generating an message with OpenSSL and decrypting it with the
other version?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From sdouglas at redhat.com  Wed Jul  6 07:37:30 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 6 Jul 2016 17:37:30 +1000
Subject: [openssl-users] Dynamically loading OpenSSL on Windows
Message-ID: <CAD+L2cwqCt-Gpo3MN8VTgufWeuj88iOGH=jyoKoMWVSoGMuSxg@mail.gmail.com>

Hi everyone,

I am trying to implement a generic Java SSLContext that is backed by
OpenSSL that uses dynamic loading to link to OpenSSL.

This works well on Linux, however I am running into "no
OPENSSL_Applink" issues on Windows. According to the FAQ all that
should be required is including openssl\applink.c, however this will
not work in my case as the main process is the java executable, and
not my glue library, so the uplink function is not finding it.

Is there any way I can get this working? I have had a quick look at
the uplink code and as far as I can tell I am out of luck, but I am
hoping I have missed something.

Stuart

From Matthias.St.Pierre at ncp-e.com  Wed Jul  6 11:11:40 2016
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Wed, 6 Jul 2016 13:11:40 +0200
Subject: [openssl-users] Dynamically loading OpenSSL on Windows
In-Reply-To: <CAD+L2cwqCt-Gpo3MN8VTgufWeuj88iOGH=jyoKoMWVSoGMuSxg@mail.gmail.com>
References: <CAD+L2cwqCt-Gpo3MN8VTgufWeuj88iOGH=jyoKoMWVSoGMuSxg@mail.gmail.com>
Message-ID: <577CE76C.9080902@ncp-e.com>



On 06.07.2016 09:37, Stuart Douglas wrote:
> Hi everyone,
> 
> I am trying to implement a generic Java SSLContext that is backed by
> OpenSSL that uses dynamic loading to link to OpenSSL.
> 
> This works well on Linux, however I am running into "no
> OPENSSL_Applink" issues on Windows. According to the FAQ all that
> should be required is including openssl\applink.c, however this will
> not work in my case as the main process is the java executable, and
> not my glue library, so the uplink function is not finding it.
> 
> Is there any way I can get this working? I have had a quick look at
> the uplink code and as far as I can tell I am out of luck, but I am
> hoping I have missed something.
> 
> Stuart
> 


If you take a look at the OPENSSL_Uplink() function (ms/uplink.c), you
will see that the code gets the applink function pointer via

  apphandle = GetModuleHandle(NULL);
  applink = GetProcAddress(apphandle, "OPENSSL_Applink")

i.e., OpenSSL expects the OPENSSL_Applink() function to be "DLL-exported"
from  the executable itself, see [1]. 

(If this sounds weird to you, don't worry, you're  not alone ;-)

In my opinion this is a design flaw which makes it almost impossible to 
have a wrapper dll around the OpenSSL library, since you always have to
modify the excutable to be able to link.

The back links are necessary, but the way they are obtained is bad design.
The best solution for this would be to have an OpenSSL API call such as 
OPENSSL_register_applink(), which could be used by an executable or 
a shared library likewise. The only problem I see is to add the new
api and stay compatible to the old hacky way.

Maybe you should open a ticket on the rt for this.


Regards,

Matthias



[1] MSDN - GetModuleHandle
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683199(v=vs.85).aspx

From steve at openssl.org  Wed Jul  6 13:46:00 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 6 Jul 2016 13:46:00 +0000
Subject: [openssl-users] How to turn on certain elements in CMS objects
In-Reply-To: <34ef0c81-bc5f-d97d-2a92-3774924763c9@pdflib.com>
References: <34ef0c81-bc5f-d97d-2a92-3774924763c9@pdflib.com>
Message-ID: <20160706134600.GA16818@openssl.org>

On Fri, Jul 01, 2016, Stephan M?hlstrasser wrote:

> Hi,
> 
> this message is related to another question that I sent with subject
> "Unable to decrypt CMS object encrypted with EC prime256v1
> certificate".
> 
> Below I have included the full ASN.1 dump of the CMS object
> generated by a third-party application.
> 
> The CMS object has two properties that I so far was not able to
> reproduce when creating CMS objects with OpenSSL:
> 
> First the AlgorithmIdentifier includes the EC curve name:
> 
>   40   19:               SEQUENCE {
>   42    7:                 OBJECT IDENTIFIER ecPublicKey (1 2 840
> 10045 2 1)
>   51    8:                 OBJECT IDENTIFIER ansiX9p256r1 (1 2 840
> 10045 3 1 7)
>          :                 }
> 
> In CMS objects created with OpenSSL with the same recipient
> certificate, the curve name is always omitted. Is it possible to
> make OpenSSL emit the curve name as well?
> 

No as this is a violation of the standards. From RFC3278:

      originator MUST be the alternative originatorKey.  The
      originatorKey algorithm field MUST contain the id-ecPublicKey
      object identifier (see Section 8.1) with NULL parameters.  The
      originatorKey publicKey field MUST contain the DER-encoding of a
      value of the ASN.1 type ECPoint (see Section 8.2), which
      represents the sending agent's ephemeral EC public key.


> Second the following:
> 
>  129   10:           [1] {
>  131    8:             OCTET STRING B1 04 4A FD FC 8B 70 6D
>          :             }
> 
> If I match this correctly to RFC 5652, this is
> 
> ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL
> 
> inside the KeyAgreeRecipientInfo SEQUENCE (see
> https://tools.ietf.org/html/rfc5652#section-6.2.2).
> 
> Can OpenSSL emit this optional element?

Yes but not using the command line utility. It would require a custom program
to set the parameter using the CMS API.

> What is the purpose of the "ukm" field?
> 

It provides some additional optional random data used in the key encryption
key derivation algorithm.

Note that you can get a diagnistic dump using:

  openssl cms -cmsout -inform DER -print -in cmd.der

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From steve at openssl.org  Wed Jul  6 14:02:21 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 6 Jul 2016 14:02:21 +0000
Subject: [openssl-users] How to turn on certain elements in CMS objects
In-Reply-To: <20160706134600.GA16818@openssl.org>
References: <34ef0c81-bc5f-d97d-2a92-3774924763c9@pdflib.com>
 <20160706134600.GA16818@openssl.org>
Message-ID: <20160706140221.GA17419@openssl.org>

On Wed, Jul 06, 2016, Dr. Stephen Henson wrote:

> On Fri, Jul 01, 2016, Stephan M?hlstrasser wrote:
> 
> > 
> > First the AlgorithmIdentifier includes the EC curve name:
> > 
> >   40   19:               SEQUENCE {
> >   42    7:                 OBJECT IDENTIFIER ecPublicKey (1 2 840
> > 10045 2 1)
> >   51    8:                 OBJECT IDENTIFIER ansiX9p256r1 (1 2 840
> > 10045 3 1 7)
> >          :                 }
> > 
> > In CMS objects created with OpenSSL with the same recipient
> > certificate, the curve name is always omitted. Is it possible to
> > make OpenSSL emit the curve name as well?
> > 
> 
> No as this is a violation of the standards. From RFC3278:
> 
>       originator MUST be the alternative originatorKey.  The
>       originatorKey algorithm field MUST contain the id-ecPublicKey
>       object identifier (see Section 8.1) with NULL parameters.  The
>       originatorKey publicKey field MUST contain the DER-encoding of a
>       value of the ASN.1 type ECPoint (see Section 8.2), which
>       represents the sending agent's ephemeral EC public key.
> 

Correction... that is not allowed by RFC3278 but is allowed in RFC5753 but
OpenSSL doesn't currently generate that format. It's not clear what purpose it
serves as the EC parameters are specified in the recipient's key and
certificate anyway.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From stm at pdflib.com  Wed Jul  6 14:47:12 2016
From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=)
Date: Wed, 6 Jul 2016 16:47:12 +0200
Subject: [openssl-users] How to turn on certain elements in CMS objects
In-Reply-To: <20160706140221.GA17419@openssl.org>
References: <34ef0c81-bc5f-d97d-2a92-3774924763c9@pdflib.com>
 <20160706134600.GA16818@openssl.org> <20160706140221.GA17419@openssl.org>
Message-ID: <4b763754-0e37-34ef-eff4-6e7c392b82ca@pdflib.com>

Am 06.07.16 um 16:02 schrieb Dr. Stephen Henson:
> On Wed, Jul 06, 2016, Dr. Stephen Henson wrote:
>
>> On Fri, Jul 01, 2016, Stephan M?hlstrasser wrote:
>>
>>>
>>> First the AlgorithmIdentifier includes the EC curve name:
>>>
>>>   40   19:               SEQUENCE {
>>>   42    7:                 OBJECT IDENTIFIER ecPublicKey (1 2 840
>>> 10045 2 1)
>>>   51    8:                 OBJECT IDENTIFIER ansiX9p256r1 (1 2 840
>>> 10045 3 1 7)
>>>          :                 }
>>>
>>> In CMS objects created with OpenSSL with the same recipient
>>> certificate, the curve name is always omitted. Is it possible to
>>> make OpenSSL emit the curve name as well?
>>>
>>
>> No as this is a violation of the standards. From RFC3278:
>>
>>       originator MUST be the alternative originatorKey.  The
>>       originatorKey algorithm field MUST contain the id-ecPublicKey
>>       object identifier (see Section 8.1) with NULL parameters.  The
>>       originatorKey publicKey field MUST contain the DER-encoding of a
>>       value of the ASN.1 type ECPoint (see Section 8.2), which
>>       represents the sending agent's ephemeral EC public key.
>>
>
> Correction... that is not allowed by RFC3278 but is allowed in RFC5753 but
> OpenSSL doesn't currently generate that format. It's not clear what purpose it
> serves as the EC parameters are specified in the recipient's key and
> certificate anyway.

So do I understand it correctly that OpenSSL currentls only supports 
RFC3278? Does that mean that it can't process CMS enveloped data objects 
that are created according to RFC5753?

In my other thread titled "Unable to decrypt CMS object encrypted with 
EC prime256v1 certificate" the CMS object that cannot be decrypted with 
OpenSSL does contain the EC parameters. Can that be related to the problem?

-- 
Stephan

From stm at pdflib.com  Wed Jul  6 14:52:27 2016
From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=)
Date: Wed, 6 Jul 2016 16:52:27 +0200
Subject: [openssl-users] How to turn on certain elements in CMS objects
In-Reply-To: <20160706134600.GA16818@openssl.org>
References: <34ef0c81-bc5f-d97d-2a92-3774924763c9@pdflib.com>
 <20160706134600.GA16818@openssl.org>
Message-ID: <529dd883-0a0e-24a6-d5b9-91d0b98cdff7@pdflib.com>

Am 06.07.16 um 15:46 schrieb Dr. Stephen Henson:
>...
>
>> Second the following:
>>
>>  129   10:           [1] {
>>  131    8:             OCTET STRING B1 04 4A FD FC 8B 70 6D
>>          :             }
>>
>> If I match this correctly to RFC 5652, this is
>>
>> ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL
>>
>> inside the KeyAgreeRecipientInfo SEQUENCE (see
>> https://tools.ietf.org/html/rfc5652#section-6.2.2).
>>
>> Can OpenSSL emit this optional element?
>
> Yes but not using the command line utility. It would require a custom program
> to set the parameter using the CMS API.

Could you pleaee briefly explain how set the parameter? I could not find 
anything in the documentation of the CMS API about this.

>> What is the purpose of the "ukm" field?
>>
>
> It provides some additional optional random data used in the key encryption
> key derivation algorithm.
>
> Note that you can get a diagnistic dump using:
>
>   openssl cms -cmsout -inform DER -print -in cmd.der

I wasn't aware of this feature, that looks very useful, thanks!

-- 
Stephan

From dni.grosu at gmail.com  Wed Jul  6 14:58:38 2016
From: dni.grosu at gmail.com (Daniel Grosu)
Date: Wed, 6 Jul 2016 17:58:38 +0300
Subject: [openssl-users] Call rsa_mod_exp for more than one exponentiation
Message-ID: <CAGYz=CxH1sr5xvHKGXLrJeW5+eadqamfQ0GBkQ6GQqNTejE_Gw@mail.gmail.com>

Hi.
Is it possible to call the rsa_mod_exp method in RSA_METHOD structure for
more than one exponentiation?

E.g.: openssl `speed rsa -engine my_engine` will call rsa_mod_exp for every
single rsa sign/verify operation, but I want to queue, let's say 10 of
these operations and process them in a single rsa_mod_exp call.

I want to do this because the RSA ENGINE is using GPU based implementations
which are faster the CPU (default) based implementations when executes
multiple operations in parallel.

Best regards,
Dani Grosu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160706/84e6783c/attachment.html>

From stm at pdflib.com  Wed Jul  6 15:16:47 2016
From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=)
Date: Wed, 6 Jul 2016 17:16:47 +0200
Subject: [openssl-users] Unable to decrypt CMS object encrypted with EC
 prime256v1 certificate
In-Reply-To: <20160706031511.GA8035@openssl.org>
References: <cdc66922-e976-7023-164c-3872418ff54d@pdflib.com>
 <20160706031511.GA8035@openssl.org>
Message-ID: <56d2b6cb-5e45-300b-5050-8831c8126b97@pdflib.com>

Am 06.07.16 um 05:15 schrieb Dr. Stephen Henson:
> ...
>> Is the CMS object broken, or is this a problem in OpenSSL?
>>
>
> Well the OpenSSL version does interop OK with the Bouncy Castle version of
> ECDH and CMS. I've checked through your test message and the problem is that
> the AES unwrapping algorithm checks fail meaning it can't proceed any further.
> That could be down to a CMS problem, an ECDH issue or a problem with the wrap
> algorithm either in the version you are testing or OpenSSL.
>
> Is it possible to get any debugging information from the other version you are
> using: for example the content encryption key it is expecting or the ECDH
> shared secret?

I don't know whether that is possible, I will check.

> Have you tried generating an message with OpenSSL and decrypting it with the
> other version?

Yes, the other version cannot decrypt the CMS object generated by 
OpenSSL. I did some tests with Bouncy Castle, and it also cannot decrypt 
the CMS object.

What might be interesting is that on the other hand Windows CryptoAPI is 
able to decrypt the CMS object (tested on Windows 10).

While doing research on this, we found one thing that looks suspicious 
in the CMS objects generated by OpenSSL 1.0.2. When dumping the CMS 
object with dumpasn1, the key wrap algorithm is encoded as follows:

SEQUENCE {
  OBJECT IDENTIFIER '1 3 132 1 11 3'
  SEQUENCE {
    OBJECT IDENTIFIER aes256-wrap (2 16 840 1 101 3 4 1 45)
    NULL
    }
  }

Note the NULL parameter in the aes256-wrap algorithm identifier. Compare 
that to RFC 3565, "2.3.2.  AES CEK Wrap Process":

https://tools.ietf.org/html/rfc3565#section-2.3.2

"In all cases the parameters field MUST be absent."

Does this refer to the parameters field of the AlgorithmIdentifier of 
the AES key wrap algorithm? Then it would be incorrect to include the 
NULL here.

-- 
Stephan

From scott_n at xypro.com  Wed Jul  6 15:55:36 2016
From: scott_n at xypro.com (Scott Neugroschl)
Date: Wed, 6 Jul 2016 15:55:36 +0000
Subject: [openssl-users] Error building 1.0.1t with no-srp
Message-ID: <D358E5B1511A314F8160ADC6F3754987343AE07D@XYSVEX02.XYPRO-23.LOCAL>

I'm building 1.0.1t with the no-srp option.    When I do, I get thefollowing error

making all in ssl...
make[1]: Entering directory `/users/scottn/openssl-1.0.1t/ssl'
make[1]: *** No rule to make target `../include/openssl/srp.h', needed by `tls_srp.o'.  Stop.

Anyone else build without SRP?  Anyone have suggestions?
---
Scott Neugroschl | XYPRO Technology Corporation
4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 |



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160706/e89e5e25/attachment-0001.html>

From steve at openssl.org  Wed Jul  6 21:31:09 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 6 Jul 2016 21:31:09 +0000
Subject: [openssl-users] How to turn on certain elements in CMS objects
In-Reply-To: <4b763754-0e37-34ef-eff4-6e7c392b82ca@pdflib.com>
References: <34ef0c81-bc5f-d97d-2a92-3774924763c9@pdflib.com>
 <20160706134600.GA16818@openssl.org>
 <20160706140221.GA17419@openssl.org>
 <4b763754-0e37-34ef-eff4-6e7c392b82ca@pdflib.com>
Message-ID: <20160706213109.GA22346@openssl.org>

On Wed, Jul 06, 2016, Stephan M?hlstrasser wrote:

> So do I understand it correctly that OpenSSL currentls only supports
> RFC3278? Does that mean that it can't process CMS enveloped data
> objects that are created according to RFC5753?
> 

OpenSSL should be able to decrypt either RFC3278 or RFC5753 forms.

> In my other thread titled "Unable to decrypt CMS object encrypted
> with EC prime256v1 certificate" the CMS object that cannot be
> decrypted with OpenSSL does contain the EC parameters. Can that be
> related to the problem?
> 

It shouldn't affect OpenSSL's ability to decrypt the object as that
information is not used anywhere in the key derivation.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From steve at openssl.org  Wed Jul  6 21:35:40 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 6 Jul 2016 21:35:40 +0000
Subject: [openssl-users] Unable to decrypt CMS object encrypted with EC
 prime256v1 certificate
In-Reply-To: <56d2b6cb-5e45-300b-5050-8831c8126b97@pdflib.com>
References: <cdc66922-e976-7023-164c-3872418ff54d@pdflib.com>
 <20160706031511.GA8035@openssl.org>
 <56d2b6cb-5e45-300b-5050-8831c8126b97@pdflib.com>
Message-ID: <20160706213540.GB22346@openssl.org>

On Wed, Jul 06, 2016, Stephan M?hlstrasser wrote:

> Am 06.07.16 um 05:15 schrieb Dr. Stephen Henson:
> >...
> >>Is the CMS object broken, or is this a problem in OpenSSL?
> >>
> >
> >Well the OpenSSL version does interop OK with the Bouncy Castle version of
> >ECDH and CMS. I've checked through your test message and the problem is that
> >the AES unwrapping algorithm checks fail meaning it can't proceed any further.
> >That could be down to a CMS problem, an ECDH issue or a problem with the wrap
> >algorithm either in the version you are testing or OpenSSL.
> >
> >Is it possible to get any debugging information from the other version you are
> >using: for example the content encryption key it is expecting or the ECDH
> >shared secret?
> 
> I don't know whether that is possible, I will check.
> 
> >Have you tried generating an message with OpenSSL and decrypting it with the
> >other version?
> 
> Yes, the other version cannot decrypt the CMS object generated by
> OpenSSL. I did some tests with Bouncy Castle, and it also cannot
> decrypt the CMS object.
> 
> What might be interesting is that on the other hand Windows
> CryptoAPI is able to decrypt the CMS object (tested on Windows 10).
> 

Just to clarify: you're saying that neither this third party version nor
BouncyCastler can decrypt the OpenSSL generated CMS objects?

> While doing research on this, we found one thing that looks
> suspicious in the CMS objects generated by OpenSSL 1.0.2. When
> dumping the CMS object with dumpasn1, the key wrap algorithm is
> encoded as follows:
> 
> SEQUENCE {
>  OBJECT IDENTIFIER '1 3 132 1 11 3'
>  SEQUENCE {
>    OBJECT IDENTIFIER aes256-wrap (2 16 840 1 101 3 4 1 45)
>    NULL
>    }
>  }
> 
> Note the NULL parameter in the aes256-wrap algorithm identifier.
> Compare that to RFC 3565, "2.3.2.  AES CEK Wrap Process":
> 
> https://tools.ietf.org/html/rfc3565#section-2.3.2
> 
> "In all cases the parameters field MUST be absent."
> 
> Does this refer to the parameters field of the AlgorithmIdentifier
> of the AES key wrap algorithm? Then it would be incorrect to include
> the NULL here.
> 

I'll check. That looks like a bug as the code should be excluding the NULL.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From steve at openssl.org  Wed Jul  6 22:16:48 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 6 Jul 2016 22:16:48 +0000
Subject: [openssl-users] Unable to decrypt CMS object encrypted with EC
 prime256v1 certificate
In-Reply-To: <56d2b6cb-5e45-300b-5050-8831c8126b97@pdflib.com>
References: <cdc66922-e976-7023-164c-3872418ff54d@pdflib.com>
 <20160706031511.GA8035@openssl.org>
 <56d2b6cb-5e45-300b-5050-8831c8126b97@pdflib.com>
Message-ID: <20160706221648.GA23129@openssl.org>

On Wed, Jul 06, 2016, Stephan M?hlstrasser wrote:

> 
> While doing research on this, we found one thing that looks
> suspicious in the CMS objects generated by OpenSSL 1.0.2. When
> dumping the CMS object with dumpasn1, the key wrap algorithm is
> encoded as follows:
> 
> SEQUENCE {
>  OBJECT IDENTIFIER '1 3 132 1 11 3'
>  SEQUENCE {
>    OBJECT IDENTIFIER aes256-wrap (2 16 840 1 101 3 4 1 45)
>    NULL
>    }
>  }
> 

That's strange: I just tried OpenSSL 1.0.2 and the master branch and I don't
get a NULL in either case.

Also that algorithm isn't something you'd get by default with OpenSSL. Has it
been modified in some way?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From stm at pdflib.com  Thu Jul  7 07:24:08 2016
From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=)
Date: Thu, 7 Jul 2016 09:24:08 +0200
Subject: [openssl-users] Unable to decrypt CMS object encrypted with EC
 prime256v1 certificate
In-Reply-To: <20160706221648.GA23129@openssl.org>
References: <cdc66922-e976-7023-164c-3872418ff54d@pdflib.com>
 <20160706031511.GA8035@openssl.org>
 <56d2b6cb-5e45-300b-5050-8831c8126b97@pdflib.com>
 <20160706221648.GA23129@openssl.org>
Message-ID: <3f1e036a-2ef1-ea82-d322-ef21c5b5c710@pdflib.com>

Am 07.07.16 um 00:16 schrieb Dr. Stephen Henson:
> On Wed, Jul 06, 2016, Stephan M?hlstrasser wrote:
>
>>
>> While doing research on this, we found one thing that looks
>> suspicious in the CMS objects generated by OpenSSL 1.0.2. When
>> dumping the CMS object with dumpasn1, the key wrap algorithm is
>> encoded as follows:
>>
>> SEQUENCE {
>>  OBJECT IDENTIFIER '1 3 132 1 11 3'
>>  SEQUENCE {
>>    OBJECT IDENTIFIER aes256-wrap (2 16 840 1 101 3 4 1 45)
>>    NULL
>>    }
>>  }
>>
>
> That's strange: I just tried OpenSSL 1.0.2 and the master branch and I don't
> get a NULL in either case.

I apologize, you are right. I tracked this down to the fact that the CMS 
object was created with an OpenSSL 1.0.2 beta version. Sorry for the 
confusion.

> Also that algorithm isn't something you'd get by default with OpenSSL. Has it
> been modified in some way?

It has not been modified. The algorithm is set with the 
EVP_PKEY_CTX_ctrl_str() function:

EVP_PKEY_CTX_ctrl_str(ctx, "ecdh_kdf_md", "sha256");

-- 
Stephan

From stm at pdflib.com  Thu Jul  7 07:46:25 2016
From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=)
Date: Thu, 7 Jul 2016 09:46:25 +0200
Subject: [openssl-users] Unable to decrypt CMS object encrypted with EC
 prime256v1 certificate
In-Reply-To: <20160706213540.GB22346@openssl.org>
References: <cdc66922-e976-7023-164c-3872418ff54d@pdflib.com>
 <20160706031511.GA8035@openssl.org>
 <56d2b6cb-5e45-300b-5050-8831c8126b97@pdflib.com>
 <20160706213540.GB22346@openssl.org>
Message-ID: <3ffc241f-e56c-c6aa-84a8-7483884a73ed@pdflib.com>

Am 06.07.16 um 23:35 schrieb Dr. Stephen Henson:
> ...
>> Yes, the other version cannot decrypt the CMS object generated by
>> OpenSSL. I did some tests with Bouncy Castle, and it also cannot
>> decrypt the CMS object.
>>
>> What might be interesting is that on the other hand Windows
>> CryptoAPI is able to decrypt the CMS object (tested on Windows 10).
>>
>
> Just to clarify: you're saying that neither this third party version nor
> BouncyCastler can decrypt the OpenSSL generated CMS objects?

No, I didn't want to say that. BouncyCastle is unable to decrypt the 
third-party CMS object that I sent as an attachment in the initial email 
of this thread.

OpenSSL and BouncyCastle interoperate just fine, I can encrypt and 
decrypt CMS messages in both directions without problems.

-- 
Stephan

From matt at openssl.org  Thu Jul  7 08:43:37 2016
From: matt at openssl.org (Matt Caswell)
Date: Thu, 7 Jul 2016 09:43:37 +0100
Subject: [openssl-users] Error building 1.0.1t with no-srp
In-Reply-To: <D358E5B1511A314F8160ADC6F3754987343AE07D@XYSVEX02.XYPRO-23.LOCAL>
References: <D358E5B1511A314F8160ADC6F3754987343AE07D@XYSVEX02.XYPRO-23.LOCAL>
Message-ID: <577E1639.4090404@openssl.org>



On 06/07/16 16:55, Scott Neugroschl wrote:
> I?m building 1.0.1t with the no-srp option.    When I do, I get
> thefollowing error
> 
>  
> 
> making all in ssl...
> 
> make[1]: Entering directory `/users/scottn/openssl-1.0.1t/ssl'
> 
> make[1]: *** No rule to make target `../include/openssl/srp.h', needed
> by `tls_srp.o'.  Stop.
> 
>  
> 
> Anyone else build without SRP?  Anyone have suggestions?

It works for me with 1.0.1t. Did you run "make depend"?

Matt



From chris.bare at gmail.com  Thu Jul  7 18:08:08 2016
From: chris.bare at gmail.com (Chris Bare)
Date: Thu, 7 Jul 2016 14:08:08 -0400
Subject: [openssl-users] EVP_get_digestbyobj fails for ecdsa-with-SHA256
Message-ID: <CAHR5+EF7KJgg3Lfu9znHoeWLmv3d4qSupynUuVgNbt_T9zpstw@mail.gmail.com>

EVP_get_digestbyobj fails for ecdsa-with-SHA256

I'm trying to perform a standard signature verification using the EVP_*
functions.
I think my code is correct, because it all runs fine if the digest is
RSA-SHA256.
I have an ASN1_OBJECT that specifics the signature/disgest type.
Here is my code that dumps out all the intermediate steps called by
EVP_get_digestbyobj:

ASN1_OBJECT * ;

OBJ_obj2txt(name, 256, sig_alg_oid, 1);
printf ("NAME %s", name);
printf ("NID = %d", OBJ_obj2nid(sig_alg_oid));
printf ("sn = %s", OBJ_nid2sn(OBJ_obj2nid(sig_alg_oid)));
printf ("OBJ_NAME_get = %p",
OBJ_NAME_get(OBJ_nid2sn(OBJ_obj2nid(sig_alg_oid)),OBJ_NAME_TYPE_MD_METH));
const EVP_MD* md = EVP_get_digestbyobj(sig_alg_oid);
if(md == NULL)
        printf ("EVP_get_digestbyobj failed");

When I call this with the RSA-SHA256 I get:
NAME 1.2.840.113549.1.1.11
NID = 668
sn = RSA-SHA256
OBJ_NAME_get = 0x7fe8846f1ee0

and the rest of the steps succeeed.
Then when I call the same code (in the same program, so I'm sure the
openssl library is correctly initialized) with
ecdsa-with-SHA256, I get:
NAME 1.2.840.10045.4.3.2
NID = 794
sn = ecdsa-with-SHA256
OBJ_NAME_get = (nil)
EVP_get_digestbyobj failed

So it looks like my sig_alg_oid is good, but OBJ_NAME_get fails.

I am using openssl 1.0.2d-0ubuntu1.5 in ubuntu 15.10

Am I doing something wrong, or could this be a bug in the library?
Any suggestions appreciated.

-- 
Chris Bare
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160707/58a4a96b/attachment.html>

From jb-openssl at wisemo.com  Thu Jul  7 18:54:50 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 7 Jul 2016 20:54:50 +0200
Subject: [openssl-users] EVP_get_digestbyobj fails for ecdsa-with-SHA256
In-Reply-To: <CAHR5+EF7KJgg3Lfu9znHoeWLmv3d4qSupynUuVgNbt_T9zpstw@mail.gmail.com>
References: <CAHR5+EF7KJgg3Lfu9znHoeWLmv3d4qSupynUuVgNbt_T9zpstw@mail.gmail.com>
Message-ID: <eb82f32b-77f1-59e0-75ad-ab6bcc897219@wisemo.com>

On 07/07/2016 20:08, Chris Bare wrote:
> EVP_get_digestbyobj fails for ecdsa-with-SHA256
>
ecdsa-with-SHA256 is not a digest algorithm, it is a signature
algorithm with a specific choice of digest algorithm (SHA256).

In OpenSSL 1.0.2 and older there is a very old compatibility
feature which allows accessing a few old signature+digest
algorithm pairs via a digest algorithm object.

Specifically:

RSA with md2, md4, md5, mdc2, ripemd, SHA-0, SHA-1, SHA224,
          SHA256, SHA384 and SHA512
DSA with SHA-0 and SHA1
ECDSA with with SHA1

This has been deprecated for a long time, but the compatibility
code makes your code below work for the above algorithm pairs.

The reason this compatibility code is deprecated is that it
causes the RSA algorithm to be referenced every time someone
tries to reference just the hash algorithm object for one of
the digest algorithms listed above.
> I'm trying to perform a standard signature verification using the 
> EVP_* functions.
> I think my code is correct, because it all runs fine if the digest is 
> RSA-SHA256.
> I have an ASN1_OBJECT that specifics the signature/disgest type.
> Here is my code that dumps out all the intermediate steps called by 
> EVP_get_digestbyobj:
>
> ASN1_OBJECT * ;
>
> OBJ_obj2txt(name, 256, sig_alg_oid, 1);
> printf ("NAME %s", name);
> printf ("NID = %d", OBJ_obj2nid(sig_alg_oid));
> printf ("sn = %s", OBJ_nid2sn(OBJ_obj2nid(sig_alg_oid)));
> printf ("OBJ_NAME_get = %p", 
> OBJ_NAME_get(OBJ_nid2sn(OBJ_obj2nid(sig_alg_oid)),OBJ_NAME_TYPE_MD_METH));
> const EVP_MD* md = EVP_get_digestbyobj(sig_alg_oid);
> if(md == NULL)
>         printf ("EVP_get_digestbyobj failed");
>
> When I call this with the RSA-SHA256 I get:
> NAME 1.2.840.113549.1.1.11
> NID = 668
> sn = RSA-SHA256
> OBJ_NAME_get = 0x7fe8846f1ee0
>
> and the rest of the steps succeeed.
> Then when I call the same code (in the same program, so I'm sure the 
> openssl library is correctly initialized) with
> ecdsa-with-SHA256, I get:
> NAME 1.2.840.10045.4.3.2
> NID = 794
> sn = ecdsa-with-SHA256
> OBJ_NAME_get = (nil)
> EVP_get_digestbyobj failed
>
> So it looks like my sig_alg_oid is good, but OBJ_NAME_get fails.
>
> I am using openssl 1.0.2d-0ubuntu1.5 in ubuntu 15.10
>
> Am I doing something wrong, or could this be a bug in the library?
> Any suggestions appreciated.

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


From chris.bare at gmail.com  Thu Jul  7 19:09:16 2016
From: chris.bare at gmail.com (Chris Bare)
Date: Thu, 7 Jul 2016 15:09:16 -0400
Subject: [openssl-users] EVP_get_digestbyobj fails for ecdsa-with-SHA256
In-Reply-To: <eb82f32b-77f1-59e0-75ad-ab6bcc897219@wisemo.com>
References: <CAHR5+EF7KJgg3Lfu9znHoeWLmv3d4qSupynUuVgNbt_T9zpstw@mail.gmail.com>
 <eb82f32b-77f1-59e0-75ad-ab6bcc897219@wisemo.com>
Message-ID: <CAHR5+EEWhb6c9WJAhqKMcjeFQek_kWnRHY17kvLJ-AuWZO7XRA@mail.gmail.com>

Ok, that makes sense with what I'm seeing. I just tried changing this:
    const EVP_MD* md = EVP_get_digestbyobj(sig_alg_oid);
to this:
    const EVP_MD* md = EVP_get_digestbyname("SHA256");

and it all worked correctly.
so given that I have an OID for ecdsa-with-SHA256, is there a function that
will return just the digest algorithm?
I'm trying to be as flexible as possible, so I don't want to hard code this
or have my own limited lookup table.

On Thu, Jul 7, 2016 at 2:54 PM, Jakob Bohm <jb-openssl at wisemo.com> wrote:

> On 07/07/2016 20:08, Chris Bare wrote:
>
>> EVP_get_digestbyobj fails for ecdsa-with-SHA256
>>
>> ecdsa-with-SHA256 is not a digest algorithm, it is a signature
> algorithm with a specific choice of digest algorithm (SHA256).
>
> In OpenSSL 1.0.2 and older there is a very old compatibility
> feature which allows accessing a few old signature+digest
> algorithm pairs via a digest algorithm object.
>
> Specifically:
>
> RSA with md2, md4, md5, mdc2, ripemd, SHA-0, SHA-1, SHA224,
>          SHA256, SHA384 and SHA512
> DSA with SHA-0 and SHA1
> ECDSA with with SHA1
>
> This has been deprecated for a long time, but the compatibility
> code makes your code below work for the above algorithm pairs.
>
> The reason this compatibility code is deprecated is that it
> causes the RSA algorithm to be referenced every time someone
> tries to reference just the hash algorithm object for one of
> the digest algorithms listed above.
>
> I'm trying to perform a standard signature verification using the EVP_*
>> functions.
>> I think my code is correct, because it all runs fine if the digest is
>> RSA-SHA256.
>> I have an ASN1_OBJECT that specifics the signature/disgest type.
>> Here is my code that dumps out all the intermediate steps called by
>> EVP_get_digestbyobj:
>>
>> ASN1_OBJECT * ;
>>
>> OBJ_obj2txt(name, 256, sig_alg_oid, 1);
>> printf ("NAME %s", name);
>> printf ("NID = %d", OBJ_obj2nid(sig_alg_oid));
>> printf ("sn = %s", OBJ_nid2sn(OBJ_obj2nid(sig_alg_oid)));
>> printf ("OBJ_NAME_get = %p",
>> OBJ_NAME_get(OBJ_nid2sn(OBJ_obj2nid(sig_alg_oid)),OBJ_NAME_TYPE_MD_METH));
>> const EVP_MD* md = EVP_get_digestbyobj(sig_alg_oid);
>> if(md == NULL)
>>         printf ("EVP_get_digestbyobj failed");
>>
>> When I call this with the RSA-SHA256 I get:
>> NAME 1.2.840.113549.1.1.11
>> NID = 668
>> sn = RSA-SHA256
>> OBJ_NAME_get = 0x7fe8846f1ee0
>>
>> and the rest of the steps succeeed.
>> Then when I call the same code (in the same program, so I'm sure the
>> openssl library is correctly initialized) with
>> ecdsa-with-SHA256, I get:
>> NAME 1.2.840.10045.4.3.2
>> NID = 794
>> sn = ecdsa-with-SHA256
>> OBJ_NAME_get = (nil)
>> EVP_get_digestbyobj failed
>>
>> So it looks like my sig_alg_oid is good, but OBJ_NAME_get fails.
>>
>> I am using openssl 1.0.2d-0ubuntu1.5 in ubuntu 15.10
>>
>> Am I doing something wrong, or could this be a bug in the library?
>> Any suggestions appreciated.
>>
>
> 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
>



-- 
Chris Bare
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160707/fa5e4683/attachment.html>

From warron.french at gmail.com  Thu Jul  7 20:36:33 2016
From: warron.french at gmail.com (Warron French)
Date: Thu, 7 Jul 2016 16:36:33 -0400
Subject: [openssl-users] When to use a key or password
Message-ID: <e89de61c-ea9d-1a93-d71d-8c5a0ccc5dfa@gmail.com>

Is there any good rule of thumb for when to use:


*-k <password>* versus

*-K <key>*

*
*

Also, what does the term IV refer to in reference to *-iv IV*?


Thanks in advance,

Warron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160707/0310768c/attachment.html>

From steve at openssl.org  Fri Jul  8 12:08:08 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 8 Jul 2016 12:08:08 +0000
Subject: [openssl-users] EVP_get_digestbyobj fails for ecdsa-with-SHA256
In-Reply-To: <CAHR5+EEWhb6c9WJAhqKMcjeFQek_kWnRHY17kvLJ-AuWZO7XRA@mail.gmail.com>
References: <CAHR5+EF7KJgg3Lfu9znHoeWLmv3d4qSupynUuVgNbt_T9zpstw@mail.gmail.com>
 <eb82f32b-77f1-59e0-75ad-ab6bcc897219@wisemo.com>
 <CAHR5+EEWhb6c9WJAhqKMcjeFQek_kWnRHY17kvLJ-AuWZO7XRA@mail.gmail.com>
Message-ID: <20160708120808.GA19877@openssl.org>

On Thu, Jul 07, 2016, Chris Bare wrote:

> Ok, that makes sense with what I'm seeing. I just tried changing this:
>     const EVP_MD* md = EVP_get_digestbyobj(sig_alg_oid);
> to this:
>     const EVP_MD* md = EVP_get_digestbyname("SHA256");
> 
> and it all worked correctly.
> so given that I have an OID for ecdsa-with-SHA256, is there a function that
> will return just the digest algorithm?
> I'm trying to be as flexible as possible, so I don't want to hard code this
> or have my own limited lookup table.
> 

OBJ_find_sigid_algs() you pass it the NID of the signature algorithm and it
reurns the public key NID and the digest NID.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From hokusai at gmx.ch  Fri Jul  8 13:32:31 2016
From: hokusai at gmx.ch (hokusai at gmx.ch)
Date: Fri, 8 Jul 2016 15:32:31 +0200
Subject: [openssl-users] ASN1 compiler
Message-ID: <trinity-d73e7678-7a20-40b4-9356-85fdbd0f036f-1467984751411@3capp-gmx-bs75>

An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160708/90a5c34e/attachment.html>

From matt at openssl.org  Fri Jul  8 13:51:14 2016
From: matt at openssl.org (Matt Caswell)
Date: Fri, 8 Jul 2016 14:51:14 +0100
Subject: [openssl-users] ASN1 compiler
In-Reply-To: <trinity-d73e7678-7a20-40b4-9356-85fdbd0f036f-1467984751411@3capp-gmx-bs75>
References: <trinity-d73e7678-7a20-40b4-9356-85fdbd0f036f-1467984751411@3capp-gmx-bs75>
Message-ID: <577FAFD2.6040107@openssl.org>



On 08/07/16 14:32, hokusai at gmx.ch wrote:
> Hi All,
>  
> Just a short question.
> Does OpenSSL project use the Objective Systems ASN1C?

A short question with an equally short answer: No.

:-)

Matt


From michel.sales at free.fr  Fri Jul  8 22:08:42 2016
From: michel.sales at free.fr (Michel)
Date: Sat, 9 Jul 2016 00:08:42 +0200
Subject: [openssl-users] When to use a key or password
In-Reply-To: <e89de61c-ea9d-1a93-d71d-8c5a0ccc5dfa@gmail.com>
References: <e89de61c-ea9d-1a93-d71d-8c5a0ccc5dfa@gmail.com>
Message-ID: <003801d1d965$4adfcbc0$e09f6340$@sales@free.fr>

Hi,

 

You need to remember a password. Passwords should never be stored.

Keys are binary data (even if they look as text because they are hexa or base64 encoded). 

Secret keys can be 'derived' from a password to be used when encrypting or decrypting.

Sometime you need to store an ENCRYPTED secret key (generally using another password).

see https://en.wikipedia.org/wiki/Key_(cryptography).

 

IV means 'Initial Vector', which is random binary data needed to 'start' encryption or decryption.

See https://en.wikipedia.org/wiki/Initialization_vector

 

Hope it helps,

Regards,

 

Michel.

 

De : openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de Warron French
Envoy? : jeudi 7 juillet 2016 22:37
? : openssl-users at openssl.org
Objet : [openssl-users] When to use a key or password

Is there any good rule of thumb for when to use:

-k <password> versus

-K <key>

Also, what does the term IV refer to in reference to -iv IV?

Thanks in advance,

Warron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160709/141af843/attachment-0001.html>

From noloader at gmail.com  Sun Jul 10 04:02:17 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Sun, 10 Jul 2016 00:02:17 -0400
Subject: [openssl-users] OpenSSL and Microsoft fork on GitHub
Message-ID: <CAH8yC8nQ35c5Ouk=RsZk7yzThzokyRmWth_DQVjetLZWA_+35w@mail.gmail.com>

Hi Everyone,

This just made my radar... Microsoft has a fork of OpenSSL at
http://github.com/Microsoft/openssl . It looks like it is actively
maintained.

Jeff

From warron.french at gmail.com  Sun Jul 10 04:25:53 2016
From: warron.french at gmail.com (Warron French)
Date: Sun, 10 Jul 2016 00:25:53 -0400
Subject: [openssl-users] When to use a key or password
In-Reply-To: <5780249a.43b2c20a.72acc.7780SMTPIN_ADDED_BROKEN@mx.google.com>
References: <e89de61c-ea9d-1a93-d71d-8c5a0ccc5dfa@gmail.com>
 <5780249a.43b2c20a.72acc.7780SMTPIN_ADDED_BROKEN@mx.google.com>
Message-ID: <48198a07-ce86-b4b7-848d-493d2098b407@gmail.com>

Michel, merci beaucoup, for the explanation.

It does clear things up for me.  I appreciate it,

Warron

On 7/8/2016 6:08 PM, Michel wrote:
>
> Hi,
>
> You need to remember a password. Passwords should never be stored.
>
> Keys are binary data (even if they look as text because they are hexa 
> or base64 encoded).
>
> Secret keys can be 'derived' from a password to be used when 
> encrypting or decrypting.
>
> Sometime you need to store an ENCRYPTED secret key (generally using 
> another password).
>
> see https://en.wikipedia.org/wiki/Key_(cryptography) 
> <https://en.wikipedia.org/wiki/Key_%28cryptography%29>.
>
> IV means 'Initial Vector', which is random binary data needed to 
> 'start' encryption or decryption.
>
> See https://en.wikipedia.org/wiki/Initialization_vector
>
> Hope it helps,
>
> Regards,
>
> Michel.
>
> *De :*openssl-users [mailto:openssl-users-bounces at openssl.org] *De la 
> part de* Warron French
> *Envoy? :* jeudi 7 juillet 2016 22:37
> *? :* openssl-users at openssl.org
> *Objet :* [openssl-users] When to use a key or password
>
> Is there any good rule of thumb for when to use:
>
> *-k <password>* versus
>
> *-K <key>*
>
> Also, what does the term IV refer to in reference to *-iv IV*?
>
> Thanks in advance,
>
> Warron
>
>
>

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

From stevem at openssl.org  Mon Jul 11 11:46:54 2016
From: stevem at openssl.org (Steve Marquess)
Date: Mon, 11 Jul 2016 07:46:54 -0400
Subject: [openssl-users] wiki spam
Message-ID: <5783872E.605@openssl.org>

The OpenSSL wiki has recently attracted the attention of some spammers
who requested accounts and provided what initially appeared to be
reasonable justifications (which we now suspect were just clever
cut-and-paste edits of CVs found online). I wish they could put half as
much effort into improving OpenSSL as they did to vandalizing it.

We're repaired the damage (if I missed any please sing out). We're
obviously going to have to be more careful about creating new accounts
in the future. We have received a flurry of requests in the past few
days that due to timing and other clues I won't mention appear to be a
continuation of the spamming. We are ignoring them.

If you are a legitimate OpenSSL user who made such a request, please
keep that in mind and try again in a week or so. The last thing we want
to do is discourage legitimate participation. On the other hand,
cleaning up the spam is tedious so please note that going forward we'll
need better evidence that new contributors are real OpenSSL users. How
we do that we'll need to figure out as we go; please bear with us.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation
20-22 Wenlock Road
London N1 7GU
United Kingdom
+44 1785508015
+1 301 874 2571 direct
marquess at opensslfoundation.org
stevem at openssl.org

From Ryan.Pfeifle at nice.com  Mon Jul 11 18:39:53 2016
From: Ryan.Pfeifle at nice.com (Ryan Pfeifle)
Date: Mon, 11 Jul 2016 11:39:53 -0700
Subject: [openssl-users] OpenSSL and Microsoft fork on GitHub
In-Reply-To: <1d60d70d-94f4-4ac7-aa3e-ccc3896f424a@openssl.org>
References: <1d60d70d-94f4-4ac7-aa3e-ccc3896f424a@openssl.org>
Message-ID: <65F4BC02FEB6AB43BF582425A3915E7B040F2643B50F@omega>

Google has their own (stripped down) fork as well, and they were not quiet about it, either:

https://boringssl.googlesource.com/boringssl/

http://arstechnica.com/security/2014/06/google-unveils-independent-fork-of-openssl-called-boringssl/

https://www.imperialviolet.org/2015/10/17/boringssl.html





Ryan Pfeifle
Software Engineer, VPI


Tel: 1.805.389.5200 x5297      |
Ryan.Pfeifle at nice.com | www.VPI-corp.com

VPI is now part of NICE Systems.

The information transmitted in this message is intended only for the addressee and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete this material from any computer.
-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jeffrey Walton
Sent: Saturday, July 09, 2016 9:02 PM
To: OpenSSL Users
Subject: [openssl-users] OpenSSL and Microsoft fork on GitHub

Hi Everyone,

This just made my radar... Microsoft has a fork of OpenSSL at http://github.com/Microsoft/openssl . It looks like it is actively maintained.

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

From rsalz at akamai.com  Mon Jul 11 18:41:40 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 11 Jul 2016 18:41:40 +0000
Subject: [openssl-users] OpenSSL and Microsoft fork on GitHub
In-Reply-To: <65F4BC02FEB6AB43BF582425A3915E7B040F2643B50F@omega>
References: <1d60d70d-94f4-4ac7-aa3e-ccc3896f424a@openssl.org>
 <65F4BC02FEB6AB43BF582425A3915E7B040F2643B50F@omega>
Message-ID: <3324148e9c874687ad313ce1a80f8e0f@usma1ex-dag1mb1.msg.corp.akamai.com>

We (openssl team) work pretty closely with the boringSSL folks.  We're reaching out to MSFT to hopefully do the same.

From df7729 at gmail.com  Tue Jul 12 04:05:10 2016
From: df7729 at gmail.com (David F.)
Date: Mon, 11 Jul 2016 21:05:10 -0700
Subject: [openssl-users] Minimum openssl configuration for ssl/tls smtp
	email support?
Message-ID: <CAGRSmLs5S3Y4fcQ+58_7BqX41Gna5zHHh7DzAO1ZNm+UZtccqQ@mail.gmail.com>

Hi,

What configuration parameters (NO-XXX) should be passed for the
openssl library to be built to support standard TLS/SSL required for
sending emails through the public smtp servers but at the least amount
of code needed.    I have it working (only calls a few BIO_ and/or
SSL_ functions) but adds 1MiB+ to the program .exe size.   I'd like to
get that down to less than 200K (other libraries claim to do it under
50K).

Thanks.

From dssengar at gmail.com  Tue Jul 12 08:55:00 2016
From: dssengar at gmail.com (Devendra Sengar)
Date: Tue, 12 Jul 2016 14:25:00 +0530
Subject: [openssl-users] Facing issue while configuring SSL
Message-ID: <CAJ88ud=RFD5-F4BoyauK31V=iOfh=zyFRvp0TEhJYUq-e=_bQw@mail.gmail.com>

Hi,

This is regarding the configuration of Tomcat SSL using the APR library on
Java 6.

While starting the server I am getting the below error:

SEVERE: Failed to initialize end point associated with ProtocolHandler
["http-apr-443"]
java.lang.Exception: Unable to load certificate key conf/localhost-key.pem
(error:02001003:system library:fopen:No such process)

I am trying to implement SSL using independent libraries for OpenSSL,
Tomcat Native and Apache Portable Runtime.

I have downloaded precompiled versions of OpenSSL and Tomcat Native (see
them attached). I have tried compiling the Apache Portable Runtime using
Visual Studio (find it also attached).

I am running those libraries on either Tomcat 7.0.6 or 7.0.70 64-bit for
Windows (using the 64-bit distro, not the installer one).

We are restricted by our applicatioin to use Oracle Java 6 Updated 115
64-bit.

The versions of the libraries I am using are the latest available online,
again see the binaries attached.

The parameters used in the server.xml file are:

For Tomcat 7.0.6:
<Connector
   protocol="org.apache.coyote.http11.Http11AprProtocol"
   port="443" maxThreads="200"
   scheme="https" secure="true" SSLEnabled="true"
   SSLCertificateFile="conf/localhost-cert.pem"
   SSLCertificateKeyFile="conf/localhost-key.pem"
   SSLCertificateChainFile="conf/ca.crt"
   SSLVerifyClient="optional" SSLProtocol="TLSv1"
   SSLCipherSuite="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"/>

For Tomcat 7.0.70

<Connector
   protocol="org.apache.coyote.http11.Http11AprProtocol"
   port="443" maxThreads="200"
   scheme="https" secure="true" SSLEnabled="true"
   SSLCertificateFile="conf/localhost-cert.pem"
   SSLCertificateKeyFile="conf/localhost-key.pem"
   SSLCertificateChainFile="conf/ca.crt"
   SSLVerifyClient="optional" SSLProtocol="TLSv1_2"
   SSLCipherSuite="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"/>

The library files are in the tomcat bin folder as openssl.exe,
tcnative-1.dll and libapr-1.dll.

tcnative-1.dll:
https://drive.google.com/file/d/0ByilOlQCXOkWQ1ZCckhodHBvQk0/view?usp=sharing
openssl.exe:
https://drive.google.com/file/d/0ByilOlQCXOkWQk9KUUJSb3ZqeW8/view?usp=sharing
libapr-1.dll:
https://drive.google.com/file/d/0ByilOlQCXOkWV09NTi0tNWxhZnM/view?usp=sharing


The same certificates files mentioned in the server.xml file were used and
work in a brand new Apache web server.

Please let us know your opinion of what can cause those errors?

Can it be because of a APR dll not compiled properly?

Any other idea?

Thanks,
Devendra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160712/b5a24ddb/attachment-0001.html>

From darshanmody at avaya.com  Tue Jul 12 09:15:42 2016
From: darshanmody at avaya.com (Mody, Darshan (Darshan))
Date: Tue, 12 Jul 2016 09:15:42 +0000
Subject: [openssl-users] Difference between re-negotiate APIs
Message-ID: <25D2EC755404B4409F263AC6D050FEBB25E256FE@AZ-FFEXMB03.global.avaya.com>

Hi

I find there are 2 APIs for SSL renegotiation. SSL_renegotiate and SSL_renegotiate_abbreviate.

What is the difference between them?

Thanks
Darshan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160712/585c8e20/attachment.html>

From jb-openssl at wisemo.com  Tue Jul 12 09:42:13 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 12 Jul 2016 11:42:13 +0200
Subject: [openssl-users] Facing issue while configuring SSL
In-Reply-To: <CAJ88ud=RFD5-F4BoyauK31V=iOfh=zyFRvp0TEhJYUq-e=_bQw@mail.gmail.com>
References: <CAJ88ud=RFD5-F4BoyauK31V=iOfh=zyFRvp0TEhJYUq-e=_bQw@mail.gmail.com>
Message-ID: <b423862d-edfd-cc60-f3cb-db70639865b2@wisemo.com>

On 12/07/2016 10:55, Devendra Sengar wrote:
> Hi,
>
> This is regarding the configuration of Tomcat SSL using the APR 
> library on Java 6.
>
> While starting the server I am getting the below error:
>
> SEVERE: Failed to initialize end point associated with ProtocolHandler 
> ["http-apr-443"]
> java.lang.Exception: Unable to load certificate key 
> conf/localhost-key.pem (error:02001003:system library:fopen:No such 
> process)
>
Not sure if Tomcat is using OpenSSL or not...

> I am trying to implement SSL using independent libraries for OpenSSL, 
> Tomcat Native and Apache Portable Runtime.
>
> I have downloaded precompiled versions of OpenSSL and Tomcat Native 
> (see them attached). I have tried compiling the Apache Portable 
> Runtime using Visual Studio (find it also attached).
>
> I am running those libraries on either Tomcat 7.0.6 or 7.0.70 64-bit 
> for Windows (using the 64-bit distro, not the installer one).
>
> We are restricted by our applicatioin to use Oracle Java 6 Updated 115 
> 64-bit.
>
That is really unfortunate, given that I don't think there
are current security updates for Java 1.6 (maybe there is
if you pay Oracle for an expensive license/subscription).

> The versions of the libraries I am using are the latest available 
> online, again see the binaries attached.
>
> The parameters used in the server.xml file are:
>
> For Tomcat 7.0.6:
> <Connector
> protocol="org.apache.coyote.http11.Http11AprProtocol"
> port="443" maxThreads="200"
> scheme="https" secure="true" SSLEnabled="true"
> SSLCertificateFile="conf/localhost-cert.pem"
> SSLCertificateKeyFile="conf/localhost-key.pem"
> SSLCertificateChainFile="conf/ca.crt"
> SSLVerifyClient="optional" SSLProtocol="TLSv1"
> SSLCipherSuite="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"/>
>
> For Tomcat 7.0.70
>
> <Connector
> protocol="org.apache.coyote.http11.Http11AprProtocol"
> port="443" maxThreads="200"
> scheme="https" secure="true" SSLEnabled="true"
> SSLCertificateFile="conf/localhost-cert.pem"
> SSLCertificateKeyFile="conf/localhost-key.pem"
> SSLCertificateChainFile="conf/ca.crt"
> SSLVerifyClient="optional" SSLProtocol="TLSv1_2"
> SSLCipherSuite="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"/>
>
> The library files are in the tomcat bin folder as openssl.exe, 
> tcnative-1.dll and libapr-1.dll.
>
> tcnative-1.dll: 
> https://drive.google.com/file/d/0ByilOlQCXOkWQ1ZCckhodHBvQk0/view?usp=sharing
> openssl.exe: 
> https://drive.google.com/file/d/0ByilOlQCXOkWQk9KUUJSb3ZqeW8/view?usp=sharing
> libapr-1.dll: 
> https://drive.google.com/file/d/0ByilOlQCXOkWV09NTi0tNWxhZnM/view?usp=sharing
>
openssl.exe is not the library, it is a command line tool for
doing various things (such as requesting certificates, converting
key file formats etc.)

The library consists of two files with .dll file extension,
libeay32.dll for basic crypto and ssleay32.dll for the actual
SSL/TLS code.

>
> The same certificates files mentioned in the server.xml file were used 
> and work in a brand new Apache web server.
>
> Please let us know your opinion of what can cause those errors?
>
> Can it be because of a APR dll not compiled properly?
>
> Any other idea?
>

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/20160712/0f24eca8/attachment.html>

From dssengar at gmail.com  Tue Jul 12 13:18:37 2016
From: dssengar at gmail.com (Devendra Sengar)
Date: Tue, 12 Jul 2016 18:48:37 +0530
Subject: [openssl-users] Facing issue while configuring SSL
In-Reply-To: <b423862d-edfd-cc60-f3cb-db70639865b2@wisemo.com>
References: <CAJ88ud=RFD5-F4BoyauK31V=iOfh=zyFRvp0TEhJYUq-e=_bQw@mail.gmail.com>
 <b423862d-edfd-cc60-f3cb-db70639865b2@wisemo.com>
Message-ID: <CAJ88udkL9i2yVCYDJyRtfXTwtt4=igSztJETY65-nuxELQ5GJQ@mail.gmail.com>

Hi,

Even i tried after putting the libeay32.dll and ssleay32.dll after
downloading from the sites like https://indy.fulgan.com/SSL/
But still i am getting the same error:

SEVERE: Failed to initialize end point associated with ProtocolHandler
["http-apr-443"]
java.lang.Exception: Unable to load certificate key conf/localhost-key.pem
(error:02001003:system library:fopen:No such process)

Even tried after putting the Apache Web server dll's just to test but that
also not work as for apache everything is working so just randomly test it.

Any other suggestion?

Thanks,
Devendra

On Tue, Jul 12, 2016 at 3:12 PM, Jakob Bohm <jb-openssl at wisemo.com> wrote:

> On 12/07/2016 10:55, Devendra Sengar wrote:
>
> Hi,
>
> This is regarding the configuration of Tomcat SSL using the APR library on
> Java 6.
>
> While starting the server I am getting the below error:
>
> SEVERE: Failed to initialize end point associated with ProtocolHandler
> ["http-apr-443"]
> java.lang.Exception: Unable to load certificate key conf/localhost-key.pem
> (error:02001003:system library:fopen:No such process)
>
> Not sure if Tomcat is using OpenSSL or not...
>
> I am trying to implement SSL using independent libraries for OpenSSL,
> Tomcat Native and Apache Portable Runtime.
>
> I have downloaded precompiled versions of OpenSSL and Tomcat Native (see
> them attached). I have tried compiling the Apache Portable Runtime using
> Visual Studio (find it also attached).
>
> I am running those libraries on either Tomcat 7.0.6 or 7.0.70 64-bit for
> Windows (using the 64-bit distro, not the installer one).
>
> We are restricted by our applicatioin to use Oracle Java 6 Updated 115
> 64-bit.
>
> That is really unfortunate, given that I don't think there
> are current security updates for Java 1.6 (maybe there is
> if you pay Oracle for an expensive license/subscription).
>
>
> The versions of the libraries I am using are the latest available online,
> again see the binaries attached.
>
> The parameters used in the server.xml file are:
>
> For Tomcat 7.0.6:
> <Connector
>    protocol="org.apache.coyote.http11.Http11AprProtocol"
>    port="443" maxThreads="200"
>    scheme="https" secure="true" SSLEnabled="true"
>    SSLCertificateFile="conf/localhost-cert.pem"
>    SSLCertificateKeyFile="conf/localhost-key.pem"
>    SSLCertificateChainFile="conf/ca.crt"
>    SSLVerifyClient="optional" SSLProtocol="TLSv1"
>    SSLCipherSuite="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"/>
>
> For Tomcat 7.0.70
>
> <Connector
>    protocol="org.apache.coyote.http11.Http11AprProtocol"
>    port="443" maxThreads="200"
>    scheme="https" secure="true" SSLEnabled="true"
>    SSLCertificateFile="conf/localhost-cert.pem"
>    SSLCertificateKeyFile="conf/localhost-key.pem"
>    SSLCertificateChainFile="conf/ca.crt"
>    SSLVerifyClient="optional" SSLProtocol="TLSv1_2"
>    SSLCipherSuite="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"/>
>
> The library files are in the tomcat bin folder as openssl.exe,
> tcnative-1.dll and libapr-1.dll.
>
> tcnative-1.dll:
> https://drive.google.com/file/d/0ByilOlQCXOkWQ1ZCckhodHBvQk0/view?usp=sharing
> openssl.exe:
> https://drive.google.com/file/d/0ByilOlQCXOkWQk9KUUJSb3ZqeW8/view?usp=sharing
> libapr-1.dll:
> https://drive.google.com/file/d/0ByilOlQCXOkWV09NTi0tNWxhZnM/view?usp=sharing
>
> openssl.exe is not the library, it is a command line tool for
> doing various things (such as requesting certificates, converting
> key file formats etc.)
>
> The library consists of two files with .dll file extension,
> libeay32.dll for basic crypto and ssleay32.dll for the actual
> SSL/TLS code.
>
>
> The same certificates files mentioned in the server.xml file were used and
> work in a brand new Apache web server.
>
> Please let us know your opinion of what can cause those errors?
>
> Can it be because of a APR dll not compiled properly?
>
> Any other idea?
>
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160712/602dfcd8/attachment-0001.html>

From jonetsu at teksavvy.com  Tue Jul 12 14:11:01 2016
From: jonetsu at teksavvy.com (jonetsu)
Date: Tue, 12 Jul 2016 10:11:01 -0400
Subject: [openssl-users] FIPS canister 2.0.12 and 186-4
Message-ID: <c928e9996b8a4d95e86e7c6492461b27@teksavvy.com>

Hello,

Does 2.0.12 support 186-4 ?? Specifically, does it support the RSA requirements? ?

Thanks.




From c.holper at ades.at  Tue Jul 12 15:47:51 2016
From: c.holper at ades.at (c.holper at ades.at)
Date: Tue, 12 Jul 2016 17:47:51 +0200
Subject: [openssl-users] GCM cipher decryption
Message-ID: <c642c569-2765-f8b2-3b2d-402cbf56eab0@ades.at>

Hi!

2 questions about GCM and the following OpenSSL-Sample please.

https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption#Authenticated_Decryption_using_GCM_mode

and the function

int decrypt(unsigned char *ciphertext, int ciphertext_len, unsigned char 
*aad, int aad_len, unsigned char *tag, unsigned char *key, unsigned char 
*iv, unsigned char *plaintext)


* Is ciphertext the pure ciperhtext OR
is it with IV and TAG still in the string??

* If the 2nd: The IV is expected to be in front of the ciphertext and 
the TAG is expected to be past of the ciphertext - correct?
| IV | ciphertext | TAG |

thanks!
Christoph

From swall at redcom.com  Tue Jul 12 18:11:56 2016
From: swall at redcom.com (Wall, Stephen)
Date: Tue, 12 Jul 2016 14:11:56 -0400
Subject: [openssl-users] FIPS canister 2.0.12 and 186-4
In-Reply-To: <c928e9996b8a4d95e86e7c6492461b27@teksavvy.com>
References: <c928e9996b8a4d95e86e7c6492461b27@teksavvy.com>
Message-ID: <401084E5E73F4241A44F3C9E6FD79428037C48EE6D@exch-01>

> Does 2.0.12 support 186-4 ?  Specifically, does it support the RSA
> requirements  ?

No.

From michel.sales at free.fr  Tue Jul 12 21:27:06 2016
From: michel.sales at free.fr (Michel)
Date: Tue, 12 Jul 2016 23:27:06 +0200
Subject: [openssl-users] GCM cipher decryption
In-Reply-To: <c642c569-2765-f8b2-3b2d-402cbf56eab0@ades.at>
References: <c642c569-2765-f8b2-3b2d-402cbf56eab0@ades.at>
Message-ID: <000601d1dc84$247adac0$6d709040$@sales@free.fr>

Hi,

Quick answer : as you probably noticed, IV, ciphertext and tag are expected
to be distinct buffers.
Consequently, ciphertext is just ciphertext (without IV or Tag).

Regards,

Michel.

-----Message d'origine-----
De?: openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de
c.holper at ades.at
Envoy??: mardi 12 juillet 2016 17:48
??: openssl-users at openssl.org
Objet?: [openssl-users] GCM cipher decryption

Hi!

2 questions about GCM and the following OpenSSL-Sample please.

https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decrypti
on#Authenticated_Decryption_using_GCM_mode

and the function

int decrypt(unsigned char *ciphertext, int ciphertext_len, unsigned char
*aad, int aad_len, unsigned char *tag, unsigned char *key, unsigned char
*iv, unsigned char *plaintext)

* Is ciphertext the pure ciperhtext OR
is it with IV and TAG still in the string??

* If the 2nd: The IV is expected to be in front of the ciphertext and the
TAG is expected to be past of the ciphertext - correct?
| IV | ciphertext | TAG |

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


From c.holper at ades.at  Wed Jul 13 12:36:19 2016
From: c.holper at ades.at (c.holper at ades.at)
Date: Wed, 13 Jul 2016 14:36:19 +0200
Subject: [openssl-users]  GCM cipher decryption
Message-ID: <b5482b8f-941a-9354-a01b-5591475dab44@ades.at>

Thanks!
It works.

Chris

From nikhil.agarwal at nxp.com  Wed Jul 13 10:05:51 2016
From: nikhil.agarwal at nxp.com (Nikhil Agarwal)
Date: Wed, 13 Jul 2016 10:05:51 +0000
Subject: [openssl-users] HMAC with Engine support
Message-ID: <DB5PR04MB1655C1EA9CF2B8212D51533F93310@DB5PR04MB1655.eurprd04.prod.outlook.com>

Hi All,

Is there any way in OPENSSL so that it can offload HMAC operation directly to engine.  As far as I understood from code, OPENSSL generates ipad/opad internally and uses engine only for HASH functions. Please suggest. I need this as the keys that are being used for this operation are blackened by HW Crypto engine and now only HW can use these keys.

Thanks in Advance
Nikhil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160713/3e8bdd76/attachment.html>

From svineet at kodiakptt.com  Fri Jul 15 07:43:13 2016
From: svineet at kodiakptt.com (Vineet Kumar Srivastava)
Date: Fri, 15 Jul 2016 07:43:13 +0000
Subject: [openssl-users] Getting SSL_ERROR_SYSCALL for an incoming DTLS
 Connection on an existing DTLS Connection on the same port
Message-ID: <BY1PR10MB0311142BE4A5A97153C7742FB0330@BY1PR10MB0311.namprd10.prod.outlook.com>

Hi,
  On an existing DTLS connection i.e. DTLS handshake already done successfully on port 5000 if server gets an incoming DTLS Connection i.e. DTLS Client Hello packet then SSL_read is generating SSL_ERROR_SYSCALL.
  Can anyone give me a clue as to why.
  Scenario is that Client had established a DTLS connection with server on port 5000 of server. IP address of client changes may be due to transition from Wi-Fi to 3G or vice-versa. So, now Client will again try to establish DTLS connection with server on same port 5000 of server.
  Please anyone let me know as to
Q1. why SSL_read is generating the error SSL_ERROR_SYSCALL and what can be done to proceed ?
Q2. Whether we can handle another incoming DTLS connection on an existing DTLS Connection on the same port without cleaning-up the already existing DTLS connection ?

Thanks in advance for the help,
Vineet Srivastava
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160715/6e88e94a/attachment-0001.html>

From shaiquantz at gmail.com  Fri Jul 15 13:46:24 2016
From: shaiquantz at gmail.com (Shai Quantz)
Date: Fri, 15 Jul 2016 16:46:24 +0300
Subject: [openssl-users] rejection message from i Tune
Message-ID: <CACCCibu7YJM_QC6nQe7Atw_+LKfyLdP2ygoMyKmN86kweecRrA@mail.gmail.com>

Hi,

I get this rejection message from i Tune:
---------------------------------------------------
Dear developer,
We have discovered one or more issues with your recent delivery for "Hebrew
Tutor". To process your delivery, the following issues must be corrected:
Invalid Signature - The binary with bundle identifier
'com.jewishsoftware.hebrewtutor' at path [Hebrew-Tutor.app] contains an
invalid signature. Make sure you have signed your application with a
distribution certificate, not an ad hoc certificate or a development
certificate. Verify that the code signing settings in Xcode are correct at
the target level (which override any values at the project level). If you
are certain your code signing settings are correct, choose "Clean All" in
Xcode, delete the "build" directory in the Finder, and rebuild your release
target.
----------------------------------------
I created my distribution certificate with openSSL, was working fine in the
past, but now there is this problem, even though I did everything good, and
checked my self over and over, but I can't get a good distribution
certificate, if the error message is correct. When I create a developer
certificate it works fine, the same process more or less, still
Distribution certificate just will not work. maybe I can send you the
distribution certificate, I make a ios_distribution.pem file and then a p12
file to use on windows with the platform I work with which is Flash Builder
4.6

Regards,
Shai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160715/30c532d3/attachment.html>

From jb-openssl at wisemo.com  Fri Jul 15 13:56:30 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 15 Jul 2016 15:56:30 +0200
Subject: [openssl-users] rejection message from i Tune
In-Reply-To: <CACCCibu7YJM_QC6nQe7Atw_+LKfyLdP2ygoMyKmN86kweecRrA@mail.gmail.com>
References: <CACCCibu7YJM_QC6nQe7Atw_+LKfyLdP2ygoMyKmN86kweecRrA@mail.gmail.com>
Message-ID: <3b70c763-9984-73d4-df09-6a1ddfa0a205@wisemo.com>

Maybe Apple changed their technical checks.

I think (I haven't checked in detail) that the contract rules
for uploading probably say that the certificate *must* be
created with XCode and not some other tool.

On 15/07/2016 15:46, Shai Quantz wrote:
>
> Hi,
>
> I get this rejection message from i Tune:
> ---------------------------------------------------
> Dear developer,
> We have discovered one or more issues with your recent delivery for 
> "Hebrew Tutor". To process your delivery, the following issues must be 
> corrected:
> Invalid Signature - The binary with bundle identifier 
> 'com.jewishsoftware.hebrewtutor' at path [Hebrew-Tutor.app] contains 
> an invalid signature. Make sure you have signed your application with 
> a distribution certificate, not an ad hoc certificate or a development 
> certificate. Verify that the code signing settings in Xcode are 
> correct at the target level (which override any values at the project 
> level). If you are certain your code signing settings are correct, 
> choose "Clean All" in Xcode, delete the "build" directory in the 
> Finder, and rebuild your release target.
> ----------------------------------------
> I created my distribution certificate with openSSL, was working fine 
> in the past, but now there is this problem, even though I did 
> everything good, and checked my self over and over, but I can't get a 
> good distribution certificate, if the error message is correct. When I 
> create a developer certificate it works fine, the same process more or 
> less, still Distribution certificate just will not work. maybe I can 
> send you the distribution certificate, I make a ios_distribution.pem 
> file and then a p12 file to use on windows with the platform I work 
> with which is Flash Builder 4.6
>
>

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


From abhilashkv at gmail.com  Sun Jul 17 10:35:29 2016
From: abhilashkv at gmail.com (Abhilash K.V)
Date: Sun, 17 Jul 2016 14:35:29 +0400
Subject: [openssl-users] Regarding Signature Algorithm: ecdsa-with-SHA512
Message-ID: <CAACZ9ZF9vj7gA54RFb_D7oqPJkLeBhuSVt==ALUSNQqVhjNsdQ@mail.gmail.com>

Hi ,



I am trying to generate a CSR using EC and wanted to have signature
algorithm as ?ecdsa-with-SHA512?.

But in the generated csr I am getting signature algorithms as ?Signature
Algorithm: ecdsa-with-SHA1? always.



Open ssl version : 1.0.1



It would be great if you can help me on this.



Code below:



int generate_csr()

{

    EVP_PKEY *privkey;



    if ((privkey = EVP_PKEY_new()) == NULL) {

        printf("Cannot allocate memory for private key.\n");

        exit(1);

    }



    EC_KEY *eckey;





    printf("Generating ECC keypair...\n");

    eckey = EC_KEY_new();

    if (NULL == eckey) {

        printf("Failed to create new EC Key\n");

        return -1;

    }



    EC_GROUP *ecgroup = EC_GROUP_new_by_curve_name(NID_secp521r1);

    if (NULL == ecgroup) {

        printf("Failed to create new EC Group\n");

        return -1;

    }



    int set_group_status = EC_KEY_set_group(eckey, ecgroup);

    const int set_group_success = 1;

    if (set_group_success != set_group_status) {

        printf("Failed to set group for EC Key\n");

        return -1;

    }





    if (!EC_KEY_generate_key(eckey)) {

        printf("Failed to generate EC Key\n");

        exit(1);

    }



    if (!EVP_PKEY_assign_EC_KEY(privkey, eckey)) {

        printf("Cannot assign keypair to private key.\n");

        exit(1);

    }



    X509_REQ *req;

    if ((req = X509_REQ_new()) == NULL) {

        printf("Cannot allocate memory for certificate request.\n");

        exit(1);

    }



    X509_NAME * name;

    name = X509_REQ_get_subject_name(req);

    X509_NAME_add_entry_by_txt(name, "CN", MBSTRING_ASC, (unsigned char *)
"alice", -1, -1, 0);

    X509_NAME_add_entry_by_txt(name, "emailAddress", MBSTRING_ASC, (unsigned
char *)"alice at darkmatter.ae", -1, -1, 0);



    X509_REQ_set_pubkey(req, privkey);

    if (!X509_REQ_sign(req, privkey, EVP_ecdsa())) {

        printf("Cannot sign request.\n");

        exit(1);

    }







    const char *keyfn = "/Users/abhilash/test/csr_sample/tempkey.der";

    const char *csrfn = "/Users/abhilash/test/csr_sample/tempcsr.der";

    // write to files ...

    FILE * f;

    f = fopen(keyfn, "w");



    i2d_PrivateKey_fp(f, privkey);



    fclose(f);

    f = fopen(csrfn, "w");

    i2d_X509_REQ_fp(f, req);

    fclose(f);

    return 0;

}





Thanks,

Abhilash.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160717/521b2408/attachment.html>

From shaiquantz at gmail.com  Sun Jul 17 15:12:54 2016
From: shaiquantz at gmail.com (Shai Quantz)
Date: Sun, 17 Jul 2016 18:12:54 +0300
Subject: [openssl-users] rejection message from i Tune
In-Reply-To: <3b70c763-9984-73d4-df09-6a1ddfa0a205@wisemo.com>
References: <CACCCibu7YJM_QC6nQe7Atw_+LKfyLdP2ygoMyKmN86kweecRrA@mail.gmail.com>
 <3b70c763-9984-73d4-df09-6a1ddfa0a205@wisemo.com>
Message-ID: <CACCCibvjdb0Gvcj2fyRT6f0Q6TJiP7bLnqhKGg-yim2YYqX5fw@mail.gmail.com>

Thank you very much

2016-07-15 16:56 GMT+03:00 Jakob Bohm <jb-openssl at wisemo.com>:

> Maybe Apple changed their technical checks.
>
> I think (I haven't checked in detail) that the contract rules
> for uploading probably say that the certificate *must* be
> created with XCode and not some other tool.
>
> On 15/07/2016 15:46, Shai Quantz wrote:
>
>>
>> Hi,
>>
>> I get this rejection message from i Tune:
>> ---------------------------------------------------
>> Dear developer,
>> We have discovered one or more issues with your recent delivery for
>> "Hebrew Tutor". To process your delivery, the following issues must be
>> corrected:
>> Invalid Signature - The binary with bundle identifier
>> 'com.jewishsoftware.hebrewtutor' at path [Hebrew-Tutor.app] contains an
>> invalid signature. Make sure you have signed your application with a
>> distribution certificate, not an ad hoc certificate or a development
>> certificate. Verify that the code signing settings in Xcode are correct at
>> the target level (which override any values at the project level). If you
>> are certain your code signing settings are correct, choose "Clean All" in
>> Xcode, delete the "build" directory in the Finder, and rebuild your release
>> target.
>> ----------------------------------------
>> I created my distribution certificate with openSSL, was working fine in
>> the past, but now there is this problem, even though I did everything good,
>> and checked my self over and over, but I can't get a good distribution
>> certificate, if the error message is correct. When I create a developer
>> certificate it works fine, the same process more or less, still
>> Distribution certificate just will not work. maybe I can send you the
>> distribution certificate, I make a ios_distribution.pem file and then a p12
>> file to use on windows with the platform I work with which is Flash Builder
>> 4.6
>>
>>
>>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160717/10a48ca8/attachment-0001.html>

From steve at openssl.org  Sun Jul 17 16:05:35 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Sun, 17 Jul 2016 16:05:35 +0000
Subject: [openssl-users] Regarding Signature Algorithm: ecdsa-with-SHA512
In-Reply-To: <CAACZ9ZF9vj7gA54RFb_D7oqPJkLeBhuSVt==ALUSNQqVhjNsdQ@mail.gmail.com>
References: <CAACZ9ZF9vj7gA54RFb_D7oqPJkLeBhuSVt==ALUSNQqVhjNsdQ@mail.gmail.com>
Message-ID: <20160717160535.GA28032@openssl.org>

On Sun, Jul 17, 2016, Abhilash K.V wrote:

> I am trying to generate a CSR using EC and wanted to have signature
> algorithm as ???ecdsa-with-SHA512???.
> 
> But in the generated csr I am getting signature algorithms as ???Signature
> Algorithm: ecdsa-with-SHA1??? always.
> 
> 
>     if (!X509_REQ_sign(req, privkey, EVP_ecdsa())) {
> 

Don't use EVP_ecdsa() it is an old "linked digest" which uses SHA1 and is only
retained for compatibility with old code. Use EVP_sha512() instead.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From Michal.Trojnara at stunnel.org  Sun Jul 17 22:16:42 2016
From: Michal.Trojnara at stunnel.org (=?UTF-8?Q?Micha=c5=82_Trojnara?=)
Date: Mon, 18 Jul 2016 00:16:42 +0200
Subject: [openssl-users] stunnel 5.35 released
Message-ID: <578C03CA.4090507@stunnel.org>

Dear Users,

I have released version 5.35 of stunnel.

The ChangeLog entry:
Version 5.35, 2016.07.18, urgency: HIGH
* Bugfixes
  - Fixed incorrectly enforced client certificate requests.
  - Only default to SO_EXCLUSIVEADDRUSE on Vista and later.
  - Fixed thread safety of the configuration file reopening.

Home page: https://www.stunnel.org/
Download:  https://www.stunnel.org/downloads.html

SHA-256 hashes:
ffa386ae4c825f35f35157c285e7402a6d58779ad8c3822f74a9d355b54aba1d
stunnel-5.35.tar.gz
36e70e109d0283cd55c416eb261234f4c1b165409e1805df369bc774551f965c
stunnel-5.35-installer.exe
e671a4716fd36bde67850cdb5d17f54ee32b6afec9ad4ea6825d00f72a741cc5
stunnel-5.35-android.zip

Best regards,
    Mike

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160718/fefc5052/attachment.sig>

From abhilashkv at gmail.com  Mon Jul 18 03:34:32 2016
From: abhilashkv at gmail.com (Abhilash K.V)
Date: Mon, 18 Jul 2016 07:34:32 +0400
Subject: [openssl-users] Regarding Signature Algorithm: ecdsa-with-SHA512
In-Reply-To: <20160717160535.GA28032@openssl.org>
References: <CAACZ9ZF9vj7gA54RFb_D7oqPJkLeBhuSVt==ALUSNQqVhjNsdQ@mail.gmail.com>
 <20160717160535.GA28032@openssl.org>
Message-ID: <CAACZ9ZH6EHwpo=7evrKC8fiE7_S1SbGW+RBWyoknHEoK2TnjSA@mail.gmail.com>

Hi Steve,

Thanks for the information I was not aware of that.

Yes, did that modification and now I am getting it as following (I passed
EVP_sha512()).

Signature Algorithm: ecdsa-with-SHA256

Thanks,
Abhilash.

On Sun, Jul 17, 2016 at 8:05 PM, Dr. Stephen Henson <steve at openssl.org>
wrote:

> On Sun, Jul 17, 2016, Abhilash K.V wrote:
>
> > I am trying to generate a CSR using EC and wanted to have signature
> > algorithm as ???ecdsa-with-SHA512???.
> >
> > But in the generated csr I am getting signature algorithms as
> ???Signature
> > Algorithm: ecdsa-with-SHA1??? always.
> >
> >
> >     if (!X509_REQ_sign(req, privkey, EVP_ecdsa())) {
> >
>
> Don't use EVP_ecdsa() it is an old "linked digest" which uses SHA1 and is
> only
> retained for compatibility with old code. Use EVP_sha512() instead.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> --
> 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/20160718/e676e57c/attachment.html>

From krajekg at gmail.com  Mon Jul 18 13:56:53 2016
From: krajekg at gmail.com (Grzegorz Krajewski)
Date: Mon, 18 Jul 2016 15:56:53 +0200
Subject: [openssl-users] [openssl] no version information available warning
Message-ID: <CAKC9FzP25=MzaXj7cCm=Wb+6PtE9_AQQuhmCBkd6Gmkf+J2Wyw@mail.gmail.com>

Helo there!

After installing from source openssl-1.0.1t which I downloaded from
openssl.org, I'm getting "runtime error":
* /lib64/libcrypto.so.10: no version information available (required by
executedTool)*
Before installation I had openssl-1.0.1e

Flow how I build it:
tar zxf openssl-1.0.1t.tar (acronym to full name of 1.0.1t)
cd openssl-1.0.1t/
./config shared
make
make install
, it's installing in /usr/local/ssl/ that is why I copy to proper path
/lib64/ or /usr/lib64/ (dependently from OS: redhat, suse, fedora) and
overwrite old .so files.

*[x at x ~]# ./RemoteAgentLinux64 -verbose*
*./RemoteAgentLinux64: /lib64/libcrypto.so.10: no version information
available (required by ./RemoteAgentLinux64)*
*./RemoteAgentLinux64: /lib64/libcrypto.so.10: no version information
available (required by ./RemoteAgentLinux64)*


*./RemoteAgentLinux64: /lib64/libssl.so.10: no version information
available (required by ./RemoteAgentLinux64)*
*[x at x ~]# openssl version -a*
*OpenSSL 1.0.1t  3 May 2016*
*built on: Wed Jul 13 07:31:08 2016*
*platform: linux-x86_64*
*options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int)
blowfish(idx)*
*compiler: gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN
-O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
-DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM*
*OPENSSLDIR: "/usr/local/ssl"*

I found some information that I'm gonna have this warning when I build tool
which I'm executing with older version of openssl ( < 1.0.1t ) then the one
which I wanna use finally ( 1.0.1t ). Is this possible?

Best regards,
Grzegorz Krajewski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160718/9853663e/attachment.html>

From matt at openssl.org  Mon Jul 18 17:21:01 2016
From: matt at openssl.org (Matt Caswell)
Date: Mon, 18 Jul 2016 18:21:01 +0100
Subject: [openssl-users] [openssl] no version information available
 warning
In-Reply-To: <CAKC9FzP25=MzaXj7cCm=Wb+6PtE9_AQQuhmCBkd6Gmkf+J2Wyw@mail.gmail.com>
References: <CAKC9FzP25=MzaXj7cCm=Wb+6PtE9_AQQuhmCBkd6Gmkf+J2Wyw@mail.gmail.com>
Message-ID: <578D0FFD.6030209@openssl.org>



On 18/07/16 14:56, Grzegorz Krajewski wrote:
> Helo there!
> 
> After installing from source openssl-1.0.1t which I downloaded
> from openssl.org <http://openssl.org/>, I'm getting "runtime error":
> * /lib64/libcrypto.so.10: no version information available (required by
> executedTool)*
> Before installation I had openssl-1.0.1e
> 
> Flow how I build it:
> tar zxf openssl-1.0.1t.tar (acronym to full name of 1.0.1t)
> cd openssl-1.0.1t/
> ./config shared
> make
> make install
> , it's installing in /usr/local/ssl/ that is why I copy to proper path
> /lib64/ or /usr/lib64/ (dependently from OS: redhat, suse, fedora) and
> overwrite old .so files.
> *
> *
> *[x at x ~]# ./RemoteAgentLinux64 -verbose*
> *./RemoteAgentLinux64: /lib64/libcrypto.so.10: no version information
> available (required by ./RemoteAgentLinux64)*
> *./RemoteAgentLinux64: /lib64/libcrypto.so.10: no version information
> available (required by ./RemoteAgentLinux64)*
> *./RemoteAgentLinux64: /lib64/libssl.so.10: no version information
> available (required by ./RemoteAgentLinux64)
> 
> *
> *[x at x ~]# openssl version -a*
> *OpenSSL 1.0.1t  3 May 2016*
> *built on: Wed Jul 13 07:31:08 2016*
> *platform: linux-x86_64*
> *options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int)
> blowfish(idx)*
> *compiler: gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC
> -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
> -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
> -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM*
> *OPENSSLDIR: "/usr/local/ssl"*
> 
> I found some information that I'm gonna have this warning when I build
> tool which I'm executing with older version of openssl ( < 1.0.1t ) then
> the one which I wanna use finally ( 1.0.1t ). Is this possible?

This warning occurs because OpenSSL 1.0.1 and OpenSSL 1.0.2 do not
provide symbol version information (the forthcoming OpenSSL 1.1.0 does
do this BTW) but the application you are running is expecting those
symbol versions to be present.

Most distros do not provide out-of-the-box OpenSSL. Instead they
normally add some of their own patches on top. At least Debian adds a
patch to include symbol version info and, from your description, it
sounds like other distros do this too.

Applications linked against a version of the library which includes
symbol versions will complain if you try to run them with a version that
doesn't have that information.

The distros will typically update the OS patched version of OpenSSL with
security updates from upstream OpenSSL, so normally there is no reason
to upgrade the "letter" version of an OS supplied OpenSSL with an
upstream version unless:
1) there are specific bug fixes you wish to obtain that have not been
incorporated in the OS supplied version
or
2) you wish to use specific compilation options different to that used
in the OS version
or
3) you wish to do a "number" upgrade such as 1.0.1 to 1.0.2

If you decide to install from upstream then it is usually preferable to
install it in some other location to that used by the OS (e.g. keep it
in /usr/local/ssl). That way apps that need to use the upstream version
can use that version, but all the other system supplied apps can use the
OS version. Otherwise you run into problems where some apps are
expecting symbol version info (e.g. system supplied apps) whereas others
are not.

If your app is linked against the OS supplied version, and you now wish
to use the upstream version then you will need to relink your app
against the new library so that it no longer uses the symbol versioning
information.

Matt


From jonetsu at teksavvy.com  Mon Jul 18 18:03:47 2016
From: jonetsu at teksavvy.com (jonetsu)
Date: Mon, 18 Jul 2016 11:03:47 -0700 (MST)
Subject: [openssl-users] FIPS: Simulating failure at run-time ?
Message-ID: <1468865027675-67350.post@n7.nabble.com>

Hello,

Is it possible to simulate FIPS failure at run-time, at any given time ?  Or
does OpenSSL have to start in failure simulation mode ?  Also, is failure
simulation a standard part of a normal, non-debug, build ?

Thanks.




--
View this message in context: http://openssl.6102.n7.nabble.com/FIPS-Simulating-failure-at-run-time-tp67350.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From doctor at doctor.nl2k.ab.ca  Mon Jul 18 23:58:36 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Mon, 18 Jul 2016 17:58:36 -0600
Subject: [openssl-users] Moving on
Message-ID: <20160718235836.GB2296@doctor.nl2k.ab.ca>

I will be retiring our BSDI servers tonight replacing them
with FreeBSD servers.

I will still work with you on 1.0 and 1.1 development issues.

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Language is the source of misunderstandings.  -Antoine de Saint-Exupery  

From rsalz at akamai.com  Tue Jul 19 00:30:12 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 19 Jul 2016 00:30:12 +0000
Subject: [openssl-users] [openssl-dev] Moving on
In-Reply-To: <20160718235836.GB2296@doctor.nl2k.ab.ca>
References: <20160718235836.GB2296@doctor.nl2k.ab.ca>
Message-ID: <f44f3ab0672343b186204d4e20421578@usma1ex-dag1mb1.msg.corp.akamai.com>

We'll have a moment of silence ;)

Seriously, glad your subject line referred to systems, and not to you helping  test snapshots!

From harjoc at gmail.com  Tue Jul 19 09:16:05 2016
From: harjoc at gmail.com (Bogdan Harjoc)
Date: Tue, 19 Jul 2016 12:16:05 +0300
Subject: [openssl-users] Cipher preference, openssl vs browsers
Message-ID: <CAF4+tmoESwJmVUMugrw4tcGivdWPO3qn8Y6dFnwX2Z49m5X3VQ@mail.gmail.com>

When connecting to a TLS1.2 webserver that uses a weak 512 bit DH key,
I noticed that browsers select

  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  (chrome, firefox)

and openssl due to the ciphers list selects

  TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA

openssl s_client -connect 112.175.90.160:443 -cipher
DEFAULT
:!EDH-RSA-DES-CBC3-SHA
:!DHE-RSA-AES128-GCM-SHA256
:!DHE-RSA-AES256-GCM-SHA384
:!DHE-RSA-AES128-SHA256
:!DHE-RSA-AES128-SHA
:!DHE-RSA-AES256-SHA256
:!DHE-RSA-AES256-SHA
:-ECDH
:-EXPORT:-DES:-SEED:-RC4:-PSK:-IDEA
:ECDHE-RSA-AES128-SHA

The error is: dh key too small:.\ssl\s3_clnt.c:3424.

>From a client that uses openssl libs, what would the correct
workaround be ? Try to figure out that the DH key is too small and
retry with the DHE ciphers disabled ? Or reorder the ciphers ? Given
that cipher order can lead to failed handshakes, is there a correct
order for https clients ?

From jb-openssl at wisemo.com  Tue Jul 19 09:29:51 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 19 Jul 2016 11:29:51 +0200
Subject: [openssl-users] Cipher preference, openssl vs browsers
In-Reply-To: <CAF4+tmoESwJmVUMugrw4tcGivdWPO3qn8Y6dFnwX2Z49m5X3VQ@mail.gmail.com>
References: <CAF4+tmoESwJmVUMugrw4tcGivdWPO3qn8Y6dFnwX2Z49m5X3VQ@mail.gmail.com>
Message-ID: <27565f74-19ee-8f87-571f-71956968b3e7@wisemo.com>

On 19/07/2016 11:16, Bogdan Harjoc wrote:
> When connecting to a TLS1.2 webserver that uses a weak 512 bit DH key,
> I noticed that browsers select
>
>    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>    (chrome, firefox)
>
> and openssl due to the ciphers list selects
>
>    TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
>
> openssl s_client -connect 112.175.90.160:443 -cipher
> DEFAULT
> :!EDH-RSA-DES-CBC3-SHA
> :!DHE-RSA-AES128-GCM-SHA256
> :!DHE-RSA-AES256-GCM-SHA384
> :!DHE-RSA-AES128-SHA256
> :!DHE-RSA-AES128-SHA
> :!DHE-RSA-AES256-SHA256
> :!DHE-RSA-AES256-SHA
> :-ECDH
> :-EXPORT:-DES:-SEED:-RC4:-PSK:-IDEA
> :ECDHE-RSA-AES128-SHA
>
> The error is: dh key too small:.\ssl\s3_clnt.c:3424.
>
>  From a client that uses openssl libs, what would the correct
> workaround be ? Try to figure out that the DH key is too small and
> retry with the DHE ciphers disabled ? Or reorder the ciphers ? Given
> that cipher order can lead to failed handshakes, is there a correct
> order for https clients ?
I am not sure, but I guess those browsers default to listing ECDHE
before EDHE, thus never notices the weak DH group parameters (not
key, OpenSSL error message is misleading).

You could try testing those particular versions of chrome and firefox
against https://www.ssllabs.com/ssltest/viewMyClient.html to see what
their cipher list is.

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


From jim at carroll.com  Tue Jul 19 11:49:33 2016
From: jim at carroll.com (Jim Carroll)
Date: Tue, 19 Jul 2016 07:49:33 -0400
Subject: [openssl-users] Help finding replacement for ASN1_seq_unpack_X509
Message-ID: <025d01d1e1b3$9e236390$da6a2ab0$@carroll.com>

OpenSSL 1.1.0 has upgraded the safestack.h macro system, but I'm having
difficulty understanding the changes. I'm porting a piece of code from
OpenSSL 0.9.8 that uses ASN1_seq_unpack_X509. In 0.9.8, safestack.h had this
definition.

#define ASN1_seq_unpack_X509(buf, len, d2i_func, free_func) \

        SKM_ASN1_seq_unpack(X509, (buf), (len), (d2i_func), (free_func))

Could anyone point me in the right direction and how this needs to be
adapted?

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160719/962873b5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4722 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160719/962873b5/attachment.bin>

From abhilashkv at gmail.com  Tue Jul 19 13:29:09 2016
From: abhilashkv at gmail.com (Abhilash K.V)
Date: Tue, 19 Jul 2016 17:29:09 +0400
Subject: [openssl-users] Regarding Signature Algorithm: ecdsa-with-SHA512
In-Reply-To: <CAACZ9ZH6EHwpo=7evrKC8fiE7_S1SbGW+RBWyoknHEoK2TnjSA@mail.gmail.com>
References: <CAACZ9ZF9vj7gA54RFb_D7oqPJkLeBhuSVt==ALUSNQqVhjNsdQ@mail.gmail.com>
 <20160717160535.GA28032@openssl.org>
 <CAACZ9ZH6EHwpo=7evrKC8fiE7_S1SbGW+RBWyoknHEoK2TnjSA@mail.gmail.com>
Message-ID: <CAACZ9ZEEkB0ebQrDG6MmMqpOD6bM4ugv5upvKrWA8s8P2dM_+Q@mail.gmail.com>

Hi Steve,

This worked now. Thanks

Thanks,
Abhilash.

On Mon, Jul 18, 2016 at 7:34 AM, Abhilash K.V <abhilashkv at gmail.com> wrote:

> Hi Steve,
>
> Thanks for the information I was not aware of that.
>
> Yes, did that modification and now I am getting it as following (I passed
> EVP_sha512()).
>
> Signature Algorithm: ecdsa-with-SHA256
>
> Thanks,
> Abhilash.
>
> On Sun, Jul 17, 2016 at 8:05 PM, Dr. Stephen Henson <steve at openssl.org>
> wrote:
>
>> On Sun, Jul 17, 2016, Abhilash K.V wrote:
>>
>> > I am trying to generate a CSR using EC and wanted to have signature
>> > algorithm as ???ecdsa-with-SHA512???.
>> >
>> > But in the generated csr I am getting signature algorithms as
>> ???Signature
>> > Algorithm: ecdsa-with-SHA1??? always.
>> >
>> >
>> >     if (!X509_REQ_sign(req, privkey, EVP_ecdsa())) {
>> >
>>
>> Don't use EVP_ecdsa() it is an old "linked digest" which uses SHA1 and is
>> only
>> retained for compatibility with old code. Use EVP_sha512() instead.
>>
>> Steve.
>> --
>> Dr Stephen N. Henson. OpenSSL project core developer.
>> Commercial tech support now available see: http://www.openssl.org
>> --
>> 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/20160719/a7903fa2/attachment-0001.html>

From abhilashkv at gmail.com  Tue Jul 19 13:32:12 2016
From: abhilashkv at gmail.com (Abhilash K.V)
Date: Tue, 19 Jul 2016 17:32:12 +0400
Subject: [openssl-users] Regarding OpenSSL_add_all_algorithms function
Message-ID: <CAACZ9ZFJ99G8xB-wP62fG3RQUANkb8Ym1CO+vwQS-kSs+qWKvg@mail.gmail.com>

Hi,

Is there any issue in calling "OpenSSL_add_all_algorithms"
multiple times in a program ?

code is like this:

constructor:
        OpenSSL_add_all_algorithms
destructor:
        EVP_Cleanup

I read some where that even if "OpenSSL_add_all_algorithms" called multiple
times only the first call will work.

Thanks,
Abhilash.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160719/fcdc8b96/attachment.html>

From ivascu.gabriel59 at gmail.com  Tue Jul 19 20:05:13 2016
From: ivascu.gabriel59 at gmail.com (=?UTF-8?Q?Gabriel_Iva=C8=99cu?=)
Date: Tue, 19 Jul 2016 23:05:13 +0300
Subject: [openssl-users] RSA sign message
Message-ID: <CAMFzgngBDd2yRydbHY8Wm-8xji5uKnZAz0SU9X5ox-Y-kdoyQg@mail.gmail.com>

Hi,

I need to RSA sign a message using SHA256 as hash and PKCS1 v1.5 as padding.

I am however confused about the *type* parameter of RSA_sign function [0]

What is the value that I should use for *type* in my particular case?

Thanks,
Gabriel

[0] https://www.openssl.org/docs/manmaster/crypto/RSA_sign.html

From steve at openssl.org  Tue Jul 19 21:19:43 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 19 Jul 2016 21:19:43 +0000
Subject: [openssl-users] RSA sign message
In-Reply-To: <CAMFzgngBDd2yRydbHY8Wm-8xji5uKnZAz0SU9X5ox-Y-kdoyQg@mail.gmail.com>
References: <CAMFzgngBDd2yRydbHY8Wm-8xji5uKnZAz0SU9X5ox-Y-kdoyQg@mail.gmail.com>
Message-ID: <20160719211943.GA10984@openssl.org>

On Tue, Jul 19, 2016, Gabriel Iva??cu wrote:

> Hi,
> 
> I need to RSA sign a message using SHA256 as hash and PKCS1 v1.5 as padding.
> 
> I am however confused about the *type* parameter of RSA_sign function [0]
> 
> What is the value that I should use for *type* in my particular case?
> 

If you want to hash and sign the hash you should use EVP functions such as
 EVP_DigestSign*() functions instead. If you already have the hash you can
use RSA_sign (though EVP_PKEY_sign() is preferred) the type parameter in
the NID of the digest algorithm, for SHA256 you use NID_sha256.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From steve at openssl.org  Tue Jul 19 22:10:01 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 19 Jul 2016 22:10:01 +0000
Subject: [openssl-users] Help finding replacement for
	ASN1_seq_unpack_X509
In-Reply-To: <025d01d1e1b3$9e236390$da6a2ab0$@carroll.com>
References: <025d01d1e1b3$9e236390$da6a2ab0$@carroll.com>
Message-ID: <20160719221001.GA12312@openssl.org>

On Tue, Jul 19, 2016, Jim Carroll wrote:

> OpenSSL 1.1.0 has upgraded the safestack.h macro system, but I'm having
> difficulty understanding the changes. I'm porting a piece of code from
> OpenSSL 0.9.8 that uses ASN1_seq_unpack_X509. In 0.9.8, safestack.h had this
> definition.
> 
> #define ASN1_seq_unpack_X509(buf, len, d2i_func, free_func) \
> 
>         SKM_ASN1_seq_unpack(X509, (buf), (len), (d2i_func), (free_func))
> 
> Could anyone point me in the right direction and how this needs to be
> adapted?
>  
> 

Ah, that uses some ancient stuff which is originally from OpenSSL 0.9.6. For
1.1.0 this has changed. You need to create a typedef for a STACK_OF(X509) and
then define ASN.1 functions for it for a SEQUENCE OF X509. That is a lot
easier than it sounds. This should do it:

#include <openssl/x509.h>
#include <openssl/asn1t.h>

typedef STACK_OF(X509) SEQ_CERT;

ASN1_ITEM_TEMPLATE(SEQ_CERT) =
        ASN1_EX_TEMPLATE_TYPE(ASN1_TFLG_SEQUENCE_OF, 0, SeqCert, X509)
ASN1_ITEM_TEMPLATE_END(SEQ_CERT)

IMPLEMENT_ASN1_FUNCTIONS(SEQ_CERT)

This defines a function d2i_SEQ_CERT() which replaces the original macro.

Note that this construct should also work in earlier versions of OpenSSL too
including 0.9.8.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From ivascu.gabriel59 at gmail.com  Wed Jul 20 08:48:05 2016
From: ivascu.gabriel59 at gmail.com (=?UTF-8?Q?Gabriel_Iva=C8=99cu?=)
Date: Wed, 20 Jul 2016 11:48:05 +0300
Subject: [openssl-users] RSA sign message
In-Reply-To: <20160719211943.GA10984@openssl.org>
References: <CAMFzgngBDd2yRydbHY8Wm-8xji5uKnZAz0SU9X5ox-Y-kdoyQg@mail.gmail.com>
 <20160719211943.GA10984@openssl.org>
Message-ID: <CAMFzgnh+eeuV3XQ0nPHnfqu7jvkRc9VoegVzPXupEWOxa-FP1w@mail.gmail.com>

On Wed, Jul 20, 2016 at 12:19 AM, Dr. Stephen Henson <steve at openssl.org> wrote:
>
> If you want to hash and sign the hash you should use EVP functions such as
>  EVP_DigestSign*() functions instead. If you already have the hash you can
> use RSA_sign (though EVP_PKEY_sign() is preferred) the type parameter in
> the NID of the digest algorithm, for SHA256 you use NID_sha256.

Indeed, NID_sha256 works great in my case, thank you!

I will have a look at EVP_DigestSign*() functions too.

Thanks,
Gabriel

From kgoldman at us.ibm.com  Wed Jul 20 14:21:07 2016
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Wed, 20 Jul 2016 10:21:07 -0400
Subject: [openssl-users] Generate ECC key with password protection
Message-ID: <nmo1cg$9qn$1@ger.gmane.org>

 From these web pages:

https://wiki.openssl.org/index.php/Command_Line_Elliptic_Curve_Operations

https://www.openssl.org/docs/manmaster/apps/ecparam.html

the "openssl ecparam -genkey" command does not accept a password.  The 
(perhaps) equivalent "openssl genrsa" command does.

Is there a openssl command that can generate an ECC key pair where the 
output file is password protected?





From jb-openssl at wisemo.com  Wed Jul 20 14:26:55 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 20 Jul 2016 16:26:55 +0200
Subject: [openssl-users] Generate ECC key with password protection
In-Reply-To: <nmo1cg$9qn$1@ger.gmane.org>
References: <nmo1cg$9qn$1@ger.gmane.org>
Message-ID: <ff3c5a86-f537-2037-fcf2-35ced62072f5@wisemo.com>

On 20/07/2016 16:21, Ken Goldman wrote:
> From these web pages:
>
> https://wiki.openssl.org/index.php/Command_Line_Elliptic_Curve_Operations
>
> https://www.openssl.org/docs/manmaster/apps/ecparam.html
>
> the "openssl ecparam -genkey" command does not accept a password. The 
> (perhaps) equivalent "openssl genrsa" command does.
>
> Is there a openssl command that can generate an ECC key pair where the 
> output file is password protected?
>
openssl genpkey

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


From doctor at doctor.nl2k.ab.ca  Wed Jul 20 07:23:07 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Wed, 20 Jul 2016 01:23:07 -0600
Subject: [openssl-users] openssl-SNAP-20160720
Message-ID: <20160720072307.GA87118@doctor.nl2k.ab.ca>

./libcrypto.so: undefined reference to `RUN_ONCE'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1  

Please fix
-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Language is the source of misunderstandings.  -Antoine de Saint-Exupery  

From jim at carroll.com  Thu Jul 21 01:29:15 2016
From: jim at carroll.com (Jim Carroll)
Date: Wed, 20 Jul 2016 21:29:15 -0400
Subject: [openssl-users] Help finding replacement
	for	ASN1_seq_unpack_X509
In-Reply-To: <20160719221001.GA12312@openssl.org>
References: <025d01d1e1b3$9e236390$da6a2ab0$@carroll.com>
 <20160719221001.GA12312@openssl.org>
Message-ID: <003901d1e2ef$4b530c50$e1f924f0$@carroll.com>

Thanks much....I have a corollary question if you don't mind.  In OpenSSL
1.1.0, what is the accepted procedure to convert a STACK_OF(X509) to DER?

Would it be acceptable to just iterate the stack elements, passing each X509
through i2d_X509 and appending the results -- would that generate valid DER?
Is there a better way?


> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
> Behalf Of Dr. Stephen Henson
> Sent: Tuesday, July 19, 2016 6:10 PM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Help finding replacement for
> ASN1_seq_unpack_X509
> 
> On Tue, Jul 19, 2016, Jim Carroll wrote:
> 
> > OpenSSL 1.1.0 has upgraded the safestack.h macro system, but I'm
> having
> > difficulty understanding the changes. I'm porting a piece of code
> from
> > OpenSSL 0.9.8 that uses ASN1_seq_unpack_X509. In 0.9.8, safestack.h
> had this
> > definition.
> >
> > #define ASN1_seq_unpack_X509(buf, len, d2i_func, free_func) \
> >
> >         SKM_ASN1_seq_unpack(X509, (buf), (len), (d2i_func),
> (free_func))
> >
> > Could anyone point me in the right direction and how this needs to be
> > adapted?
> >
> >
> 
> Ah, that uses some ancient stuff which is originally from OpenSSL
> 0.9.6. For
> 1.1.0 this has changed. You need to create a typedef for a
> STACK_OF(X509) and
> then define ASN.1 functions for it for a SEQUENCE OF X509. That is a
> lot
> easier than it sounds. This should do it:
> 
> #include <openssl/x509.h>
> #include <openssl/asn1t.h>
> 
> typedef STACK_OF(X509) SEQ_CERT;
> 
> ASN1_ITEM_TEMPLATE(SEQ_CERT) =
>         ASN1_EX_TEMPLATE_TYPE(ASN1_TFLG_SEQUENCE_OF, 0, SeqCert, X509)
> ASN1_ITEM_TEMPLATE_END(SEQ_CERT)
> 
> IMPLEMENT_ASN1_FUNCTIONS(SEQ_CERT)
> 
> This defines a function d2i_SEQ_CERT() which replaces the original
> macro.
> 
> Note that this construct should also work in earlier versions of
> OpenSSL too
> including 0.9.8.
> 
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


begin 666 smime.p7s
M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$'
M`0``H((.$3""!#8P@@,>H ,"`0("`0$P#08)*H9(AO<-`0$%!0`P;S$+, D&
M`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T($%",28P) 8#500+$QU!9&14
M<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B," &`U4$`Q,9061D5')U<W0@
M17AT97)N86P at 0T$@4F]O=# >%PTP,# U,S Q,#0X,SA:%PTR,# U,S Q,#0X
M,SA:,&\Q"S )!@-5! 83`E-%,10P$@8#500*$PM!9&14<G5S="!!0C$F,"0&
M`U4$"Q,=061D5')U<W0 at 17AT97)N86P at 5%10($YE='=O<FLQ(C @!@-5! ,3
M&4%D9%1R=7-T($5X=&5R;F%L($-!(%)O;W0P@@$B, T&"2J&2(;W#0$!`04`
M`X(!#P`P@@$*`H(!`0"W]QHSYO(`!"TYX$Y;[1^\; _-M?HCML[>FQ$SEZ0I
M3'V3G[U*O)/M`QKCC\_E;5!:UI<IE%J L$EZVRZ5_;C*OS<X+1X^D4&M<%;'
M\$\_Z#*>=,K(D%3IQE\/>)V:0#P.K&&J7A2/GH>A:E#<UYI.KP6SIG&4G'&S
M4& *QQ.=. >&`JCIJ&DF&)"K3+!/(ZLZ3X38W\Z?X6EON]="UVM$Y,>M[FU!
M7W):<0 at WLWEEI%F at E#?W`"\-PI)RVM X<ML4J$7$72I]M[36Q.ZLS1-$M\DK
MW4,`)?IAN6EJ6",1MZ<SCU9U6?7-*==&MPHK9;;30F\5LKA[^^_I75/5-%HG
M`@,!``&C@=PP@=DP'08#51T.!!8$%*V]F'HTM";W^L0F5.\#O> DRU0:, L&
M`U4=#P0$`P(!!C /!@-5'1,!`?\$!3 #`0'_,(&9!@-5'2,$@9$P at 8Z %*V]
MF'HTM";W^L0F5.\#O> DRU0:H7.D<3!O,0LP"08#500&$P)313$4,!(&`U4$
M"A,+061D5')U<W0 at 04(Q)C D!@-5! L3'4%D9%1R=7-T($5X=&5R;F%L(%14
M4"!.971W;W)K,2(P( 8#500#$QE!9&14<G5S="!%>'1E<FYA;"!#02!2;V]T
M@@$!, T&"2J&2(;W#0$!!04``X(!`0"PF^"%)<+6(^(/E@:2G4&8G-F$>8'9
M'EL4!R,V98^PV'>[K$%L1V"#4;#Y,CWG_/8F$\> %J6_6OR'SWAYB2&:XDP'
M"H8UO/+>4<32EK?<?D[N</T<.>L,`E$4+8Z]%N#!WT9UYR2M[/1"M(63<!!G
MNIT&-4H8TRMZS%%"H7ICT>:[H<4KPC:^$PWFO6-^>7NG"0U JVK=CXK#]O:,
M&D(%4=1%]9^G8B%H%2!#/)GG?+TDV*F1%W.(/U8;,3 at 8M'$/FLW(#IZ.+AOA
MC)B#RQ\Q\41,Q at 1S279@#\?XO1> :R[IS$P.6IIY#R *+M6>8R8>59*4V((7
M6GO0O,>/3H8$,(($KS""`Y>@`P(!`@(1`. CRQ42 at U.)K6%N>E1G:R$P#08)
M*H9(AO<-`0$+!0`P;S$+, D&`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T
M($%",28P) 8#500+$QU!9&14<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B
M," &`U4$`Q,9061D5')U<W0 at 17AT97)N86P at 0T$@4F]O=# >%PTQ-#$R,C(P
M,# P,#!:%PTR,# U,S Q,#0X,SA:,(&;,0LP"08#500&$P)'0C$;,!D&`U4$
M"!,21W)E871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#
M500*$Q%#3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR
M-38 at 0VQI96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$P
M@@$B, T&"2J&2(;W#0$!`04``X(!#P`P@@$*`H(!`0")L0W:>E,93G!2';Q6
MI at 8FM[A)X);G4:OQ\%H3216CM(P;8+QZ44*G>8RD(M\784Z1U78C"A332@)_
MMAT)@&ZE!#W9NKL6_J&'J2Y#4D,6?*\R4,BF3UKI"-C/DR6<>XCH,&3FI/A6
M@/TJ)!0S%YFL1.5IBZ-&!DO",]3I0)\&L+&LDT"YM0B3.IPJ4Z,0VST at 83Q5
M`X[93G8E`B$I^J-\<79/[N%?@>G[5(#;PWLU4K>$WB(]+# M,7]9O5(WL#-I
M+4/K^M:E\9=W9U&,V>XGZ[RE!SAVC*2I./_?C/4#K$F^RO=SF3H/,JN<E3H3
M/0Y&.E=T85"^QD _R^3BGZ(A`@,!``&C@@$7,((!$S ?!@-5'2,$&# 6@!2M
MO9AZ-+0F]_K$)E3O`[W@),M4&C =!@-5'0X$%@04DF%K at N&BH*I/[&?QPJ/W
MM( `P>PP#@8#51T/`0'_! 0#`@&&,!(&`U4=$P$!_P0(, 8!`?\"`0`P'08#
M51TE!!8P% 8(*P8!!04'`P(&""L&`04%!P,$,!$&`U4=( 0*, @P!@8$51T@
M`#!$!@-5'1\$/3 [,#F at -Z UAC-H='1P.B\O8W)L+G5S97)T<G5S="YC;VTO
M061D5')U<W1%>'1E<FYA;$-!4F]O="YC<FPP-08(*P8!!04'`0$$*3 G,"4&
M""L&`04%!S !AAEH='1P.B\O;V-S<"YU<V5R=')U<W0N8V]M, T&"2J&2(;W
M#0$!"P4``X(!`0`;*FZL5<$ZJXC%V.W-5?.J:V$KP D0(YD/Q69J;['UM+5W
M7@\"80#??07^$K.D@( `_/L=6VIR`@I!O 6ZP5C5)L+JU4V$^_Z"F,]8&^,B
M8YQ2^+L%-JM]6*7>JSMCY=K5<^_LX/M[XJ/_\$(CG,JVC4T^Y$L8`[*H+=38
MNT)+D&F%$-NF-S3H>^ !$*6<RCK'GT^(-&Z*9= :BKNIW,K*-M'T_,)D*36O
MUK&G<1'2`T.QCSZ:[)XR4_1VDLJ&- >Y+,KF'$K8F0W!AN*0DOM:0FHC(1#I
M9<?UU;M^ZHR%( )BZM$Z!RQ9Q9DS\CB)Y;;I%GH?>13V2A :)OI\BON;,((%
M(#""! B@`P(!`@(1`-4+#]T2278FC)\!=Y87SN8P#08)*H9(AO<-`0$+!0`P
M at 9LQ"S )!@-5! 83`D=",1LP&08#500($Q)'<F5A=&5R($UA;F-H97-T97(Q
M$# .!@-5! <3!U-A;&9O<F0Q&C 8!@-5! H3$4-/34]$3R!#02!,:6UI=&5D
M,4$P/P8#500#$SA#3TU/1$\@4TA!+3(U-B!#;&EE;G0 at 075T:&5N=&EC871I
M;VX at 86YD(%-E8W5R92!%;6%I;"!#03 >%PTQ-C Q,3,P,# P,#!:%PTQ-S Q
M,3(R,S4Y-3E:," Q'C <!@DJADB&]PT!"0$6#VII;4!C87)R;VQL+F-O;3""
M`2(P#08)*H9(AO<-`0$!!0`#@@$/`#""`0H"@@$!`-K\XS'GF('[$TPZLMT=
MY]ID(UGI at 9^?K.$F3&?)JS.0Q"6)OD@;8S<+1#[2QFG.S045<BKJ-D6O9FQ\
M<*2_A$&HWT6R`S' 7$<4M7HIO_"G at U#-`1,6W2HZ`,L53(EL?:P_[H%Y/6VB
MJU\01/0U<U7T/"K$+CFK\>HV/H^"EPS!W)_L#3<"[3T(BZ3LDTHN"#(\B5A1
M^VO2XN77=+Z\+IU=@1UR!40:,<7&)5,P,O1STRE:UFFYLS65=GVT*:ZY[YK9
M':(_+75)?UCOJQ: M-%=9XH<_VNPXG^;7/:6"2-DDFNH3JMIBVKH$1G/E$ 9
MD8XE<3>#8^@.89*P$#)O+'$"`P$``:."`=<P@@'3,!\&`U4=(P08,!: %))A
M:X+AHJ"J3^QG\<*C][2 `,'L,!T&`U4=#@06!!0P:UC0J,N<!7>SB(9<*/G'
MV*_ SS .!@-5'0\!`?\$! ,"!: P# 8#51T3`0'_! (P`# =!@-5'24$%C 4
M!@@K!@$%!0<#! 8(*P8!!04'`P(P1 at 8#51T@!#\P/3 [!@PK!@$$`;(Q`0(!
M`P4P*S I!@@K!@$%!0<"`18=:'1T<',Z+R]S96-U<F4N8V]M;V1O+FYE="]#
M4%,P708#51T?!%8P5#!2H%"@3H9,:'1T<#HO+V-R;"YC;VUO9&]C82YC;VTO
M0T]-3T1/4TA!,C4V0VQI96YT075T:&5N=&EC871I;VYA;F1396-U<F5%;6%I
M;$-!+F-R;#"!D 8(*P8!!04'`0$$@8,P at 8 P6 8(*P8!!04', *&3&AT=' Z
M+R]C<G0N8V]M;V1O8V$N8V]M+T-/34]$3U-(03(U-D-L:65N=$%U=&AE;G1I
M8V%T:6]N86YD4V5C=7)E16UA:6Q#02YC<G0P) 8(*P8!!04', &&&&AT=' Z
M+R]O8W-P+F-O;6]D;V-A+F-O;3 :!@-5'1$$$S 1 at 0]J:6U 8V%R<F]L;"YC
M;VTP#08)*H9(AO<-`0$+!0`#@@$!`&7_YE!"6I-N>DE*'QH34=CM%+[K`1M]
M]CL[U/FRY5[^LX>0V\F[3S&JAG>8?S4(\8%YC7"@FZN?&[XNG;*71FB1VC5\
M[C at 1T1/1VFB^.U_DY "31W;:;K"NZ]K)Q3#HO(@&45E,YCJ!NY$AC!C\IGQ:
M2/NGP"_K'85*^(.K.&Q*INS)?2E26GN'Y^%BLAID at HA<[DL&']YY*Z 9#&;V
MFJ3HYV^Y[HF)FFH-]D/]<5G):'.LJD*"]IJWI4,'-BQ;060E4[7[NKAN!^P\
MBTU&T;&8EQ; '\I'[_^.1-;+K'J.:_]/&2]A0 at L9SC^8NO*8S_4,>"4TRIOH
MI'J>$[1$P4TQ@@0C,(($'P(!`3"!L3"!FS$+, D&`U4$!A,"1T(Q&S 9!@-5
M! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'4V%L9F]R9#$:,!@&
M`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3.$-/34]$3R!32$$M
M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C=7)E($5M86EL($-!
M`A$`U0L/W1))=B:,GP%WEA?.YC )!@4K#@,"&@4`H(("1C 8!@DJADB&]PT!
M"0,Q"P8)*H9(AO<-`0<!,!P&"2J&2(;W#0$)!3$/%PTQ-C W,C$P,3(Y,31:
M,",&"2J&2(;W#0$)!#$6!!3QO1K$?%C\DP?'8-/C%M/&P+T>G3!;!@DJADB&
M]PT!"0\Q3C!,, H&""J&2(;W#0,', X&""J&2(;W#0,"`@(`@# -!@@JADB&
M]PT#`@(!0# '!@4K#@,"!S -!@@JADB&]PT#`@(!*# '!@4K#@,"&C"!P at 8)
M*P8!! &"-Q $,8&T,(&Q,(&;,0LP"08#500&$P)'0C$;,!D&`U4$"!,21W)E
M871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#500*$Q%#
M3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR-38 at 0VQI
M96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$"$0#5"P_=
M$DEV)HR?`7>6%\[F,('$!@LJADB&]PT!"1 ""S&!M*"!L3"!FS$+, D&`U4$
M!A,"1T(Q&S 9!@-5! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'
M4V%L9F]R9#$:,!@&`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3
M.$-/34]$3R!32$$M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C
M=7)E($5M86EL($-!`A$`U0L/W1))=B:,GP%WEA?.YC -!@DJADB&]PT!`0$%
M``2"`0!G;Z9]+'/+3\H(*EWJQ at MTX$8=P;\9/DM,PK?"!V?D?&,4,^'_DJ>7
M]P,#-V&VL#/3-@#E^V58G\,W.MJ#/:GANE<?`W<OEHZH[R#LI*]Z85,F>_*/
MQROQ,DDPQ0FS]NRQ*4POITK<IT:-:L=WE6IL9@<6&_T1E-UO!^A:8+&^/M]R
M'K6+UPW"DMY>WYHO,1=W1."_BKV X"<=DT4<>D at LZG,]98WE!K\'(P%_:Y:W
M9KBWVEH,//=^0-U_\"'SB3KJF,RQ&K8&*P\%MP!W]:/%1 .$^WW2N,R%Y-<P
J$[&^+Z-_WLP)U0PT'*@*;_?Y> QEDD'\(#@_S.0HG=26^2]G````````
`
end


From rsalz at akamai.com  Thu Jul 21 08:35:06 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 21 Jul 2016 08:35:06 +0000
Subject: [openssl-users] Help finding
	replacement	for	ASN1_seq_unpack_X509
In-Reply-To: <003901d1e2ef$4b530c50$e1f924f0$@carroll.com>
References: <025d01d1e1b3$9e236390$da6a2ab0$@carroll.com>
 <20160719221001.GA12312@openssl.org>
 <003901d1e2ef$4b530c50$e1f924f0$@carroll.com>
Message-ID: <9b8c0edfac89463889e7d702724e2ee5@usma1ex-dag1mb1.msg.corp.akamai.com>

> Would it be acceptable to just iterate the stack elements, passing each X509
> through i2d_X509 and appending the results -- would that generate valid
> DER?

Maybe.  It depends on what the receiver is expecting.  If it's willing to read a set of certs until it hits EOF (or equivalent) that's fine.  But if you're sending a SEQUENCE OF certificates then you need to wrap it in an ASN1/DER container. For example, Netscape Cert Sequence

Can you post a code snippet?



From Saurabh.Gupta at cavium.com  Thu Jul 21 08:32:27 2016
From: Saurabh.Gupta at cavium.com (Gupta, Saurabh)
Date: Thu, 21 Jul 2016 08:32:27 +0000
Subject: [openssl-users]  Openssl software failure for RSA 16K modulus
Message-ID: <BN3PR07MB246737A3ABB76E4624723C9E97090@BN3PR07MB2467.namprd07.prod.outlook.com>

This issue, I'm facing for openssl-1.0.2e/g/h version.

Run openssl server: Used 16K Certificate and Key
./openssl s_server -cert sercert16384.pem -key server16384

Run openssl client:
./openssl s_client -connect <server_ip>:port_number -cipher AES128-SHA -tls1

ERROR

139812135450280:error:1408E098:SSL routines:ssl3_get_message:excessive message size:s3_both.c:417:


This error is coming while using AES128-SHA as a cipher and tls1/1_1/1_2 protocols. It's working fine with ssl3 protocol.

Note:
1. This issue, I didn't face for the openssl-1.0.1p/e version.

Can you please confirm. is this known issue?
if it is the known issue. Can you please share that fix?


Regards,
Saurabh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160721/019a4725/attachment.html>

From Erwann.Abalea at docusign.com  Thu Jul 21 10:31:03 2016
From: Erwann.Abalea at docusign.com (Erwann Abalea)
Date: Thu, 21 Jul 2016 10:31:03 +0000
Subject: [openssl-users] Openssl software failure for RSA 16K modulus
In-Reply-To: <BN3PR07MB246737A3ABB76E4624723C9E97090@BN3PR07MB2467.namprd07.prod.outlook.com>
References: <BN3PR07MB246737A3ABB76E4624723C9E97090@BN3PR07MB2467.namprd07.prod.outlook.com>
Message-ID: <F2A95F8F-BCC8-4EC5-984F-8B77C91BBAA2@docusign.com>

Largest accepted client key exchange message length seems to be set to 2048 bytes.
Key exchange for an RSA16k is slightly larger than that (exactly 2048 bytes of pure crypto payload, plus a few bytes of overhead).

OpenSSL is too conservative here.

Cordialement,
Erwann Abalea

Le 21 juil. 2016 ? 10:32, Gupta, Saurabh <Saurabh.Gupta at cavium.com<mailto:Saurabh.Gupta at cavium.com>> a ?crit :

This issue, I'm facing for openssl-1.0.2e/g/h version.

Run openssl server: Used 16K Certificate and Key
./openssl s_server -cert sercert16384.pem -key server16384

Run openssl client:
./openssl s_client -connect <server_ip>:port_number -cipher AES128-SHA -tls1

ERROR

139812135450280:error:1408E098:SSL routines:ssl3_get_message:excessive message size:s3_both.c:417:


This error is coming while using AES128-SHA as a cipher and tls1/1_1/1_2 protocols. It's working fine with ssl3 protocol.

Note:
1. This issue, I didn't face for the openssl-1.0.1p/e version.

Can you please confirm. is this known issue?
if it is the known issue. Can you please share that fix?

Regards,
Saurabh
--
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/20160721/01d6d941/attachment-0001.html>

From rsalz at akamai.com  Thu Jul 21 12:15:15 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 21 Jul 2016 12:15:15 +0000
Subject: [openssl-users] Openssl software failure for RSA 16K modulus
In-Reply-To: <F2A95F8F-BCC8-4EC5-984F-8B77C91BBAA2@docusign.com>
References: <BN3PR07MB246737A3ABB76E4624723C9E97090@BN3PR07MB2467.namprd07.prod.outlook.com>
 <F2A95F8F-BCC8-4EC5-984F-8B77C91BBAA2@docusign.com>
Message-ID: <f3934079655b4d8fa3328b21ea62ef6f@usma1ex-dag1mb1.msg.corp.akamai.com>


> Largest accepted client key exchange message length seems to be set to 2048 bytes. 
> Key exchange for an RSA16k is slightly larger than that (exactly 2048 bytes of pure crypto payload, plus a few bytes of overhead).

> OpenSSL is too conservative here.

Why not use an ECC key?

We have to make trade-offs.  Who uses a 16K RSA key?

From rsalz at akamai.com  Thu Jul 21 12:17:44 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 21 Jul 2016 12:17:44 +0000
Subject: [openssl-users] Openssl software failure for RSA 16K modulus
In-Reply-To: <f3934079655b4d8fa3328b21ea62ef6f@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <BN3PR07MB246737A3ABB76E4624723C9E97090@BN3PR07MB2467.namprd07.prod.outlook.com>
 <F2A95F8F-BCC8-4EC5-984F-8B77C91BBAA2@docusign.com>
 <f3934079655b4d8fa3328b21ea62ef6f@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <e8e3f6f5b5a849ab8000dab434aace1d@usma1ex-dag1mb1.msg.corp.akamai.com>

> We have to make trade-offs.  Who uses a 16K RSA key?

Let me add some  clarification.  Is it worth putting every application that uses OpenSSL at risk for a DoS attack with a 16K RSA key?

--  
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz



From jim at carroll.com  Thu Jul 21 12:52:24 2016
From: jim at carroll.com (Jim Carroll)
Date: Thu, 21 Jul 2016 08:52:24 -0400
Subject: [openssl-users] Help
	finding	replacement	for	ASN1_seq_unpack_X509
In-Reply-To: <9b8c0edfac89463889e7d702724e2ee5@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <025d01d1e1b3$9e236390$da6a2ab0$@carroll.com>
 <20160719221001.GA12312@openssl.org>
 <003901d1e2ef$4b530c50$e1f924f0$@carroll.com>
 <9b8c0edfac89463889e7d702724e2ee5@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <00e201d1e34e$ba83f760$2f8be620$@carroll.com>

 We are porting M2Crypto which is a python swig wrapper around OpenSSL. It
currently supports OpenSSL 0.9.8 and we are porting it to 1.1.0.  The 1.1.0
branch is really cool (clean, elegant code), but there were a few
refactoring's that affected M2Crypto.  Most were trivial getter/setter type
changes, but a few were in the are of getting rid of some ASN1 processing
(which happens to be our weakest point of understanding).

We're left with porting the final bit -- which is related to X509 cert
handling.  Here's a sample use. The caller builds up the call with a the
following 'psuedo-sequence'. get_der() is the function we are working on
finishing.

	X508* load_cert_bio(char* filename) {
	    BIO* bio = BIO_new_file(filename, "r");
	    return PEM_read_bio_X509(bio, NULL, NULL, NULL);
	    }

	unsigned char* get_der(int* len_out) {
	    X509* cert = load_cert_bio("x509.pem");
	    X509* ca = load_cert_bio("ca.pem");

	    STACK_OF(X509)* stack = sk_x509_new_null();
	    sk_x509_push(stack, cert);
	    sk_x509_push(stack, ca);

	    return ASN1_seq_pack_X509(stack, i2d_X509, NULL, len_out);
	    }

The ASN1_seq_pack_X509 was a macro -- and has been removed.


> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
> Behalf Of Salz, Rich
> Sent: Thursday, July 21, 2016 4:35 AM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Help finding replacement for
> ASN1_seq_unpack_X509
> 
> > Would it be acceptable to just iterate the stack elements, passing
> each X509
> > through i2d_X509 and appending the results -- would that generate
> valid
> > DER?
> 
> Maybe.  It depends on what the receiver is expecting.  If it's willing
> to read a set of certs until it hits EOF (or equivalent) that's fine.
> But if you're sending a SEQUENCE OF certificates then you need to wrap
> it in an ASN1/DER container. For example, Netscape Cert Sequence
> 
> Can you post a code snippet?
> 
> 
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


begin 666 smime.p7s
M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$'
M`0``H((.$3""!#8P@@,>H ,"`0("`0$P#08)*H9(AO<-`0$%!0`P;S$+, D&
M`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T($%",28P) 8#500+$QU!9&14
M<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B," &`U4$`Q,9061D5')U<W0@
M17AT97)N86P at 0T$@4F]O=# >%PTP,# U,S Q,#0X,SA:%PTR,# U,S Q,#0X
M,SA:,&\Q"S )!@-5! 83`E-%,10P$@8#500*$PM!9&14<G5S="!!0C$F,"0&
M`U4$"Q,=061D5')U<W0 at 17AT97)N86P at 5%10($YE='=O<FLQ(C @!@-5! ,3
M&4%D9%1R=7-T($5X=&5R;F%L($-!(%)O;W0P@@$B, T&"2J&2(;W#0$!`04`
M`X(!#P`P@@$*`H(!`0"W]QHSYO(`!"TYX$Y;[1^\; _-M?HCML[>FQ$SEZ0I
M3'V3G[U*O)/M`QKCC\_E;5!:UI<IE%J L$EZVRZ5_;C*OS<X+1X^D4&M<%;'
M\$\_Z#*>=,K(D%3IQE\/>)V:0#P.K&&J7A2/GH>A:E#<UYI.KP6SIG&4G'&S
M4& *QQ.=. >&`JCIJ&DF&)"K3+!/(ZLZ3X38W\Z?X6EON]="UVM$Y,>M[FU!
M7W):<0 at WLWEEI%F at E#?W`"\-PI)RVM X<ML4J$7$72I]M[36Q.ZLS1-$M\DK
MW4,`)?IAN6EJ6",1MZ<SCU9U6?7-*==&MPHK9;;30F\5LKA[^^_I75/5-%HG
M`@,!``&C@=PP@=DP'08#51T.!!8$%*V]F'HTM";W^L0F5.\#O> DRU0:, L&
M`U4=#P0$`P(!!C /!@-5'1,!`?\$!3 #`0'_,(&9!@-5'2,$@9$P at 8Z %*V]
MF'HTM";W^L0F5.\#O> DRU0:H7.D<3!O,0LP"08#500&$P)313$4,!(&`U4$
M"A,+061D5')U<W0 at 04(Q)C D!@-5! L3'4%D9%1R=7-T($5X=&5R;F%L(%14
M4"!.971W;W)K,2(P( 8#500#$QE!9&14<G5S="!%>'1E<FYA;"!#02!2;V]T
M@@$!, T&"2J&2(;W#0$!!04``X(!`0"PF^"%)<+6(^(/E@:2G4&8G-F$>8'9
M'EL4!R,V98^PV'>[K$%L1V"#4;#Y,CWG_/8F$\> %J6_6OR'SWAYB2&:XDP'
M"H8UO/+>4<32EK?<?D[N</T<.>L,`E$4+8Z]%N#!WT9UYR2M[/1"M(63<!!G
MNIT&-4H8TRMZS%%"H7ICT>:[H<4KPC:^$PWFO6-^>7NG"0U JVK=CXK#]O:,
M&D(%4=1%]9^G8B%H%2!#/)GG?+TDV*F1%W.(/U8;,3 at 8M'$/FLW(#IZ.+AOA
MC)B#RQ\Q\41,Q at 1S279@#\?XO1> :R[IS$P.6IIY#R *+M6>8R8>59*4V((7
M6GO0O,>/3H8$,(($KS""`Y>@`P(!`@(1`. CRQ42 at U.)K6%N>E1G:R$P#08)
M*H9(AO<-`0$+!0`P;S$+, D&`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T
M($%",28P) 8#500+$QU!9&14<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B
M," &`U4$`Q,9061D5')U<W0 at 17AT97)N86P at 0T$@4F]O=# >%PTQ-#$R,C(P
M,# P,#!:%PTR,# U,S Q,#0X,SA:,(&;,0LP"08#500&$P)'0C$;,!D&`U4$
M"!,21W)E871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#
M500*$Q%#3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR
M-38 at 0VQI96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$P
M@@$B, T&"2J&2(;W#0$!`04``X(!#P`P@@$*`H(!`0")L0W:>E,93G!2';Q6
MI at 8FM[A)X);G4:OQ\%H3216CM(P;8+QZ44*G>8RD(M\784Z1U78C"A332@)_
MMAT)@&ZE!#W9NKL6_J&'J2Y#4D,6?*\R4,BF3UKI"-C/DR6<>XCH,&3FI/A6
M@/TJ)!0S%YFL1.5IBZ-&!DO",]3I0)\&L+&LDT"YM0B3.IPJ4Z,0VST at 83Q5
M`X[93G8E`B$I^J-\<79/[N%?@>G[5(#;PWLU4K>$WB(]+# M,7]9O5(WL#-I
M+4/K^M:E\9=W9U&,V>XGZ[RE!SAVC*2I./_?C/4#K$F^RO=SF3H/,JN<E3H3
M/0Y&.E=T85"^QD _R^3BGZ(A`@,!``&C@@$7,((!$S ?!@-5'2,$&# 6@!2M
MO9AZ-+0F]_K$)E3O`[W@),M4&C =!@-5'0X$%@04DF%K at N&BH*I/[&?QPJ/W
MM( `P>PP#@8#51T/`0'_! 0#`@&&,!(&`U4=$P$!_P0(, 8!`?\"`0`P'08#
M51TE!!8P% 8(*P8!!04'`P(&""L&`04%!P,$,!$&`U4=( 0*, @P!@8$51T@
M`#!$!@-5'1\$/3 [,#F at -Z UAC-H='1P.B\O8W)L+G5S97)T<G5S="YC;VTO
M061D5')U<W1%>'1E<FYA;$-!4F]O="YC<FPP-08(*P8!!04'`0$$*3 G,"4&
M""L&`04%!S !AAEH='1P.B\O;V-S<"YU<V5R=')U<W0N8V]M, T&"2J&2(;W
M#0$!"P4``X(!`0`;*FZL5<$ZJXC%V.W-5?.J:V$KP D0(YD/Q69J;['UM+5W
M7@\"80#??07^$K.D@( `_/L=6VIR`@I!O 6ZP5C5)L+JU4V$^_Z"F,]8&^,B
M8YQ2^+L%-JM]6*7>JSMCY=K5<^_LX/M[XJ/_\$(CG,JVC4T^Y$L8`[*H+=38
MNT)+D&F%$-NF-S3H>^ !$*6<RCK'GT^(-&Z*9= :BKNIW,K*-M'T_,)D*36O
MUK&G<1'2`T.QCSZ:[)XR4_1VDLJ&- >Y+,KF'$K8F0W!AN*0DOM:0FHC(1#I
M9<?UU;M^ZHR%( )BZM$Z!RQ9Q9DS\CB)Y;;I%GH?>13V2A :)OI\BON;,((%
M(#""! B@`P(!`@(1`-4+#]T2278FC)\!=Y87SN8P#08)*H9(AO<-`0$+!0`P
M at 9LQ"S )!@-5! 83`D=",1LP&08#500($Q)'<F5A=&5R($UA;F-H97-T97(Q
M$# .!@-5! <3!U-A;&9O<F0Q&C 8!@-5! H3$4-/34]$3R!#02!,:6UI=&5D
M,4$P/P8#500#$SA#3TU/1$\@4TA!+3(U-B!#;&EE;G0 at 075T:&5N=&EC871I
M;VX at 86YD(%-E8W5R92!%;6%I;"!#03 >%PTQ-C Q,3,P,# P,#!:%PTQ-S Q
M,3(R,S4Y-3E:," Q'C <!@DJADB&]PT!"0$6#VII;4!C87)R;VQL+F-O;3""
M`2(P#08)*H9(AO<-`0$!!0`#@@$/`#""`0H"@@$!`-K\XS'GF('[$TPZLMT=
MY]ID(UGI at 9^?K.$F3&?)JS.0Q"6)OD@;8S<+1#[2QFG.S045<BKJ-D6O9FQ\
M<*2_A$&HWT6R`S' 7$<4M7HIO_"G at U#-`1,6W2HZ`,L53(EL?:P_[H%Y/6VB
MJU\01/0U<U7T/"K$+CFK\>HV/H^"EPS!W)_L#3<"[3T(BZ3LDTHN"#(\B5A1
M^VO2XN77=+Z\+IU=@1UR!40:,<7&)5,P,O1STRE:UFFYLS65=GVT*:ZY[YK9
M':(_+75)?UCOJQ: M-%=9XH<_VNPXG^;7/:6"2-DDFNH3JMIBVKH$1G/E$ 9
MD8XE<3>#8^@.89*P$#)O+'$"`P$``:."`=<P@@'3,!\&`U4=(P08,!: %))A
M:X+AHJ"J3^QG\<*C][2 `,'L,!T&`U4=#@06!!0P:UC0J,N<!7>SB(9<*/G'
MV*_ SS .!@-5'0\!`?\$! ,"!: P# 8#51T3`0'_! (P`# =!@-5'24$%C 4
M!@@K!@$%!0<#! 8(*P8!!04'`P(P1 at 8#51T@!#\P/3 [!@PK!@$$`;(Q`0(!
M`P4P*S I!@@K!@$%!0<"`18=:'1T<',Z+R]S96-U<F4N8V]M;V1O+FYE="]#
M4%,P708#51T?!%8P5#!2H%"@3H9,:'1T<#HO+V-R;"YC;VUO9&]C82YC;VTO
M0T]-3T1/4TA!,C4V0VQI96YT075T:&5N=&EC871I;VYA;F1396-U<F5%;6%I
M;$-!+F-R;#"!D 8(*P8!!04'`0$$@8,P at 8 P6 8(*P8!!04', *&3&AT=' Z
M+R]C<G0N8V]M;V1O8V$N8V]M+T-/34]$3U-(03(U-D-L:65N=$%U=&AE;G1I
M8V%T:6]N86YD4V5C=7)E16UA:6Q#02YC<G0P) 8(*P8!!04', &&&&AT=' Z
M+R]O8W-P+F-O;6]D;V-A+F-O;3 :!@-5'1$$$S 1 at 0]J:6U 8V%R<F]L;"YC
M;VTP#08)*H9(AO<-`0$+!0`#@@$!`&7_YE!"6I-N>DE*'QH34=CM%+[K`1M]
M]CL[U/FRY5[^LX>0V\F[3S&JAG>8?S4(\8%YC7"@FZN?&[XNG;*71FB1VC5\
M[C at 1T1/1VFB^.U_DY "31W;:;K"NZ]K)Q3#HO(@&45E,YCJ!NY$AC!C\IGQ:
M2/NGP"_K'85*^(.K.&Q*INS)?2E26GN'Y^%BLAID at HA<[DL&']YY*Z 9#&;V
MFJ3HYV^Y[HF)FFH-]D/]<5G):'.LJD*"]IJWI4,'-BQ;060E4[7[NKAN!^P\
MBTU&T;&8EQ; '\I'[_^.1-;+K'J.:_]/&2]A0 at L9SC^8NO*8S_4,>"4TRIOH
MI'J>$[1$P4TQ@@0C,(($'P(!`3"!L3"!FS$+, D&`U4$!A,"1T(Q&S 9!@-5
M! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'4V%L9F]R9#$:,!@&
M`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3.$-/34]$3R!32$$M
M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C=7)E($5M86EL($-!
M`A$`U0L/W1))=B:,GP%WEA?.YC )!@4K#@,"&@4`H(("1C 8!@DJADB&]PT!
M"0,Q"P8)*H9(AO<-`0<!,!P&"2J&2(;W#0$)!3$/%PTQ-C W,C$Q,C4R,C1:
M,",&"2J&2(;W#0$)!#$6!!1G&[GL6/=H8LZE9M4)L7L&;?<.K#!;!@DJADB&
M]PT!"0\Q3C!,, H&""J&2(;W#0,', X&""J&2(;W#0,"`@(`@# -!@@JADB&
M]PT#`@(!0# '!@4K#@,"!S -!@@JADB&]PT#`@(!*# '!@4K#@,"&C"!P at 8)
M*P8!! &"-Q $,8&T,(&Q,(&;,0LP"08#500&$P)'0C$;,!D&`U4$"!,21W)E
M871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#500*$Q%#
M3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR-38 at 0VQI
M96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$"$0#5"P_=
M$DEV)HR?`7>6%\[F,('$!@LJADB&]PT!"1 ""S&!M*"!L3"!FS$+, D&`U4$
M!A,"1T(Q&S 9!@-5! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'
M4V%L9F]R9#$:,!@&`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3
M.$-/34]$3R!32$$M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C
M=7)E($5M86EL($-!`A$`U0L/W1))=B:,GP%WEA?.YC -!@DJADB&]PT!`0$%
M``2"`0"BA-SZ*7/VI,VOREMEIW/;NJ!T.(Q,&_+LZM3[,K57Q>;>/_E:B,?4
MK5#@,W&"P\/'6&9N(0O:&\E9$LLW&L4A&HFUP*--6&QWBNO"Q&@@SIXKRKY!
M_1ADXBJEW(_'N=2L<O%!9/VQ^P]?>'::Q/1SE_GHOFK1&0]"5Q.5WG@#>A65
MB(_+) A!06%L^,:81&8%&!ZR+=BE5G.6@!ENZ? 9F%CZ(<"+? HBSP6%VV8?
MTAS31B5,U\:SOL4_RM%C>8G1EAU^KEX8F\F8/,E_>XVZIV_ at N7TL:@M3&I0Q
J=3SK\27,?_:X'&P\D7 at _/_32#280-K>N"UZHE-(Y;\OR3/=C````````
`
end


From rsalz at akamai.com  Thu Jul 21 12:57:09 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 21 Jul 2016 12:57:09 +0000
Subject: [openssl-users]
	Help	finding	replacement	for	ASN1_seq_unpack_X509
In-Reply-To: <00e201d1e34e$ba83f760$2f8be620$@carroll.com>
References: <025d01d1e1b3$9e236390$da6a2ab0$@carroll.com>
 <20160719221001.GA12312@openssl.org>
 <003901d1e2ef$4b530c50$e1f924f0$@carroll.com>
 <9b8c0edfac89463889e7d702724e2ee5@usma1ex-dag1mb1.msg.corp.akamai.com>
 <00e201d1e34e$ba83f760$2f8be620$@carroll.com>
Message-ID: <b54c7abdcf9d4d589ff40e7603228ba4@usma1ex-dag1mb1.msg.corp.akamai.com>


> 	    STACK_OF(X509)* stack = sk_x509_new_null();
> 	    sk_x509_push(stack, cert);
> 	    sk_x509_push(stack, ca);
> 
> 	    return ASN1_seq_pack_X509(stack, i2d_X509, NULL, len_out);

Okay, so your just pushing two DER-format blobs one after the other.
Yes, what you thought to do is fine. :)

From Erwann.Abalea at docusign.com  Thu Jul 21 12:31:56 2016
From: Erwann.Abalea at docusign.com (Erwann Abalea)
Date: Thu, 21 Jul 2016 12:31:56 +0000
Subject: [openssl-users] Openssl software failure for RSA 16K modulus
In-Reply-To: <e8e3f6f5b5a849ab8000dab434aace1d@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <BN3PR07MB246737A3ABB76E4624723C9E97090@BN3PR07MB2467.namprd07.prod.outlook.com>
 <F2A95F8F-BCC8-4EC5-984F-8B77C91BBAA2@docusign.com>
 <f3934079655b4d8fa3328b21ea62ef6f@usma1ex-dag1mb1.msg.corp.akamai.com>
 <e8e3f6f5b5a849ab8000dab434aace1d@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <C1C086D5-5270-4595-8ED6-D6D69DF0C7E1@docusign.com>


> Le 21 juil. 2016 ? 14:17, Salz, Rich <rsalz at akamai.com> a ?crit :
> 
>> We have to make trade-offs.  Who uses a 16K RSA key?
> 
> Let me add some  clarification.  Is it worth putting every application that uses OpenSSL at risk for a DoS attack with a 16K RSA key?

By raising the limit, you don?t suddenly put every application at risk of a DoS, because these applications won?t suddenly use a 16k RSA key.
Anyway, OpenSSL 1.0.2+ now sets some limits on message sizes (defensive), some tradeoffs have to be done on those limits. According to some sources (NIST and ECRYPT II), 16k RSA provides an equivalent security level of a 512bits ECC key.

From rsalz at akamai.com  Thu Jul 21 13:08:52 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 21 Jul 2016 13:08:52 +0000
Subject: [openssl-users] Openssl software failure for RSA 16K modulus
In-Reply-To: <C1C086D5-5270-4595-8ED6-D6D69DF0C7E1@docusign.com>
References: <BN3PR07MB246737A3ABB76E4624723C9E97090@BN3PR07MB2467.namprd07.prod.outlook.com>
 <F2A95F8F-BCC8-4EC5-984F-8B77C91BBAA2@docusign.com>
 <f3934079655b4d8fa3328b21ea62ef6f@usma1ex-dag1mb1.msg.corp.akamai.com>
 <e8e3f6f5b5a849ab8000dab434aace1d@usma1ex-dag1mb1.msg.corp.akamai.com>
 <C1C086D5-5270-4595-8ED6-D6D69DF0C7E1@docusign.com>
Message-ID: <e54921bc7b864c64bda6fd688172240c@usma1ex-dag1mb1.msg.corp.akamai.com>


>By raising the limit, you don?t suddenly put every application at risk of a DoS,
> because these applications won?t suddenly use a 16k RSA key.

Yes we do, because the other side could send a key, not local config.

From jim at carroll.com  Thu Jul 21 13:10:56 2016
From: jim at carroll.com (Jim Carroll)
Date: Thu, 21 Jul 2016 09:10:56 -0400
Subject: [openssl-users]
	Help	finding	replacement	for	ASN1_seq_unpack_X509
In-Reply-To: <b54c7abdcf9d4d589ff40e7603228ba4@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <025d01d1e1b3$9e236390$da6a2ab0$@carroll.com>
 <20160719221001.GA12312@openssl.org>
 <003901d1e2ef$4b530c50$e1f924f0$@carroll.com>
 <9b8c0edfac89463889e7d702724e2ee5@usma1ex-dag1mb1.msg.corp.akamai.com>
 <00e201d1e34e$ba83f760$2f8be620$@carroll.com>
 <b54c7abdcf9d4d589ff40e7603228ba4@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <011b01d1e351$514d94b0$f3e8be10$@carroll.com>

Thanks Rich!

> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
> Behalf Of Salz, Rich
> Sent: Thursday, July 21, 2016 8:57 AM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Help finding replacement for
> ASN1_seq_unpack_X509
> 
> 
> > 	    STACK_OF(X509)* stack = sk_x509_new_null();
> > 	    sk_x509_push(stack, cert);
> > 	    sk_x509_push(stack, ca);
> >
> > 	    return ASN1_seq_pack_X509(stack, i2d_X509, NULL, len_out);
> 
> Okay, so your just pushing two DER-format blobs one after the other.
> Yes, what you thought to do is fine. :)
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


begin 666 smime.p7s
M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$'
M`0``H((.$3""!#8P@@,>H ,"`0("`0$P#08)*H9(AO<-`0$%!0`P;S$+, D&
M`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T($%",28P) 8#500+$QU!9&14
M<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B," &`U4$`Q,9061D5')U<W0@
M17AT97)N86P at 0T$@4F]O=# >%PTP,# U,S Q,#0X,SA:%PTR,# U,S Q,#0X
M,SA:,&\Q"S )!@-5! 83`E-%,10P$@8#500*$PM!9&14<G5S="!!0C$F,"0&
M`U4$"Q,=061D5')U<W0 at 17AT97)N86P at 5%10($YE='=O<FLQ(C @!@-5! ,3
M&4%D9%1R=7-T($5X=&5R;F%L($-!(%)O;W0P@@$B, T&"2J&2(;W#0$!`04`
M`X(!#P`P@@$*`H(!`0"W]QHSYO(`!"TYX$Y;[1^\; _-M?HCML[>FQ$SEZ0I
M3'V3G[U*O)/M`QKCC\_E;5!:UI<IE%J L$EZVRZ5_;C*OS<X+1X^D4&M<%;'
M\$\_Z#*>=,K(D%3IQE\/>)V:0#P.K&&J7A2/GH>A:E#<UYI.KP6SIG&4G'&S
M4& *QQ.=. >&`JCIJ&DF&)"K3+!/(ZLZ3X38W\Z?X6EON]="UVM$Y,>M[FU!
M7W):<0 at WLWEEI%F at E#?W`"\-PI)RVM X<ML4J$7$72I]M[36Q.ZLS1-$M\DK
MW4,`)?IAN6EJ6",1MZ<SCU9U6?7-*==&MPHK9;;30F\5LKA[^^_I75/5-%HG
M`@,!``&C@=PP@=DP'08#51T.!!8$%*V]F'HTM";W^L0F5.\#O> DRU0:, L&
M`U4=#P0$`P(!!C /!@-5'1,!`?\$!3 #`0'_,(&9!@-5'2,$@9$P at 8Z %*V]
MF'HTM";W^L0F5.\#O> DRU0:H7.D<3!O,0LP"08#500&$P)313$4,!(&`U4$
M"A,+061D5')U<W0 at 04(Q)C D!@-5! L3'4%D9%1R=7-T($5X=&5R;F%L(%14
M4"!.971W;W)K,2(P( 8#500#$QE!9&14<G5S="!%>'1E<FYA;"!#02!2;V]T
M@@$!, T&"2J&2(;W#0$!!04``X(!`0"PF^"%)<+6(^(/E@:2G4&8G-F$>8'9
M'EL4!R,V98^PV'>[K$%L1V"#4;#Y,CWG_/8F$\> %J6_6OR'SWAYB2&:XDP'
M"H8UO/+>4<32EK?<?D[N</T<.>L,`E$4+8Z]%N#!WT9UYR2M[/1"M(63<!!G
MNIT&-4H8TRMZS%%"H7ICT>:[H<4KPC:^$PWFO6-^>7NG"0U JVK=CXK#]O:,
M&D(%4=1%]9^G8B%H%2!#/)GG?+TDV*F1%W.(/U8;,3 at 8M'$/FLW(#IZ.+AOA
MC)B#RQ\Q\41,Q at 1S279@#\?XO1> :R[IS$P.6IIY#R *+M6>8R8>59*4V((7
M6GO0O,>/3H8$,(($KS""`Y>@`P(!`@(1`. CRQ42 at U.)K6%N>E1G:R$P#08)
M*H9(AO<-`0$+!0`P;S$+, D&`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T
M($%",28P) 8#500+$QU!9&14<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B
M," &`U4$`Q,9061D5')U<W0 at 17AT97)N86P at 0T$@4F]O=# >%PTQ-#$R,C(P
M,# P,#!:%PTR,# U,S Q,#0X,SA:,(&;,0LP"08#500&$P)'0C$;,!D&`U4$
M"!,21W)E871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#
M500*$Q%#3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR
M-38 at 0VQI96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$P
M@@$B, T&"2J&2(;W#0$!`04``X(!#P`P@@$*`H(!`0")L0W:>E,93G!2';Q6
MI at 8FM[A)X);G4:OQ\%H3216CM(P;8+QZ44*G>8RD(M\784Z1U78C"A332@)_
MMAT)@&ZE!#W9NKL6_J&'J2Y#4D,6?*\R4,BF3UKI"-C/DR6<>XCH,&3FI/A6
M@/TJ)!0S%YFL1.5IBZ-&!DO",]3I0)\&L+&LDT"YM0B3.IPJ4Z,0VST at 83Q5
M`X[93G8E`B$I^J-\<79/[N%?@>G[5(#;PWLU4K>$WB(]+# M,7]9O5(WL#-I
M+4/K^M:E\9=W9U&,V>XGZ[RE!SAVC*2I./_?C/4#K$F^RO=SF3H/,JN<E3H3
M/0Y&.E=T85"^QD _R^3BGZ(A`@,!``&C@@$7,((!$S ?!@-5'2,$&# 6@!2M
MO9AZ-+0F]_K$)E3O`[W@),M4&C =!@-5'0X$%@04DF%K at N&BH*I/[&?QPJ/W
MM( `P>PP#@8#51T/`0'_! 0#`@&&,!(&`U4=$P$!_P0(, 8!`?\"`0`P'08#
M51TE!!8P% 8(*P8!!04'`P(&""L&`04%!P,$,!$&`U4=( 0*, @P!@8$51T@
M`#!$!@-5'1\$/3 [,#F at -Z UAC-H='1P.B\O8W)L+G5S97)T<G5S="YC;VTO
M061D5')U<W1%>'1E<FYA;$-!4F]O="YC<FPP-08(*P8!!04'`0$$*3 G,"4&
M""L&`04%!S !AAEH='1P.B\O;V-S<"YU<V5R=')U<W0N8V]M, T&"2J&2(;W
M#0$!"P4``X(!`0`;*FZL5<$ZJXC%V.W-5?.J:V$KP D0(YD/Q69J;['UM+5W
M7@\"80#??07^$K.D@( `_/L=6VIR`@I!O 6ZP5C5)L+JU4V$^_Z"F,]8&^,B
M8YQ2^+L%-JM]6*7>JSMCY=K5<^_LX/M[XJ/_\$(CG,JVC4T^Y$L8`[*H+=38
MNT)+D&F%$-NF-S3H>^ !$*6<RCK'GT^(-&Z*9= :BKNIW,K*-M'T_,)D*36O
MUK&G<1'2`T.QCSZ:[)XR4_1VDLJ&- >Y+,KF'$K8F0W!AN*0DOM:0FHC(1#I
M9<?UU;M^ZHR%( )BZM$Z!RQ9Q9DS\CB)Y;;I%GH?>13V2A :)OI\BON;,((%
M(#""! B@`P(!`@(1`-4+#]T2278FC)\!=Y87SN8P#08)*H9(AO<-`0$+!0`P
M at 9LQ"S )!@-5! 83`D=",1LP&08#500($Q)'<F5A=&5R($UA;F-H97-T97(Q
M$# .!@-5! <3!U-A;&9O<F0Q&C 8!@-5! H3$4-/34]$3R!#02!,:6UI=&5D
M,4$P/P8#500#$SA#3TU/1$\@4TA!+3(U-B!#;&EE;G0 at 075T:&5N=&EC871I
M;VX at 86YD(%-E8W5R92!%;6%I;"!#03 >%PTQ-C Q,3,P,# P,#!:%PTQ-S Q
M,3(R,S4Y-3E:," Q'C <!@DJADB&]PT!"0$6#VII;4!C87)R;VQL+F-O;3""
M`2(P#08)*H9(AO<-`0$!!0`#@@$/`#""`0H"@@$!`-K\XS'GF('[$TPZLMT=
MY]ID(UGI at 9^?K.$F3&?)JS.0Q"6)OD@;8S<+1#[2QFG.S045<BKJ-D6O9FQ\
M<*2_A$&HWT6R`S' 7$<4M7HIO_"G at U#-`1,6W2HZ`,L53(EL?:P_[H%Y/6VB
MJU\01/0U<U7T/"K$+CFK\>HV/H^"EPS!W)_L#3<"[3T(BZ3LDTHN"#(\B5A1
M^VO2XN77=+Z\+IU=@1UR!40:,<7&)5,P,O1STRE:UFFYLS65=GVT*:ZY[YK9
M':(_+75)?UCOJQ: M-%=9XH<_VNPXG^;7/:6"2-DDFNH3JMIBVKH$1G/E$ 9
MD8XE<3>#8^@.89*P$#)O+'$"`P$``:."`=<P@@'3,!\&`U4=(P08,!: %))A
M:X+AHJ"J3^QG\<*C][2 `,'L,!T&`U4=#@06!!0P:UC0J,N<!7>SB(9<*/G'
MV*_ SS .!@-5'0\!`?\$! ,"!: P# 8#51T3`0'_! (P`# =!@-5'24$%C 4
M!@@K!@$%!0<#! 8(*P8!!04'`P(P1 at 8#51T@!#\P/3 [!@PK!@$$`;(Q`0(!
M`P4P*S I!@@K!@$%!0<"`18=:'1T<',Z+R]S96-U<F4N8V]M;V1O+FYE="]#
M4%,P708#51T?!%8P5#!2H%"@3H9,:'1T<#HO+V-R;"YC;VUO9&]C82YC;VTO
M0T]-3T1/4TA!,C4V0VQI96YT075T:&5N=&EC871I;VYA;F1396-U<F5%;6%I
M;$-!+F-R;#"!D 8(*P8!!04'`0$$@8,P at 8 P6 8(*P8!!04', *&3&AT=' Z
M+R]C<G0N8V]M;V1O8V$N8V]M+T-/34]$3U-(03(U-D-L:65N=$%U=&AE;G1I
M8V%T:6]N86YD4V5C=7)E16UA:6Q#02YC<G0P) 8(*P8!!04', &&&&AT=' Z
M+R]O8W-P+F-O;6]D;V-A+F-O;3 :!@-5'1$$$S 1 at 0]J:6U 8V%R<F]L;"YC
M;VTP#08)*H9(AO<-`0$+!0`#@@$!`&7_YE!"6I-N>DE*'QH34=CM%+[K`1M]
M]CL[U/FRY5[^LX>0V\F[3S&JAG>8?S4(\8%YC7"@FZN?&[XNG;*71FB1VC5\
M[C at 1T1/1VFB^.U_DY "31W;:;K"NZ]K)Q3#HO(@&45E,YCJ!NY$AC!C\IGQ:
M2/NGP"_K'85*^(.K.&Q*INS)?2E26GN'Y^%BLAID at HA<[DL&']YY*Z 9#&;V
MFJ3HYV^Y[HF)FFH-]D/]<5G):'.LJD*"]IJWI4,'-BQ;060E4[7[NKAN!^P\
MBTU&T;&8EQ; '\I'[_^.1-;+K'J.:_]/&2]A0 at L9SC^8NO*8S_4,>"4TRIOH
MI'J>$[1$P4TQ@@0C,(($'P(!`3"!L3"!FS$+, D&`U4$!A,"1T(Q&S 9!@-5
M! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'4V%L9F]R9#$:,!@&
M`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3.$-/34]$3R!32$$M
M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C=7)E($5M86EL($-!
M`A$`U0L/W1))=B:,GP%WEA?.YC )!@4K#@,"&@4`H(("1C 8!@DJADB&]PT!
M"0,Q"P8)*H9(AO<-`0<!,!P&"2J&2(;W#0$)!3$/%PTQ-C W,C$Q,S$P-35:
M,",&"2J&2(;W#0$)!#$6!!1,4O^@E[W0Q.J0I91]GOO6+(X*IS!;!@DJADB&
M]PT!"0\Q3C!,, H&""J&2(;W#0,', X&""J&2(;W#0,"`@(`@# -!@@JADB&
M]PT#`@(!0# '!@4K#@,"!S -!@@JADB&]PT#`@(!*# '!@4K#@,"&C"!P at 8)
M*P8!! &"-Q $,8&T,(&Q,(&;,0LP"08#500&$P)'0C$;,!D&`U4$"!,21W)E
M871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#500*$Q%#
M3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR-38 at 0VQI
M96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$"$0#5"P_=
M$DEV)HR?`7>6%\[F,('$!@LJADB&]PT!"1 ""S&!M*"!L3"!FS$+, D&`U4$
M!A,"1T(Q&S 9!@-5! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'
M4V%L9F]R9#$:,!@&`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3
M.$-/34]$3R!32$$M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C
M=7)E($5M86EL($-!`A$`U0L/W1))=B:,GP%WEA?.YC -!@DJADB&]PT!`0$%
M``2"`0"9][+'5&D@]![]4),$=R'^69M(Q)60#7>(K\1-16I%G1J3O^)+;0>"
M4IYH;/-X%UV\6 E0J9PQ3BGH9 *:,PX--7:#=#KFY\V%$)16HWJQ:@:5BL).
MO93=!;X$_+<-J'K?]HCMMJ%_%#]EUBY1\@]O*<F?4VFD&[.1J/.%G^OC07:'
M$: B\T#>"%09UDTZM=<LW%:?R'#Y^J8- at -PD`AGNX#Z%%"!5*NG,TZSD>P_"
M2&D[Z=^DH++;>$#G5] #8CUHP7'*TG'O" ?I")VG2P88EDD.S>U>OMX>M 55
J8O!7V.8Q6HQ^R08Z(;"3'!\Z`T8>,9H;RZ>)]Q84^?@49B5H````````
`
end


From rsalz at akamai.com  Thu Jul 21 13:16:11 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 21 Jul 2016 13:16:11 +0000
Subject: [openssl-users]
	Help	finding	replacement	for	ASN1_seq_unpack_X509
In-Reply-To: <011b01d1e351$514d94b0$f3e8be10$@carroll.com>
References: <025d01d1e1b3$9e236390$da6a2ab0$@carroll.com>
 <20160719221001.GA12312@openssl.org>
 <003901d1e2ef$4b530c50$e1f924f0$@carroll.com>
 <9b8c0edfac89463889e7d702724e2ee5@usma1ex-dag1mb1.msg.corp.akamai.com>
 <00e201d1e34e$ba83f760$2f8be620$@carroll.com>
 <b54c7abdcf9d4d589ff40e7603228ba4@usma1ex-dag1mb1.msg.corp.akamai.com>
 <011b01d1e351$514d94b0$f3e8be10$@carroll.com>
Message-ID: <0e38c0d449234ab4a2826eb2bd2c6d3b@usma1ex-dag1mb1.msg.corp.akamai.com>

> Thanks Rich!

You're welcome.  Getting M2Crypto moved to 1.1 is a *great* project.  Thanks.

--  
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz



From steve at openssl.org  Thu Jul 21 13:52:38 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 21 Jul 2016 13:52:38 +0000
Subject: [openssl-users] Help finding replacement
	for	ASN1_seq_unpack_X509
In-Reply-To: <003901d1e2ef$4b530c50$e1f924f0$@carroll.com>
References: <025d01d1e1b3$9e236390$da6a2ab0$@carroll.com>
 <20160719221001.GA12312@openssl.org>
 <003901d1e2ef$4b530c50$e1f924f0$@carroll.com>
Message-ID: <20160721135238.GA20163@openssl.org>

On Wed, Jul 20, 2016, Jim Carroll wrote:

> Thanks much....I have a corollary question if you don't mind.  In OpenSSL
> 1.1.0, what is the accepted procedure to convert a STACK_OF(X509) to DER?
> 

It depends on what you mean by "to DER" and what the other ends is expecting.

The code snipped I suggested will do that: if you call i2d_SEQ_CERT (or
whatever you called it) that will work. That wraps the whole lot in a SEQUENCE
header which is the same as the original. That is it is a SEQUENCE OF X509.

> Would it be acceptable to just iterate the stack elements, passing each X509
> through i2d_X509 and appending the results -- would that generate valid DER?
> Is there a better way?
> 

It depends on what the other side expects. If you just do that that and EOF
signals the and of the last certificate you'll be fine. If you append
additional data afterwards then you need to mark the last certificate somehow.
The certificate sequence version prepends the data with the length of all the
certificates so it automatically handles that.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From steve at openssl.org  Thu Jul 21 13:54:05 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 21 Jul 2016 13:54:05 +0000
Subject: [openssl-users]
	Help	finding	replacement	for	ASN1_seq_unpack_X509
In-Reply-To: <b54c7abdcf9d4d589ff40e7603228ba4@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <025d01d1e1b3$9e236390$da6a2ab0$@carroll.com>
 <20160719221001.GA12312@openssl.org>
 <003901d1e2ef$4b530c50$e1f924f0$@carroll.com>
 <9b8c0edfac89463889e7d702724e2ee5@usma1ex-dag1mb1.msg.corp.akamai.com>
 <00e201d1e34e$ba83f760$2f8be620$@carroll.com>
 <b54c7abdcf9d4d589ff40e7603228ba4@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20160721135405.GB20163@openssl.org>

On Thu, Jul 21, 2016, Salz, Rich wrote:

> 
> > 	    STACK_OF(X509)* stack = sk_x509_new_null();
> > 	    sk_x509_push(stack, cert);
> > 	    sk_x509_push(stack, ca);
> > 
> > 	    return ASN1_seq_pack_X509(stack, i2d_X509, NULL, len_out);
> 
> Okay, so your just pushing two DER-format blobs one after the other.
> Yes, what you thought to do is fine. :)

Actually that is including a SEQUENCE header and not just the DER blobs. So if
the result must be compatible with the original format the snippet I suggested
would be appropriate here.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From Saurabh.Gupta at cavium.com  Thu Jul 21 14:00:26 2016
From: Saurabh.Gupta at cavium.com (Gupta, Saurabh)
Date: Thu, 21 Jul 2016 14:00:26 +0000
Subject: [openssl-users] Openssl software failure for RSA 16K modulus
In-Reply-To: <mailman.5431.1469106535.1746.openssl-users@openssl.org>
References: <mailman.5431.1469106535.1746.openssl-users@openssl.org>
Message-ID: <BN3PR07MB2467BA46C774A5A3E9A0D6D097090@BN3PR07MB2467.namprd07.prod.outlook.com>

> By raising the limit, you don't suddenly put every application at risk of a DoS,
> because these applications won't suddenly use a 16k RSA key.


Instead of raising the limit of client key exchange message length more than 2048, why can't we add the

"ssl3_check_client_hello" functionality in the ssl/s3_srvr.c because that will "permit appropriate message length".


I came across this functionality when I compared the code of openssl-1.0.1p and openssl-1.0.2e.


Regards,
Saurabh


________________________________
From: openssl-users <openssl-users-bounces at openssl.org> on behalf of openssl-users-request at openssl.org <openssl-users-request at openssl.org>
Sent: Thursday, July 21, 2016 6:38 PM
To: openssl-users at openssl.org
Subject: openssl-users Digest, Vol 20, Issue 18

Send openssl-users mailing list submissions to
        openssl-users at openssl.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
        openssl-users-request at openssl.org

You can reach the person managing the list at
        openssl-users-owner at openssl.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."


Today's Topics:

   1. Re: Openssl software failure for RSA 16K modulus (Salz, Rich)
   2. Re: Openssl software failure for RSA 16K modulus (Salz, Rich)
   3. Re: Help  finding replacement     for     ASN1_seq_unpack_X509
      (Jim Carroll)
   4. Re: [openssl-users]       Help    finding replacement     for
      ASN1_seq_unpack_X509 (Salz, Rich)
   5. Re: Openssl software failure for RSA 16K modulus (Erwann Abalea)
   6. Re: Openssl software failure for RSA 16K modulus (Salz, Rich)


----------------------------------------------------------------------

Message: 1
Date: Thu, 21 Jul 2016 12:15:15 +0000
From: "Salz, Rich" <rsalz at akamai.com>
To: "openssl-users at openssl.org" <openssl-users at openssl.org>
Subject: Re: [openssl-users] Openssl software failure for RSA 16K
        modulus
Message-ID:
        <f3934079655b4d8fa3328b21ea62ef6f at usma1ex-dag1mb1.msg.corp.akamai.com>
Content-Type: text/plain; charset="Windows-1252"


> Largest accepted client key exchange message length seems to be set to 2048 bytes.
> Key exchange for an RSA16k is slightly larger than that (exactly 2048 bytes of pure crypto payload, plus a few bytes of overhead).

> OpenSSL is too conservative here.

Why not use an ECC key?

We have to make trade-offs.  Who uses a 16K RSA key?


------------------------------

Message: 2
Date: Thu, 21 Jul 2016 12:17:44 +0000
From: "Salz, Rich" <rsalz at akamai.com>
To: "openssl-users at openssl.org" <openssl-users at openssl.org>
Subject: Re: [openssl-users] Openssl software failure for RSA 16K
        modulus
Message-ID:
        <e8e3f6f5b5a849ab8000dab434aace1d at usma1ex-dag1mb1.msg.corp.akamai.com>
Content-Type: text/plain; charset="Windows-1252"

> We have to make trade-offs.  Who uses a 16K RSA key?

Let me add some  clarification.  Is it worth putting every application that uses OpenSSL at risk for a DoS attack with a 16K RSA key?

--
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz




------------------------------

Message: 3
Date: Thu, 21 Jul 2016 08:52:24 -0400
From: "Jim Carroll" <jim at carroll.com>
To: <openssl-users at openssl.org>
Subject: Re: [openssl-users] Help       finding replacement     for
        ASN1_seq_unpack_X509
Message-ID: <00e201d1e34e$ba83f760$2f8be620$@carroll.com>

 We are porting M2Crypto which is a python swig wrapper around OpenSSL. It
currently supports OpenSSL 0.9.8 and we are porting it to 1.1.0.  The 1.1.0
branch is really cool (clean, elegant code), but there were a few
refactoring's that affected M2Crypto.  Most were trivial getter/setter type
changes, but a few were in the are of getting rid of some ASN1 processing
(which happens to be our weakest point of understanding).

We're left with porting the final bit -- which is related to X509 cert
handling.  Here's a sample use. The caller builds up the call with a the
following 'psuedo-sequence'. get_der() is the function we are working on
finishing.

        X508* load_cert_bio(char* filename) {
            BIO* bio = BIO_new_file(filename, "r");
            return PEM_read_bio_X509(bio, NULL, NULL, NULL);
            }

        unsigned char* get_der(int* len_out) {
            X509* cert = load_cert_bio("x509.pem");
            X509* ca = load_cert_bio("ca.pem");

            STACK_OF(X509)* stack = sk_x509_new_null();
            sk_x509_push(stack, cert);
            sk_x509_push(stack, ca);

            return ASN1_seq_pack_X509(stack, i2d_X509, NULL, len_out);
            }

The ASN1_seq_pack_X509 was a macro -- and has been removed.


> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
> Behalf Of Salz, Rich
> Sent: Thursday, July 21, 2016 4:35 AM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Help finding replacement for
> ASN1_seq_unpack_X509
>
> > Would it be acceptable to just iterate the stack elements, passing
> each X509
> > through i2d_X509 and appending the results -- would that generate
> valid
> > DER?
>
> Maybe.  It depends on what the receiver is expecting.  If it's willing
> to read a set of certs until it hits EOF (or equivalent) that's fine.
> But if you're sending a SEQUENCE OF certificates then you need to wrap
> it in an ASN1/DER container. For example, Netscape Cert Sequence
>
> Can you post a code snippet?
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


begin 666 smime.p7s
M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$'
M`0``H((.$3""!#8P@@,>H ,"`0("`0$P#08)*H9(AO<-`0$%!0`P;S$+, D&
M`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T($%",28P) 8#500+$QU!9&14
M<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B," &`U4$`Q,9061D5')U<W0@
M17AT97)N86P at 0T$@4F]O=# >%PTP,# U,S Q,#0X,SA:%PTR,# U,S Q,#0X
M,SA:,&\Q"S )!@-5! 83`E-%,10P$@8#500*$PM!9&14<G5S="!!0C$F,"0&
M`U4$"Q,=061D5')U<W0 at 17AT97)N86P at 5%10($YE='=O<FLQ(C @!@-5! ,3
M&4%D9%1R=7-T($5X=&5R;F%L($-!(%)O;W0P@@$B, T&"2J&2(;W#0$!`04`
M`X(!#P`P@@$*`H(!`0"W]QHSYO(`!"TYX$Y;[1^\; _-M?HCML[>FQ$SEZ0I
M3'V3G[U*O)/M`QKCC\_E;5!:UI<IE%J L$EZVRZ5_;C*OS<X+1X^D4&M<%;'
M\$\_Z#*>=,K(D%3IQE\/>)V:0#P.K&&J7A2/GH>A:E#<UYI.KP6SIG&4G'&S
M4& *QQ.=. >&`JCIJ&DF&)"K3+!/(ZLZ3X38W\Z?X6EON]="UVM$Y,>M[FU!
M7W):<0 at WLWEEI%F at E#?W`"\-PI)RVM X<ML4J$7$72I]M[36Q.ZLS1-$M\DK
MW4,`)?IAN6EJ6",1MZ<SCU9U6?7-*==&MPHK9;;30F\5LKA[^^_I75/5-%HG
M`@,!``&C@=PP@=DP'08#51T.!!8$%*V]F'HTM";W^L0F5.\#O> DRU0:, L&
M`U4=#P0$`P(!!C /!@-5'1,!`?\$!3 #`0'_,(&9!@-5'2,$@9$P at 8Z %*V]
MF'HTM";W^L0F5.\#O> DRU0:H7.D<3!O,0LP"08#500&$P)313$4,!(&`U4$
M"A,+061D5')U<W0 at 04(Q)C D!@-5! L3'4%D9%1R=7-T($5X=&5R;F%L(%14
M4"!.971W;W)K,2(P( 8#500#$QE!9&14<G5S="!%>'1E<FYA;"!#02!2;V]T
M@@$!, T&"2J&2(;W#0$!!04``X(!`0"PF^"%)<+6(^(/E@:2G4&8G-F$>8'9
M'EL4!R,V98^PV'>[K$%L1V"#4;#Y,CWG_/8F$\> %J6_6OR'SWAYB2&:XDP'
M"H8UO/+>4<32EK?<?D[N</T<.>L,`E$4+8Z]%N#!WT9UYR2M[/1"M(63<!!G
MNIT&-4H8TRMZS%%"H7ICT>:[H<4KPC:^$PWFO6-^>7NG"0U JVK=CXK#]O:,
M&D(%4=1%]9^G8B%H%2!#/)GG?+TDV*F1%W.(/U8;,3 at 8M'$/FLW(#IZ.+AOA
MC)B#RQ\Q\41,Q at 1S279@#\?XO1> :R[IS$P.6IIY#R *+M6>8R8>59*4V((7
M6GO0O,>/3H8$,(($KS""`Y>@`P(!`@(1`. CRQ42 at U.)K6%N>E1G:R$P#08)
M*H9(AO<-`0$+!0`P;S$+, D&`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T
M($%",28P) 8#500+$QU!9&14<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B
M," &`U4$`Q,9061D5')U<W0 at 17AT97)N86P at 0T$@4F]O=# >%PTQ-#$R,C(P
M,# P,#!:%PTR,# U,S Q,#0X,SA:,(&;,0LP"08#500&$P)'0C$;,!D&`U4$
M"!,21W)E871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#
M500*$Q%#3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR
M-38 at 0VQI96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$P
M@@$B, T&"2J&2(;W#0$!`04``X(!#P`P@@$*`H(!`0")L0W:>E,93G!2';Q6
MI at 8FM[A)X);G4:OQ\%H3216CM(P;8+QZ44*G>8RD(M\784Z1U78C"A332@)_
MMAT)@&ZE!#W9NKL6_J&'J2Y#4D,6?*\R4,BF3UKI"-C/DR6<>XCH,&3FI/A6
M@/TJ)!0S%YFL1.5IBZ-&!DO",]3I0)\&L+&LDT"YM0B3.IPJ4Z,0VST at 83Q5
M`X[93G8E`B$I^J-\<79/[N%?@>G[5(#;PWLU4K>$WB(]+# M,7]9O5(WL#-I
M+4/K^M:E\9=W9U&,V>XGZ[RE!SAVC*2I./_?C/4#K$F^RO=SF3H/,JN<E3H3
M/0Y&.E=T85"^QD _R^3BGZ(A`@,!``&C@@$7,((!$S ?!@-5'2,$&# 6@!2M
MO9AZ-+0F]_K$)E3O`[W@),M4&C =!@-5'0X$%@04DF%K at N&BH*I/[&?QPJ/W
MM( `P>PP#@8#51T/`0'_! 0#`@&&,!(&`U4=$P$!_P0(, 8!`?\"`0`P'08#
M51TE!!8P% 8(*P8!!04'`P(&""L&`04%!P,$,!$&`U4=( 0*, @P!@8$51T@
M`#!$!@-5'1\$/3 [,#F at -Z UAC-H='1P.B\O8W)L+G5S97)T<G5S="YC;VTO
M061D5')U<W1%>'1E<FYA;$-!4F]O="YC<FPP-08(*P8!!04'`0$$*3 G,"4&
M""L&`04%!S !AAEH='1P.B\O;V-S<"YU<V5R=')U<W0N8V]M, T&"2J&2(;W
M#0$!"P4``X(!`0`;*FZL5<$ZJXC%V.W-5?.J:V$KP D0(YD/Q69J;['UM+5W
M7@\"80#??07^$K.D@( `_/L=6VIR`@I!O 6ZP5C5)L+JU4V$^_Z"F,]8&^,B
M8YQ2^+L%-JM]6*7>JSMCY=K5<^_LX/M[XJ/_\$(CG,JVC4T^Y$L8`[*H+=38
MNT)+D&F%$-NF-S3H>^ !$*6<RCK'GT^(-&Z*9= :BKNIW,K*-M'T_,)D*36O
MUK&G<1'2`T.QCSZ:[)XR4_1VDLJ&- >Y+,KF'$K8F0W!AN*0DOM:0FHC(1#I
M9<?UU;M^ZHR%( )BZM$Z!RQ9Q9DS\CB)Y;;I%GH?>13V2A :)OI\BON;,((%
M(#""! B@`P(!`@(1`-4+#]T2278FC)\!=Y87SN8P#08)*H9(AO<-`0$+!0`P
M at 9LQ"S )!@-5! 83`D=",1LP&08#500($Q)'<F5A=&5R($UA;F-H97-T97(Q
M$# .!@-5! <3!U-A;&9O<F0Q&C 8!@-5! H3$4-/34]$3R!#02!,:6UI=&5D
M,4$P/P8#500#$SA#3TU/1$\@4TA!+3(U-B!#;&EE;G0 at 075T:&5N=&EC871I
M;VX at 86YD(%-E8W5R92!%;6%I;"!#03 >%PTQ-C Q,3,P,# P,#!:%PTQ-S Q
M,3(R,S4Y-3E:," Q'C <!@DJADB&]PT!"0$6#VII;4!C87)R;VQL+F-O;3""
M`2(P#08)*H9(AO<-`0$!!0`#@@$/`#""`0H"@@$!`-K\XS'GF('[$TPZLMT=
MY]ID(UGI at 9^?K.$F3&?)JS.0Q"6)OD@;8S<+1#[2QFG.S045<BKJ-D6O9FQ\
M<*2_A$&HWT6R`S' 7$<4M7HIO_"G at U#-`1,6W2HZ`,L53(EL?:P_[H%Y/6VB
MJU\01/0U<U7T/"K$+CFK\>HV/H^"EPS!W)_L#3<"[3T(BZ3LDTHN"#(\B5A1
M^VO2XN77=+Z\+IU=@1UR!40:,<7&)5,P,O1STRE:UFFYLS65=GVT*:ZY[YK9
M':(_+75)?UCOJQ: M-%=9XH<_VNPXG^;7/:6"2-DDFNH3JMIBVKH$1G/E$ 9
MD8XE<3>#8^@.89*P$#)O+'$"`P$``:."`=<P@@'3,!\&`U4=(P08,!: %))A
M:X+AHJ"J3^QG\<*C][2 `,'L,!T&`U4=#@06!!0P:UC0J,N<!7>SB(9<*/G'
MV*_ SS .!@-5'0\!`?\$! ,"!: P# 8#51T3`0'_! (P`# =!@-5'24$%C 4
M!@@K!@$%!0<#! 8(*P8!!04'`P(P1 at 8#51T@!#\P/3 [!@PK!@$$`;(Q`0(!
M`P4P*S I!@@K!@$%!0<"`18=:'1T<',Z+R]S96-U<F4N8V]M;V1O+FYE="]#
M4%,P708#51T?!%8P5#!2H%"@3H9,:'1T<#HO+V-R;"YC;VUO9&]C82YC;VTO
M0T]-3T1/4TA!,C4V0VQI96YT075T:&5N=&EC871I;VYA;F1396-U<F5%;6%I
M;$-!+F-R;#"!D 8(*P8!!04'`0$$@8,P at 8 P6 8(*P8!!04', *&3&AT=' Z
M+R]C<G0N8V]M;V1O8V$N8V]M+T-/34]$3U-(03(U-D-L:65N=$%U=&AE;G1I
M8V%T:6]N86YD4V5C=7)E16UA:6Q#02YC<G0P) 8(*P8!!04', &&&&AT=' Z
M+R]O8W-P+F-O;6]D;V-A+F-O;3 :!@-5'1$$$S 1 at 0]J:6U 8V%R<F]L;"YC
M;VTP#08)*H9(AO<-`0$+!0`#@@$!`&7_YE!"6I-N>DE*'QH34=CM%+[K`1M]
M]CL[U/FRY5[^LX>0V\F[3S&JAG>8?S4(\8%YC7"@FZN?&[XNG;*71FB1VC5\
M[C at 1T1/1VFB^.U_DY "31W;:;K"NZ]K)Q3#HO(@&45E,YCJ!NY$AC!C\IGQ:
M2/NGP"_K'85*^(.K.&Q*INS)?2E26GN'Y^%BLAID at HA<[DL&']YY*Z 9#&;V
MFJ3HYV^Y[HF)FFH-]D/]<5G):'.LJD*"]IJWI4,'-BQ;060E4[7[NKAN!^P\
MBTU&T;&8EQ; '\I'[_^.1-;+K'J.:_]/&2]A0 at L9SC^8NO*8S_4,>"4TRIOH
MI'J>$[1$P4TQ@@0C,(($'P(!`3"!L3"!FS$+, D&`U4$!A,"1T(Q&S 9!@-5
M! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'4V%L9F]R9#$:,!@&
M`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3.$-/34]$3R!32$$M
M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C=7)E($5M86EL($-!
M`A$`U0L/W1))=B:,GP%WEA?.YC )!@4K#@,"&@4`H(("1C 8!@DJADB&]PT!
M"0,Q"P8)*H9(AO<-`0<!,!P&"2J&2(;W#0$)!3$/%PTQ-C W,C$Q,C4R,C1:
M,",&"2J&2(;W#0$)!#$6!!1G&[GL6/=H8LZE9M4)L7L&;?<.K#!;!@DJADB&
M]PT!"0\Q3C!,, H&""J&2(;W#0,', X&""J&2(;W#0,"`@(`@# -!@@JADB&
M]PT#`@(!0# '!@4K#@,"!S -!@@JADB&]PT#`@(!*# '!@4K#@,"&C"!P at 8)
M*P8!! &"-Q $,8&T,(&Q,(&;,0LP"08#500&$P)'0C$;,!D&`U4$"!,21W)E
M871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#500*$Q%#
M3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR-38 at 0VQI
M96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$"$0#5"P_=
M$DEV)HR?`7>6%\[F,('$!@LJADB&]PT!"1 ""S&!M*"!L3"!FS$+, D&`U4$
M!A,"1T(Q&S 9!@-5! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'
M4V%L9F]R9#$:,!@&`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3
M.$-/34]$3R!32$$M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C
M=7)E($5M86EL($-!`A$`U0L/W1))=B:,GP%WEA?.YC -!@DJADB&]PT!`0$%
M``2"`0"BA-SZ*7/VI,VOREMEIW/;NJ!T.(Q,&_+LZM3[,K57Q>;>/_E:B,?4
MK5#@,W&"P\/'6&9N(0O:&\E9$LLW&L4A&HFUP*--6&QWBNO"Q&@@SIXKRKY!
M_1ADXBJEW(_'N=2L<O%!9/VQ^P]?>'::Q/1SE_GHOFK1&0]"5Q.5WG@#>A65
MB(_+) A!06%L^,:81&8%&!ZR+=BE5G.6@!ENZ? 9F%CZ(<"+? HBSP6%VV8?
MTAS31B5,U\:SOL4_RM%C>8G1EAU^KEX8F\F8/,E_>XVZIV_ at N7TL:@M3&I0Q
J=3SK\27,?_:X'&P\D7 at _/_32#280-K>N"UZHE-(Y;\OR3/=C````````
`
end



------------------------------

Message: 4
Date: Thu, 21 Jul 2016 12:57:09 +0000
From: "Salz, Rich" <rsalz at akamai.com>
To: "openssl-users at openssl.org" <openssl-users at openssl.org>
Subject: Re: [openssl-users]    Help    finding replacement     for
        ASN1_seq_unpack_X509
Message-ID:
        <b54c7abdcf9d4d589ff40e7603228ba4 at usma1ex-dag1mb1.msg.corp.akamai.com>
Content-Type: text/plain; charset="Windows-1252"


>            STACK_OF(X509)* stack = sk_x509_new_null();
>            sk_x509_push(stack, cert);
>            sk_x509_push(stack, ca);
>
>            return ASN1_seq_pack_X509(stack, i2d_X509, NULL, len_out);

Okay, so your just pushing two DER-format blobs one after the other.
Yes, what you thought to do is fine. :)


------------------------------

Message: 5
Date: Thu, 21 Jul 2016 12:31:56 +0000
From: Erwann Abalea <Erwann.Abalea at docusign.com>
To: "openssl-users at openssl.org" <openssl-users at openssl.org>
Subject: Re: [openssl-users] Openssl software failure for RSA 16K
        modulus
Message-ID: <C1C086D5-5270-4595-8ED6-D6D69DF0C7E1 at docusign.com>
Content-Type: text/plain; charset="utf-8"


> Le 21 juil. 2016 ? 14:17, Salz, Rich <rsalz at akamai.com> a ?crit :
>
>> We have to make trade-offs.  Who uses a 16K RSA key?
>
> Let me add some  clarification.  Is it worth putting every application that uses OpenSSL at risk for a DoS attack with a 16K RSA key?

By raising the limit, you don?t suddenly put every application at risk of a DoS, because these applications won?t suddenly use a 16k RSA key.
Anyway, OpenSSL 1.0.2+ now sets some limits on message sizes (defensive), some tradeoffs have to be done on those limits. According to some sources (NIST and ECRYPT II), 16k RSA provides an equivalent security level of a 512bits ECC key.

------------------------------

Message: 6
Date: Thu, 21 Jul 2016 13:08:52 +0000
From: "Salz, Rich" <rsalz at akamai.com>
To: "openssl-users at openssl.org" <openssl-users at openssl.org>
Subject: Re: [openssl-users] Openssl software failure for RSA 16K
        modulus
Message-ID:
        <e54921bc7b864c64bda6fd688172240c at usma1ex-dag1mb1.msg.corp.akamai.com>
Content-Type: text/plain; charset="utf-8"


>By raising the limit, you don?t suddenly put every application at risk of a DoS,
> because these applications won?t suddenly use a 16k RSA key.

Yes we do, because the other side could send a key, not local config.

------------------------------

Subject: Digest Footer

_______________________________________________
openssl-users mailing list
openssl-users at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-users


------------------------------

End of openssl-users Digest, Vol 20, Issue 18
*********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160721/8adbeccb/attachment-0001.html>

From cheyendal at fortinet.com  Thu Jul 21 14:03:10 2016
From: cheyendal at fortinet.com (Carl Heyendal)
Date: Thu, 21 Jul 2016 14:03:10 +0000
Subject: [openssl-users] Same openssl app behaves differently depending on
	platform
Message-ID: <CF8C1824A5EBA84CAB54AD048E722F5050DF0718@FGT-EXCH-MBX231.fortinet-us.com>

I have an app that uses openssl to connect to a server on a different machine. In one case on my Ubuntu machine the app has no problem getting a secure connection. But when I recompile the same app for an embedded target board and run it I get this error:

# ./client3 192.168.1.99
Enter PEM pass phrase:
connecting to 192.168.1.99:16001
** client3.c:77 Error connecting SSL object
1024:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278:
1024:error:1408D07B:SSL routines:ssl3_get_key_exchange:bad signature:s3_clnt.c:2004:

The app uses the same private key and certificate in both cases.

As a test I used s_client on both platforms to see whether it's a problem with the app, and it too fails with the same error on the embedded target but makes a connection on the Ubuntu machine....just like the app.

Something I observed on a wireshark trace is that depending on what platform the app is running on, in the 'Client Hello' exchange the app advertises a much smaller set of cipher suites on the Ubuntu machine than on the embedded target app. Consequently the server chooses a different cipher suite in both situations. This puzzles me and not sure if it's related to my problem.

Worth noting the version of openssl on the Ubuntu machine which is the platform that works, is older than the version for the embedded target board.

Not using TLSv2.

Appreciate any help or a nudge on how to debug this.

/carl h.



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



From rsalz at akamai.com  Thu Jul 21 14:28:50 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 21 Jul 2016 14:28:50 +0000
Subject: [openssl-users]
	Help	finding	replacement	for	ASN1_seq_unpack_X509
In-Reply-To: <20160721135405.GB20163@openssl.org>
References: <025d01d1e1b3$9e236390$da6a2ab0$@carroll.com>
 <20160719221001.GA12312@openssl.org>
 <003901d1e2ef$4b530c50$e1f924f0$@carroll.com>
 <9b8c0edfac89463889e7d702724e2ee5@usma1ex-dag1mb1.msg.corp.akamai.com>
 <00e201d1e34e$ba83f760$2f8be620$@carroll.com>
 <b54c7abdcf9d4d589ff40e7603228ba4@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20160721135405.GB20163@openssl.org>
Message-ID: <4069ad69851a4857a6f36d03e18ca4d7@usma1ex-dag1mb1.msg.corp.akamai.com>


> Actually that is including a SEQUENCE header and not just the DER blobs. So if
> the result must be compatible with the original format the snippet I
> suggested would be appropriate here.

Thanks for the correction.

From rsalz at akamai.com  Thu Jul 21 14:31:03 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 21 Jul 2016 14:31:03 +0000
Subject: [openssl-users] Openssl software failure for RSA 16K modulus
In-Reply-To: <BN3PR07MB2467BA46C774A5A3E9A0D6D097090@BN3PR07MB2467.namprd07.prod.outlook.com>
References: <mailman.5431.1469106535.1746.openssl-users@openssl.org>
 <BN3PR07MB2467BA46C774A5A3E9A0D6D097090@BN3PR07MB2467.namprd07.prod.outlook.com>
Message-ID: <f49344c7363d4d9fa2e34ab12f8e4637@usma1ex-dag1mb1.msg.corp.akamai.com>


> Instead of raising the limit of client key exchange message length more than 2048, why can't we add the 
> "ssl3_check_client_hello" functionality in the ssl/s3_srvr.c because that will "permit appropriate message length".

The DoS issue is still there.  How can you prevent the "other side" from consuming all your CPU with a large key?

Who needs 16K RSA keys, such that openssl by default should support that for everyone?

From steve at openssl.org  Thu Jul 21 14:33:38 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 21 Jul 2016 14:33:38 +0000
Subject: [openssl-users] Same openssl app behaves differently depending
 on platform
In-Reply-To: <CF8C1824A5EBA84CAB54AD048E722F5050DF0718@FGT-EXCH-MBX231.fortinet-us.com>
References: <CF8C1824A5EBA84CAB54AD048E722F5050DF0718@FGT-EXCH-MBX231.fortinet-us.com>
Message-ID: <20160721143338.GA21386@openssl.org>

On Thu, Jul 21, 2016, Carl Heyendal wrote:

> I have an app that uses openssl to connect to a server on a different machine. In one case on my Ubuntu machine the app has no problem getting a secure connection. But when I recompile the same app for an embedded target board and run it I get this error:
> 
> # ./client3 192.168.1.99
> Enter PEM pass phrase:
> connecting to 192.168.1.99:16001
> ** client3.c:77 Error connecting SSL object
> 1024:error:04091068:rsa routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278:
> 1024:error:1408D07B:SSL routines:ssl3_get_key_exchange:bad signature:s3_clnt.c:2004:
> 
> The app uses the same private key and certificate in both cases.
> 

It could be a compiler bug on the embedded platform. Does it pass "make test"?

Have you tried it with optimisation turned off?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From jim at carroll.com  Thu Jul 21 15:11:17 2016
From: jim at carroll.com (Jim Carroll)
Date: Thu, 21 Jul 2016 11:11:17 -0400
Subject: [openssl-users] Help finding
	replacement	for	ASN1_seq_unpack_X509
In-Reply-To: <20160721135238.GA20163@openssl.org>
References: <025d01d1e1b3$9e236390$da6a2ab0$@carroll.com>
 <20160719221001.GA12312@openssl.org>
 <003901d1e2ef$4b530c50$e1f924f0$@carroll.com>
 <20160721135238.GA20163@openssl.org>
Message-ID: <016f01d1e362$2155b420$64011c60$@carroll.com>

Steve,  

I ran into problems with swig when I tried to deploy you suggestion. Your
solution was slick pre-processor magic's and I was having difficulty
reversing the magic to troubleshoot swig (and I was a little shy about
admitting I didn't understand your suggestion).

I've spent more time reading ASN1 headers since then, and I'm starting to
get a glimmer of understanding of whats/what. I'm now circling back to your
solution and I think I'm getting on top of the swig issue.

Thanks for all your help.

> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
> Behalf Of Dr. Stephen Henson
> Sent: Thursday, July 21, 2016 9:53 AM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Help finding replacement for
> ASN1_seq_unpack_X509
> 
> On Wed, Jul 20, 2016, Jim Carroll wrote:
> 
> > Thanks much....I have a corollary question if you don't mind.  In
> OpenSSL
> > 1.1.0, what is the accepted procedure to convert a STACK_OF(X509) to
> DER?
> >
> 
> It depends on what you mean by "to DER" and what the other ends is
> expecting.
> 
> The code snipped I suggested will do that: if you call i2d_SEQ_CERT (or
> whatever you called it) that will work. That wraps the whole lot in a
> SEQUENCE
> header which is the same as the original. That is it is a SEQUENCE OF
> X509.
> 
> > Would it be acceptable to just iterate the stack elements, passing
> each X509
> > through i2d_X509 and appending the results -- would that generate
> valid DER?
> > Is there a better way?
> >
> 
> It depends on what the other side expects. If you just do that that and
> EOF
> signals the and of the last certificate you'll be fine. If you append
> additional data afterwards then you need to mark the last certificate
> somehow.
> The certificate sequence version prepends the data with the length of
> all the
> certificates so it automatically handles that.
> 
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


begin 666 smime.p7s
M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$'
M`0``H((.$3""!#8P@@,>H ,"`0("`0$P#08)*H9(AO<-`0$%!0`P;S$+, D&
M`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T($%",28P) 8#500+$QU!9&14
M<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B," &`U4$`Q,9061D5')U<W0@
M17AT97)N86P at 0T$@4F]O=# >%PTP,# U,S Q,#0X,SA:%PTR,# U,S Q,#0X
M,SA:,&\Q"S )!@-5! 83`E-%,10P$@8#500*$PM!9&14<G5S="!!0C$F,"0&
M`U4$"Q,=061D5')U<W0 at 17AT97)N86P at 5%10($YE='=O<FLQ(C @!@-5! ,3
M&4%D9%1R=7-T($5X=&5R;F%L($-!(%)O;W0P@@$B, T&"2J&2(;W#0$!`04`
M`X(!#P`P@@$*`H(!`0"W]QHSYO(`!"TYX$Y;[1^\; _-M?HCML[>FQ$SEZ0I
M3'V3G[U*O)/M`QKCC\_E;5!:UI<IE%J L$EZVRZ5_;C*OS<X+1X^D4&M<%;'
M\$\_Z#*>=,K(D%3IQE\/>)V:0#P.K&&J7A2/GH>A:E#<UYI.KP6SIG&4G'&S
M4& *QQ.=. >&`JCIJ&DF&)"K3+!/(ZLZ3X38W\Z?X6EON]="UVM$Y,>M[FU!
M7W):<0 at WLWEEI%F at E#?W`"\-PI)RVM X<ML4J$7$72I]M[36Q.ZLS1-$M\DK
MW4,`)?IAN6EJ6",1MZ<SCU9U6?7-*==&MPHK9;;30F\5LKA[^^_I75/5-%HG
M`@,!``&C@=PP@=DP'08#51T.!!8$%*V]F'HTM";W^L0F5.\#O> DRU0:, L&
M`U4=#P0$`P(!!C /!@-5'1,!`?\$!3 #`0'_,(&9!@-5'2,$@9$P at 8Z %*V]
MF'HTM";W^L0F5.\#O> DRU0:H7.D<3!O,0LP"08#500&$P)313$4,!(&`U4$
M"A,+061D5')U<W0 at 04(Q)C D!@-5! L3'4%D9%1R=7-T($5X=&5R;F%L(%14
M4"!.971W;W)K,2(P( 8#500#$QE!9&14<G5S="!%>'1E<FYA;"!#02!2;V]T
M@@$!, T&"2J&2(;W#0$!!04``X(!`0"PF^"%)<+6(^(/E@:2G4&8G-F$>8'9
M'EL4!R,V98^PV'>[K$%L1V"#4;#Y,CWG_/8F$\> %J6_6OR'SWAYB2&:XDP'
M"H8UO/+>4<32EK?<?D[N</T<.>L,`E$4+8Z]%N#!WT9UYR2M[/1"M(63<!!G
MNIT&-4H8TRMZS%%"H7ICT>:[H<4KPC:^$PWFO6-^>7NG"0U JVK=CXK#]O:,
M&D(%4=1%]9^G8B%H%2!#/)GG?+TDV*F1%W.(/U8;,3 at 8M'$/FLW(#IZ.+AOA
MC)B#RQ\Q\41,Q at 1S279@#\?XO1> :R[IS$P.6IIY#R *+M6>8R8>59*4V((7
M6GO0O,>/3H8$,(($KS""`Y>@`P(!`@(1`. CRQ42 at U.)K6%N>E1G:R$P#08)
M*H9(AO<-`0$+!0`P;S$+, D&`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T
M($%",28P) 8#500+$QU!9&14<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B
M," &`U4$`Q,9061D5')U<W0 at 17AT97)N86P at 0T$@4F]O=# >%PTQ-#$R,C(P
M,# P,#!:%PTR,# U,S Q,#0X,SA:,(&;,0LP"08#500&$P)'0C$;,!D&`U4$
M"!,21W)E871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#
M500*$Q%#3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR
M-38 at 0VQI96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$P
M@@$B, T&"2J&2(;W#0$!`04``X(!#P`P@@$*`H(!`0")L0W:>E,93G!2';Q6
MI at 8FM[A)X);G4:OQ\%H3216CM(P;8+QZ44*G>8RD(M\784Z1U78C"A332@)_
MMAT)@&ZE!#W9NKL6_J&'J2Y#4D,6?*\R4,BF3UKI"-C/DR6<>XCH,&3FI/A6
M@/TJ)!0S%YFL1.5IBZ-&!DO",]3I0)\&L+&LDT"YM0B3.IPJ4Z,0VST at 83Q5
M`X[93G8E`B$I^J-\<79/[N%?@>G[5(#;PWLU4K>$WB(]+# M,7]9O5(WL#-I
M+4/K^M:E\9=W9U&,V>XGZ[RE!SAVC*2I./_?C/4#K$F^RO=SF3H/,JN<E3H3
M/0Y&.E=T85"^QD _R^3BGZ(A`@,!``&C@@$7,((!$S ?!@-5'2,$&# 6@!2M
MO9AZ-+0F]_K$)E3O`[W@),M4&C =!@-5'0X$%@04DF%K at N&BH*I/[&?QPJ/W
MM( `P>PP#@8#51T/`0'_! 0#`@&&,!(&`U4=$P$!_P0(, 8!`?\"`0`P'08#
M51TE!!8P% 8(*P8!!04'`P(&""L&`04%!P,$,!$&`U4=( 0*, @P!@8$51T@
M`#!$!@-5'1\$/3 [,#F at -Z UAC-H='1P.B\O8W)L+G5S97)T<G5S="YC;VTO
M061D5')U<W1%>'1E<FYA;$-!4F]O="YC<FPP-08(*P8!!04'`0$$*3 G,"4&
M""L&`04%!S !AAEH='1P.B\O;V-S<"YU<V5R=')U<W0N8V]M, T&"2J&2(;W
M#0$!"P4``X(!`0`;*FZL5<$ZJXC%V.W-5?.J:V$KP D0(YD/Q69J;['UM+5W
M7@\"80#??07^$K.D@( `_/L=6VIR`@I!O 6ZP5C5)L+JU4V$^_Z"F,]8&^,B
M8YQ2^+L%-JM]6*7>JSMCY=K5<^_LX/M[XJ/_\$(CG,JVC4T^Y$L8`[*H+=38
MNT)+D&F%$-NF-S3H>^ !$*6<RCK'GT^(-&Z*9= :BKNIW,K*-M'T_,)D*36O
MUK&G<1'2`T.QCSZ:[)XR4_1VDLJ&- >Y+,KF'$K8F0W!AN*0DOM:0FHC(1#I
M9<?UU;M^ZHR%( )BZM$Z!RQ9Q9DS\CB)Y;;I%GH?>13V2A :)OI\BON;,((%
M(#""! B@`P(!`@(1`-4+#]T2278FC)\!=Y87SN8P#08)*H9(AO<-`0$+!0`P
M at 9LQ"S )!@-5! 83`D=",1LP&08#500($Q)'<F5A=&5R($UA;F-H97-T97(Q
M$# .!@-5! <3!U-A;&9O<F0Q&C 8!@-5! H3$4-/34]$3R!#02!,:6UI=&5D
M,4$P/P8#500#$SA#3TU/1$\@4TA!+3(U-B!#;&EE;G0 at 075T:&5N=&EC871I
M;VX at 86YD(%-E8W5R92!%;6%I;"!#03 >%PTQ-C Q,3,P,# P,#!:%PTQ-S Q
M,3(R,S4Y-3E:," Q'C <!@DJADB&]PT!"0$6#VII;4!C87)R;VQL+F-O;3""
M`2(P#08)*H9(AO<-`0$!!0`#@@$/`#""`0H"@@$!`-K\XS'GF('[$TPZLMT=
MY]ID(UGI at 9^?K.$F3&?)JS.0Q"6)OD@;8S<+1#[2QFG.S045<BKJ-D6O9FQ\
M<*2_A$&HWT6R`S' 7$<4M7HIO_"G at U#-`1,6W2HZ`,L53(EL?:P_[H%Y/6VB
MJU\01/0U<U7T/"K$+CFK\>HV/H^"EPS!W)_L#3<"[3T(BZ3LDTHN"#(\B5A1
M^VO2XN77=+Z\+IU=@1UR!40:,<7&)5,P,O1STRE:UFFYLS65=GVT*:ZY[YK9
M':(_+75)?UCOJQ: M-%=9XH<_VNPXG^;7/:6"2-DDFNH3JMIBVKH$1G/E$ 9
MD8XE<3>#8^@.89*P$#)O+'$"`P$``:."`=<P@@'3,!\&`U4=(P08,!: %))A
M:X+AHJ"J3^QG\<*C][2 `,'L,!T&`U4=#@06!!0P:UC0J,N<!7>SB(9<*/G'
MV*_ SS .!@-5'0\!`?\$! ,"!: P# 8#51T3`0'_! (P`# =!@-5'24$%C 4
M!@@K!@$%!0<#! 8(*P8!!04'`P(P1 at 8#51T@!#\P/3 [!@PK!@$$`;(Q`0(!
M`P4P*S I!@@K!@$%!0<"`18=:'1T<',Z+R]S96-U<F4N8V]M;V1O+FYE="]#
M4%,P708#51T?!%8P5#!2H%"@3H9,:'1T<#HO+V-R;"YC;VUO9&]C82YC;VTO
M0T]-3T1/4TA!,C4V0VQI96YT075T:&5N=&EC871I;VYA;F1396-U<F5%;6%I
M;$-!+F-R;#"!D 8(*P8!!04'`0$$@8,P at 8 P6 8(*P8!!04', *&3&AT=' Z
M+R]C<G0N8V]M;V1O8V$N8V]M+T-/34]$3U-(03(U-D-L:65N=$%U=&AE;G1I
M8V%T:6]N86YD4V5C=7)E16UA:6Q#02YC<G0P) 8(*P8!!04', &&&&AT=' Z
M+R]O8W-P+F-O;6]D;V-A+F-O;3 :!@-5'1$$$S 1 at 0]J:6U 8V%R<F]L;"YC
M;VTP#08)*H9(AO<-`0$+!0`#@@$!`&7_YE!"6I-N>DE*'QH34=CM%+[K`1M]
M]CL[U/FRY5[^LX>0V\F[3S&JAG>8?S4(\8%YC7"@FZN?&[XNG;*71FB1VC5\
M[C at 1T1/1VFB^.U_DY "31W;:;K"NZ]K)Q3#HO(@&45E,YCJ!NY$AC!C\IGQ:
M2/NGP"_K'85*^(.K.&Q*INS)?2E26GN'Y^%BLAID at HA<[DL&']YY*Z 9#&;V
MFJ3HYV^Y[HF)FFH-]D/]<5G):'.LJD*"]IJWI4,'-BQ;060E4[7[NKAN!^P\
MBTU&T;&8EQ; '\I'[_^.1-;+K'J.:_]/&2]A0 at L9SC^8NO*8S_4,>"4TRIOH
MI'J>$[1$P4TQ@@0C,(($'P(!`3"!L3"!FS$+, D&`U4$!A,"1T(Q&S 9!@-5
M! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'4V%L9F]R9#$:,!@&
M`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3.$-/34]$3R!32$$M
M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C=7)E($5M86EL($-!
M`A$`U0L/W1))=B:,GP%WEA?.YC )!@4K#@,"&@4`H(("1C 8!@DJADB&]PT!
M"0,Q"P8)*H9(AO<-`0<!,!P&"2J&2(;W#0$)!3$/%PTQ-C W,C$Q-3$Q,39:
M,",&"2J&2(;W#0$)!#$6!!0;O5^+:?"I\(':$X.)-.#(W77_LC!;!@DJADB&
M]PT!"0\Q3C!,, H&""J&2(;W#0,', X&""J&2(;W#0,"`@(`@# -!@@JADB&
M]PT#`@(!0# '!@4K#@,"!S -!@@JADB&]PT#`@(!*# '!@4K#@,"&C"!P at 8)
M*P8!! &"-Q $,8&T,(&Q,(&;,0LP"08#500&$P)'0C$;,!D&`U4$"!,21W)E
M871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#500*$Q%#
M3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR-38 at 0VQI
M96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$"$0#5"P_=
M$DEV)HR?`7>6%\[F,('$!@LJADB&]PT!"1 ""S&!M*"!L3"!FS$+, D&`U4$
M!A,"1T(Q&S 9!@-5! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'
M4V%L9F]R9#$:,!@&`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3
M.$-/34]$3R!32$$M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C
M=7)E($5M86EL($-!`A$`U0L/W1))=B:,GP%WEA?.YC -!@DJADB&]PT!`0$%
M``2"`0!R%/A?JIZ3WEWO^YEU96:6]KXOE";9TQ6=_;;O(NY'$_'EE298#8UC
M%TO]9_$."EHCFBLBQ16Q6N06KHJN\[ G>C$<*UEXG$H5*J0:M<+_RQO!8*+U
M at EQF&'2+,"@6252G/_+7N' 4K9KBAT,BO&!U3MWLB9GK2]%E^<]RYXQ=,W9D
M1R"0MC0ZA0LAWR&&1L0M$Y.4+[(T5._AHYB/T$OK#9E.S,/6?['!J3>AP41I
M#0]%#RF>9'Y0O+8B'P+9-9O7_,)JBDQ(;S_Y[=U[<(_$_8DKU#F7I1.H>;OU
J7V<0K%8+4QH]J\G>'Y 96-V0ML_58NFHWJQBV)NQQ1G^M?BZ````````
`
end


From Erwann.Abalea at docusign.com  Thu Jul 21 13:51:47 2016
From: Erwann.Abalea at docusign.com (Erwann Abalea)
Date: Thu, 21 Jul 2016 13:51:47 +0000
Subject: [openssl-users] Openssl software failure for RSA 16K modulus
In-Reply-To: <e54921bc7b864c64bda6fd688172240c@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <BN3PR07MB246737A3ABB76E4624723C9E97090@BN3PR07MB2467.namprd07.prod.outlook.com>
 <F2A95F8F-BCC8-4EC5-984F-8B77C91BBAA2@docusign.com>
 <f3934079655b4d8fa3328b21ea62ef6f@usma1ex-dag1mb1.msg.corp.akamai.com>
 <e8e3f6f5b5a849ab8000dab434aace1d@usma1ex-dag1mb1.msg.corp.akamai.com>
 <C1C086D5-5270-4595-8ED6-D6D69DF0C7E1@docusign.com>
 <e54921bc7b864c64bda6fd688172240c@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <A568EFF7-0C87-475F-B7B0-62E31BA70908@docusign.com>


> Le 21 juil. 2016 ? 15:08, Salz, Rich <rsalz at akamai.com> a ?crit :
> 
>> By raising the limit, you don?t suddenly put every application at risk of a DoS,
>> because these applications won?t suddenly use a 16k RSA key.
> 
> Yes we do, because the other side could send a key, not local config.

Server A code is modified to accept client key exchange messages up to 4kB.
Server A is configured with a 2048bits RSA key.

Client A connects to Server A, initiates the TLS handshake, receives the certificate, properly generates a 2048bits client key exchange message (using RSA key exchange), sends the message (about 260 octets); Server A accepts it and will do the job.

Client B connects to Server A, initiates the TLS handshake, receives the certificate, but for whatever reason decides to send a client key exchange message composed of what could be a 16kb RSA block (about 2056 bytes); Server A will accept the message, but will refuse to perform the RSA decryption (because it?s larger than the modulus length).

I don?t see where the harm can hide. There?s no more CPU eaten, network transfer has already happened at this moment, memory is already allocated.

Again, I?m not saying using a 16kRSA key is a good idea. It?s not a good idea, one should really consider ECC instead (both for performance and network reasons). But keeping this 2048 bytes limit is not a security decision. It?s the result of a trade-off choice, right. And that doesn't make it a bad decision either.


From rsalz at akamai.com  Thu Jul 21 15:28:47 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 21 Jul 2016 15:28:47 +0000
Subject: [openssl-users] Openssl software failure for RSA 16K modulus
In-Reply-To: <A568EFF7-0C87-475F-B7B0-62E31BA70908@docusign.com>
References: <BN3PR07MB246737A3ABB76E4624723C9E97090@BN3PR07MB2467.namprd07.prod.outlook.com>
 <F2A95F8F-BCC8-4EC5-984F-8B77C91BBAA2@docusign.com>
 <f3934079655b4d8fa3328b21ea62ef6f@usma1ex-dag1mb1.msg.corp.akamai.com>
 <e8e3f6f5b5a849ab8000dab434aace1d@usma1ex-dag1mb1.msg.corp.akamai.com>
 <C1C086D5-5270-4595-8ED6-D6D69DF0C7E1@docusign.com>
 <e54921bc7b864c64bda6fd688172240c@usma1ex-dag1mb1.msg.corp.akamai.com>
 <A568EFF7-0C87-475F-B7B0-62E31BA70908@docusign.com>
Message-ID: <91e464c39bcd47cda99d66306d0cb64c@usma1ex-dag1mb1.msg.corp.akamai.com>

> Again, I?m not saying using a 16kRSA key is a good idea. It?s not a good idea,
> one should really consider ECC instead (both for performance and network
> reasons). But keeping this 2048 bytes limit is not a security decision. It?s the
> result of a trade-off choice, right. And that doesn't make it a bad decision
> either.

+1

From jb-openssl at wisemo.com  Thu Jul 21 15:59:00 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 21 Jul 2016 17:59:00 +0200
Subject: [openssl-users] Openssl software failure for RSA 16K modulus
In-Reply-To: <91e464c39bcd47cda99d66306d0cb64c@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <BN3PR07MB246737A3ABB76E4624723C9E97090@BN3PR07MB2467.namprd07.prod.outlook.com>
 <F2A95F8F-BCC8-4EC5-984F-8B77C91BBAA2@docusign.com>
 <f3934079655b4d8fa3328b21ea62ef6f@usma1ex-dag1mb1.msg.corp.akamai.com>
 <e8e3f6f5b5a849ab8000dab434aace1d@usma1ex-dag1mb1.msg.corp.akamai.com>
 <C1C086D5-5270-4595-8ED6-D6D69DF0C7E1@docusign.com>
 <e54921bc7b864c64bda6fd688172240c@usma1ex-dag1mb1.msg.corp.akamai.com>
 <A568EFF7-0C87-475F-B7B0-62E31BA70908@docusign.com>
 <91e464c39bcd47cda99d66306d0cb64c@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <68a893e6-52e0-8d41-19cb-064b50e874a9@wisemo.com>

On 21/07/2016 17:28, Salz, Rich wrote:
>> Again, I?m not saying using a 16kRSA key is a good idea. It?s not a good idea,
>> one should really consider ECC instead (both for performance and network
>> reasons). But keeping this 2048 bytes limit is not a security decision. It?s the
>> result of a trade-off choice, right. And that doesn't make it a bad decision
>> either.
> +1

Wait, is OpenSSL "sanity checking" a message size dictated by
the same ends local configuration against a fixed arbitrary
limit rather than a limit computed from that local
configuration?  That sounds doubly buggy as it will be too
high a limit for some configurations and too low a limit for
some other configurations.

The situation would be different for limits that would depend
on the sanity of remote values (such as the key length in a
client certificate sent to a server checking the limit or the
key length in a server certificate sent to a client checking
the limit).

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


From rsalz at akamai.com  Thu Jul 21 16:04:33 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 21 Jul 2016 16:04:33 +0000
Subject: [openssl-users] Openssl software failure for RSA 16K modulus
In-Reply-To: <68a893e6-52e0-8d41-19cb-064b50e874a9@wisemo.com>
References: <BN3PR07MB246737A3ABB76E4624723C9E97090@BN3PR07MB2467.namprd07.prod.outlook.com>
 <F2A95F8F-BCC8-4EC5-984F-8B77C91BBAA2@docusign.com>
 <f3934079655b4d8fa3328b21ea62ef6f@usma1ex-dag1mb1.msg.corp.akamai.com>
 <e8e3f6f5b5a849ab8000dab434aace1d@usma1ex-dag1mb1.msg.corp.akamai.com>
 <C1C086D5-5270-4595-8ED6-D6D69DF0C7E1@docusign.com>
 <e54921bc7b864c64bda6fd688172240c@usma1ex-dag1mb1.msg.corp.akamai.com>
 <A568EFF7-0C87-475F-B7B0-62E31BA70908@docusign.com>
 <91e464c39bcd47cda99d66306d0cb64c@usma1ex-dag1mb1.msg.corp.akamai.com>
 <68a893e6-52e0-8d41-19cb-064b50e874a9@wisemo.com>
Message-ID: <66bfd614220a4237ae3a29881dbe3e70@usma1ex-dag1mb1.msg.corp.akamai.com>


> Wait, is OpenSSL "sanity checking" a message size dictated by the same ends
> local configuration against a fixed arbitrary limit rather than a limit computed
> from that local configuration?

Yup.  Call it a limitation of C, if you want.  "#define MAX_..." is just too hard to avoid.

It has been this way forever. There was an open ticket about removing all fixed-sized limits, I think.  But I doubt that will happen.




From cheyendal at fortinet.com  Thu Jul 21 17:44:50 2016
From: cheyendal at fortinet.com (Carl Heyendal)
Date: Thu, 21 Jul 2016 17:44:50 +0000
Subject: [openssl-users] [Newsletter] Re: Same openssl app behaves
 differently depending on platform
In-Reply-To: <20160721143338.GA21386@openssl.org>
References: <CF8C1824A5EBA84CAB54AD048E722F5050DF0718@FGT-EXCH-MBX231.fortinet-us.com>
 <20160721143338.GA21386@openssl.org>
Message-ID: <CF8C1824A5EBA84CAB54AD048E722F5050DF17BB@FGT-EXCH-MBX231.fortinet-us.com>

Turned out to be optimization as you suggested. Once I turned it off the app connected on the embedded target.

Good one Steve. I had forgotten how optimization mucks things up from time to time.

Thanks
/carl h.

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Dr. Stephen Henson
Sent: July-21-16 10:34 AM
To: openssl-users at openssl.org
Subject: [Newsletter] Re: [openssl-users] Same openssl app behaves differently depending on platform

On Thu, Jul 21, 2016, Carl Heyendal wrote:

> I have an app that uses openssl to connect to a server on a different machine. In one case on my Ubuntu machine the app has no problem getting a secure connection. But when I recompile the same app for an embedded target board and run it I get this error:
> 
> # ./client3 192.168.1.99
> Enter PEM pass phrase:
> connecting to 192.168.1.99:16001
> ** client3.c:77 Error connecting SSL object 1024:error:04091068:rsa 
> routines:INT_RSA_VERIFY:bad signature:rsa_sign.c:278:
> 1024:error:1408D07B:SSL routines:ssl3_get_key_exchange:bad signature:s3_clnt.c:2004:
> 
> The app uses the same private key and certificate in both cases.
> 

It could be a compiler bug on the embedded platform. Does it pass "make test"?

Have you tried it with optimisation turned off?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


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



From steve at openssl.org  Thu Jul 21 18:41:00 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 21 Jul 2016 18:41:00 +0000
Subject: [openssl-users] Help finding
	replacement	for	ASN1_seq_unpack_X509
In-Reply-To: <016f01d1e362$2155b420$64011c60$@carroll.com>
References: <025d01d1e1b3$9e236390$da6a2ab0$@carroll.com>
 <20160719221001.GA12312@openssl.org>
 <003901d1e2ef$4b530c50$e1f924f0$@carroll.com>
 <20160721135238.GA20163@openssl.org>
 <016f01d1e362$2155b420$64011c60$@carroll.com>
Message-ID: <20160721184100.GA24909@openssl.org>

On Thu, Jul 21, 2016, Jim Carroll wrote:

> 
> I ran into problems with swig when I tried to deploy you suggestion. Your
> solution was slick pre-processor magic's and I was having difficulty
> reversing the magic to troubleshoot swig (and I was a little shy about
> admitting I didn't understand your suggestion).
> 
> I've spent more time reading ASN1 headers since then, and I'm starting to
> get a glimmer of understanding of whats/what. I'm now circling back to your
> solution and I think I'm getting on top of the swig issue.
> 

I'd be interested in knowing more details of the swig problems you had. If it
helps you can just include my code snippet in a separate C source file and
then just use the i2d/d2i functions in the swig wrapper itself.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From steve at openssl.org  Thu Jul 21 19:00:03 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 21 Jul 2016 19:00:03 +0000
Subject: [openssl-users] Help finding
	replacement	for	ASN1_seq_unpack_X509
In-Reply-To: <016f01d1e362$2155b420$64011c60$@carroll.com>
References: <025d01d1e1b3$9e236390$da6a2ab0$@carroll.com>
 <20160719221001.GA12312@openssl.org>
 <003901d1e2ef$4b530c50$e1f924f0$@carroll.com>
 <20160721135238.GA20163@openssl.org>
 <016f01d1e362$2155b420$64011c60$@carroll.com>
Message-ID: <20160721190003.GA25192@openssl.org>

On Thu, Jul 21, 2016, Jim Carroll wrote:

> Steve,  
> 
> I ran into problems with swig when I tried to deploy you suggestion. Your
> solution was slick pre-processor magic's and I was having difficulty
> reversing the magic to troubleshoot swig (and I was a little shy about
> admitting I didn't understand your suggestion).
> 

Well there are various things going on underneath which can be hard to follow
if you aren't used to them. Here's a bit more detail about what is going on.

Initially we just include the necessary headers:

#include <openssl/x509.h>
#include <openssl/asn1t.h>

ASN.1 encode/decode routines generally use a structure name. We have
STACK_OF(X509) but no name for that so we can make one up which I call
SEQ_CERT:

typedef STACK_OF(X509) SEQ_CERT;

The next bit defines an ASN.1 module structure which says the SEQ_CERT is
a SEQUENCE OF X509:

ASN1_ITEM_TEMPLATE(SEQ_CERT) =
        ASN1_EX_TEMPLATE_TYPE(ASN1_TFLG_SEQUENCE_OF, 0, SeqCert, X509)
ASN1_ITEM_TEMPLATE_END(SEQ_CERT)

Here SEQ_CERT is the structure name which that macro defines as a SEQUENCE OF
X509. The "SeqCert" is just a string that is used as a name in the definition:
it can be anything.

Now that's all very well but it doesn't actually define any functions. The bit
that does that is this:

IMPLEMENT_ASN1_FUNCTIONS(SEQ_CERT)

This implements four functions but we're only interested in the encode and
decode ones which look like this:

 int i2d_SEQ_CERT(SEQ_CERT *a, unsigned char **pp);
 TYPE *d2i_SEQ_CERT(SEQ_CERT **a, unsigned char **pp, long length);

These behave like regular ASN.1 functions you pass in SEQ_CERT: which is
STACK_OF(X509) to the i2d_SEQ_CERT and it encodes the result as a SEQUENCE
OF X509 which is the same format as the original.

Similarly you can decode using d2i_SEQ_CERT() and get back a STACK_OF(X509).

If you have this in a separate module you can declare the new functions (e.g.
in a header file) with:

DECLARE_ASN1_FUNCTIONS(SEQ_CERT)

Hope that helps. If you have any further problems let me know.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From jim at carroll.com  Thu Jul 21 19:08:24 2016
From: jim at carroll.com (Jim Carroll)
Date: Thu, 21 Jul 2016 15:08:24 -0400
Subject: [openssl-users] Help
	finding	replacement	for	ASN1_seq_unpack_X509
In-Reply-To: <20160721190003.GA25192@openssl.org>
References: <025d01d1e1b3$9e236390$da6a2ab0$@carroll.com>
 <20160719221001.GA12312@openssl.org>
 <003901d1e2ef$4b530c50$e1f924f0$@carroll.com>
 <20160721135238.GA20163@openssl.org>
 <016f01d1e362$2155b420$64011c60$@carroll.com>
 <20160721190003.GA25192@openssl.org>
Message-ID: <025001d1e383$422a62b0$c67f2810$@carroll.com>

I was just typing a reply to your previous message asking for a bit of
clarification and this message just came through -- answered every single
one of my questions !

To answer your question about the swig changes, I was able to solve the
problem by moving your code to the top of the swig declarations file. The
M2Crypto swig declaration file uses some pretty sophisticated directives,
and I think one of them was getting in the way.  Specifically, I believe it
was a conflict with %inline %{ ... %} and the swig pre-processor.

We're using SWIG 3.0.1, and we're compiling a small list of bug fixes for
them as well (mostly with how they handle certain Microsoft specific
extensions).  After we finish the port of M2Crypto, we'll submit to them as
well.

> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
> Behalf Of Dr. Stephen Henson
> Sent: Thursday, July 21, 2016 3:00 PM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Help finding replacement for
> ASN1_seq_unpack_X509
> 
> On Thu, Jul 21, 2016, Jim Carroll wrote:
> 
> > Steve,
> >
> > I ran into problems with swig when I tried to deploy you suggestion.
> Your
> > solution was slick pre-processor magic's and I was having difficulty
> > reversing the magic to troubleshoot swig (and I was a little shy
> about
> > admitting I didn't understand your suggestion).
> >
> 
> Well there are various things going on underneath which can be hard to
> follow
> if you aren't used to them. Here's a bit more detail about what is
> going on.
> 
> Initially we just include the necessary headers:
> 
> #include <openssl/x509.h>
> #include <openssl/asn1t.h>
> 
> ASN.1 encode/decode routines generally use a structure name. We have
> STACK_OF(X509) but no name for that so we can make one up which I call
> SEQ_CERT:
> 
> typedef STACK_OF(X509) SEQ_CERT;
> 
> The next bit defines an ASN.1 module structure which says the SEQ_CERT
> is
> a SEQUENCE OF X509:
> 
> ASN1_ITEM_TEMPLATE(SEQ_CERT) =
>         ASN1_EX_TEMPLATE_TYPE(ASN1_TFLG_SEQUENCE_OF, 0, SeqCert, X509)
> ASN1_ITEM_TEMPLATE_END(SEQ_CERT)
> 
> Here SEQ_CERT is the structure name which that macro defines as a
> SEQUENCE OF
> X509. The "SeqCert" is just a string that is used as a name in the
> definition:
> it can be anything.
> 
> Now that's all very well but it doesn't actually define any functions.
> The bit
> that does that is this:
> 
> IMPLEMENT_ASN1_FUNCTIONS(SEQ_CERT)
> 
> This implements four functions but we're only interested in the encode
> and
> decode ones which look like this:
> 
>  int i2d_SEQ_CERT(SEQ_CERT *a, unsigned char **pp);
>  TYPE *d2i_SEQ_CERT(SEQ_CERT **a, unsigned char **pp, long length);
> 
> These behave like regular ASN.1 functions you pass in SEQ_CERT: which
> is
> STACK_OF(X509) to the i2d_SEQ_CERT and it encodes the result as a
> SEQUENCE
> OF X509 which is the same format as the original.
> 
> Similarly you can decode using d2i_SEQ_CERT() and get back a
> STACK_OF(X509).
> 
> If you have this in a separate module you can declare the new functions
> (e.g.
> in a header file) with:
> 
> DECLARE_ASN1_FUNCTIONS(SEQ_CERT)
> 
> Hope that helps. If you have any further problems let me know.
> 
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


begin 666 smime.p7s
M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$'
M`0``H((.$3""!#8P@@,>H ,"`0("`0$P#08)*H9(AO<-`0$%!0`P;S$+, D&
M`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T($%",28P) 8#500+$QU!9&14
M<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B," &`U4$`Q,9061D5')U<W0@
M17AT97)N86P at 0T$@4F]O=# >%PTP,# U,S Q,#0X,SA:%PTR,# U,S Q,#0X
M,SA:,&\Q"S )!@-5! 83`E-%,10P$@8#500*$PM!9&14<G5S="!!0C$F,"0&
M`U4$"Q,=061D5')U<W0 at 17AT97)N86P at 5%10($YE='=O<FLQ(C @!@-5! ,3
M&4%D9%1R=7-T($5X=&5R;F%L($-!(%)O;W0P@@$B, T&"2J&2(;W#0$!`04`
M`X(!#P`P@@$*`H(!`0"W]QHSYO(`!"TYX$Y;[1^\; _-M?HCML[>FQ$SEZ0I
M3'V3G[U*O)/M`QKCC\_E;5!:UI<IE%J L$EZVRZ5_;C*OS<X+1X^D4&M<%;'
M\$\_Z#*>=,K(D%3IQE\/>)V:0#P.K&&J7A2/GH>A:E#<UYI.KP6SIG&4G'&S
M4& *QQ.=. >&`JCIJ&DF&)"K3+!/(ZLZ3X38W\Z?X6EON]="UVM$Y,>M[FU!
M7W):<0 at WLWEEI%F at E#?W`"\-PI)RVM X<ML4J$7$72I]M[36Q.ZLS1-$M\DK
MW4,`)?IAN6EJ6",1MZ<SCU9U6?7-*==&MPHK9;;30F\5LKA[^^_I75/5-%HG
M`@,!``&C@=PP@=DP'08#51T.!!8$%*V]F'HTM";W^L0F5.\#O> DRU0:, L&
M`U4=#P0$`P(!!C /!@-5'1,!`?\$!3 #`0'_,(&9!@-5'2,$@9$P at 8Z %*V]
MF'HTM";W^L0F5.\#O> DRU0:H7.D<3!O,0LP"08#500&$P)313$4,!(&`U4$
M"A,+061D5')U<W0 at 04(Q)C D!@-5! L3'4%D9%1R=7-T($5X=&5R;F%L(%14
M4"!.971W;W)K,2(P( 8#500#$QE!9&14<G5S="!%>'1E<FYA;"!#02!2;V]T
M@@$!, T&"2J&2(;W#0$!!04``X(!`0"PF^"%)<+6(^(/E@:2G4&8G-F$>8'9
M'EL4!R,V98^PV'>[K$%L1V"#4;#Y,CWG_/8F$\> %J6_6OR'SWAYB2&:XDP'
M"H8UO/+>4<32EK?<?D[N</T<.>L,`E$4+8Z]%N#!WT9UYR2M[/1"M(63<!!G
MNIT&-4H8TRMZS%%"H7ICT>:[H<4KPC:^$PWFO6-^>7NG"0U JVK=CXK#]O:,
M&D(%4=1%]9^G8B%H%2!#/)GG?+TDV*F1%W.(/U8;,3 at 8M'$/FLW(#IZ.+AOA
MC)B#RQ\Q\41,Q at 1S279@#\?XO1> :R[IS$P.6IIY#R *+M6>8R8>59*4V((7
M6GO0O,>/3H8$,(($KS""`Y>@`P(!`@(1`. CRQ42 at U.)K6%N>E1G:R$P#08)
M*H9(AO<-`0$+!0`P;S$+, D&`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T
M($%",28P) 8#500+$QU!9&14<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B
M," &`U4$`Q,9061D5')U<W0 at 17AT97)N86P at 0T$@4F]O=# >%PTQ-#$R,C(P
M,# P,#!:%PTR,# U,S Q,#0X,SA:,(&;,0LP"08#500&$P)'0C$;,!D&`U4$
M"!,21W)E871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#
M500*$Q%#3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR
M-38 at 0VQI96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$P
M@@$B, T&"2J&2(;W#0$!`04``X(!#P`P@@$*`H(!`0")L0W:>E,93G!2';Q6
MI at 8FM[A)X);G4:OQ\%H3216CM(P;8+QZ44*G>8RD(M\784Z1U78C"A332@)_
MMAT)@&ZE!#W9NKL6_J&'J2Y#4D,6?*\R4,BF3UKI"-C/DR6<>XCH,&3FI/A6
M@/TJ)!0S%YFL1.5IBZ-&!DO",]3I0)\&L+&LDT"YM0B3.IPJ4Z,0VST at 83Q5
M`X[93G8E`B$I^J-\<79/[N%?@>G[5(#;PWLU4K>$WB(]+# M,7]9O5(WL#-I
M+4/K^M:E\9=W9U&,V>XGZ[RE!SAVC*2I./_?C/4#K$F^RO=SF3H/,JN<E3H3
M/0Y&.E=T85"^QD _R^3BGZ(A`@,!``&C@@$7,((!$S ?!@-5'2,$&# 6@!2M
MO9AZ-+0F]_K$)E3O`[W@),M4&C =!@-5'0X$%@04DF%K at N&BH*I/[&?QPJ/W
MM( `P>PP#@8#51T/`0'_! 0#`@&&,!(&`U4=$P$!_P0(, 8!`?\"`0`P'08#
M51TE!!8P% 8(*P8!!04'`P(&""L&`04%!P,$,!$&`U4=( 0*, @P!@8$51T@
M`#!$!@-5'1\$/3 [,#F at -Z UAC-H='1P.B\O8W)L+G5S97)T<G5S="YC;VTO
M061D5')U<W1%>'1E<FYA;$-!4F]O="YC<FPP-08(*P8!!04'`0$$*3 G,"4&
M""L&`04%!S !AAEH='1P.B\O;V-S<"YU<V5R=')U<W0N8V]M, T&"2J&2(;W
M#0$!"P4``X(!`0`;*FZL5<$ZJXC%V.W-5?.J:V$KP D0(YD/Q69J;['UM+5W
M7@\"80#??07^$K.D@( `_/L=6VIR`@I!O 6ZP5C5)L+JU4V$^_Z"F,]8&^,B
M8YQ2^+L%-JM]6*7>JSMCY=K5<^_LX/M[XJ/_\$(CG,JVC4T^Y$L8`[*H+=38
MNT)+D&F%$-NF-S3H>^ !$*6<RCK'GT^(-&Z*9= :BKNIW,K*-M'T_,)D*36O
MUK&G<1'2`T.QCSZ:[)XR4_1VDLJ&- >Y+,KF'$K8F0W!AN*0DOM:0FHC(1#I
M9<?UU;M^ZHR%( )BZM$Z!RQ9Q9DS\CB)Y;;I%GH?>13V2A :)OI\BON;,((%
M(#""! B@`P(!`@(1`-4+#]T2278FC)\!=Y87SN8P#08)*H9(AO<-`0$+!0`P
M at 9LQ"S )!@-5! 83`D=",1LP&08#500($Q)'<F5A=&5R($UA;F-H97-T97(Q
M$# .!@-5! <3!U-A;&9O<F0Q&C 8!@-5! H3$4-/34]$3R!#02!,:6UI=&5D
M,4$P/P8#500#$SA#3TU/1$\@4TA!+3(U-B!#;&EE;G0 at 075T:&5N=&EC871I
M;VX at 86YD(%-E8W5R92!%;6%I;"!#03 >%PTQ-C Q,3,P,# P,#!:%PTQ-S Q
M,3(R,S4Y-3E:," Q'C <!@DJADB&]PT!"0$6#VII;4!C87)R;VQL+F-O;3""
M`2(P#08)*H9(AO<-`0$!!0`#@@$/`#""`0H"@@$!`-K\XS'GF('[$TPZLMT=
MY]ID(UGI at 9^?K.$F3&?)JS.0Q"6)OD@;8S<+1#[2QFG.S045<BKJ-D6O9FQ\
M<*2_A$&HWT6R`S' 7$<4M7HIO_"G at U#-`1,6W2HZ`,L53(EL?:P_[H%Y/6VB
MJU\01/0U<U7T/"K$+CFK\>HV/H^"EPS!W)_L#3<"[3T(BZ3LDTHN"#(\B5A1
M^VO2XN77=+Z\+IU=@1UR!40:,<7&)5,P,O1STRE:UFFYLS65=GVT*:ZY[YK9
M':(_+75)?UCOJQ: M-%=9XH<_VNPXG^;7/:6"2-DDFNH3JMIBVKH$1G/E$ 9
MD8XE<3>#8^@.89*P$#)O+'$"`P$``:."`=<P@@'3,!\&`U4=(P08,!: %))A
M:X+AHJ"J3^QG\<*C][2 `,'L,!T&`U4=#@06!!0P:UC0J,N<!7>SB(9<*/G'
MV*_ SS .!@-5'0\!`?\$! ,"!: P# 8#51T3`0'_! (P`# =!@-5'24$%C 4
M!@@K!@$%!0<#! 8(*P8!!04'`P(P1 at 8#51T@!#\P/3 [!@PK!@$$`;(Q`0(!
M`P4P*S I!@@K!@$%!0<"`18=:'1T<',Z+R]S96-U<F4N8V]M;V1O+FYE="]#
M4%,P708#51T?!%8P5#!2H%"@3H9,:'1T<#HO+V-R;"YC;VUO9&]C82YC;VTO
M0T]-3T1/4TA!,C4V0VQI96YT075T:&5N=&EC871I;VYA;F1396-U<F5%;6%I
M;$-!+F-R;#"!D 8(*P8!!04'`0$$@8,P at 8 P6 8(*P8!!04', *&3&AT=' Z
M+R]C<G0N8V]M;V1O8V$N8V]M+T-/34]$3U-(03(U-D-L:65N=$%U=&AE;G1I
M8V%T:6]N86YD4V5C=7)E16UA:6Q#02YC<G0P) 8(*P8!!04', &&&&AT=' Z
M+R]O8W-P+F-O;6]D;V-A+F-O;3 :!@-5'1$$$S 1 at 0]J:6U 8V%R<F]L;"YC
M;VTP#08)*H9(AO<-`0$+!0`#@@$!`&7_YE!"6I-N>DE*'QH34=CM%+[K`1M]
M]CL[U/FRY5[^LX>0V\F[3S&JAG>8?S4(\8%YC7"@FZN?&[XNG;*71FB1VC5\
M[C at 1T1/1VFB^.U_DY "31W;:;K"NZ]K)Q3#HO(@&45E,YCJ!NY$AC!C\IGQ:
M2/NGP"_K'85*^(.K.&Q*INS)?2E26GN'Y^%BLAID at HA<[DL&']YY*Z 9#&;V
MFJ3HYV^Y[HF)FFH-]D/]<5G):'.LJD*"]IJWI4,'-BQ;060E4[7[NKAN!^P\
MBTU&T;&8EQ; '\I'[_^.1-;+K'J.:_]/&2]A0 at L9SC^8NO*8S_4,>"4TRIOH
MI'J>$[1$P4TQ@@0C,(($'P(!`3"!L3"!FS$+, D&`U4$!A,"1T(Q&S 9!@-5
M! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'4V%L9F]R9#$:,!@&
M`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3.$-/34]$3R!32$$M
M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C=7)E($5M86EL($-!
M`A$`U0L/W1))=B:,GP%WEA?.YC )!@4K#@,"&@4`H(("1C 8!@DJADB&]PT!
M"0,Q"P8)*H9(AO<-`0<!,!P&"2J&2(;W#0$)!3$/%PTQ-C W,C$Q.3 X,C1:
M,",&"2J&2(;W#0$)!#$6!!1S_ [:J[,".;7][T8\$YD-7D@;"3!;!@DJADB&
M]PT!"0\Q3C!,, H&""J&2(;W#0,', X&""J&2(;W#0,"`@(`@# -!@@JADB&
M]PT#`@(!0# '!@4K#@,"!S -!@@JADB&]PT#`@(!*# '!@4K#@,"&C"!P at 8)
M*P8!! &"-Q $,8&T,(&Q,(&;,0LP"08#500&$P)'0C$;,!D&`U4$"!,21W)E
M871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#500*$Q%#
M3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR-38 at 0VQI
M96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$"$0#5"P_=
M$DEV)HR?`7>6%\[F,('$!@LJADB&]PT!"1 ""S&!M*"!L3"!FS$+, D&`U4$
M!A,"1T(Q&S 9!@-5! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'
M4V%L9F]R9#$:,!@&`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3
M.$-/34]$3R!32$$M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C
M=7)E($5M86EL($-!`A$`U0L/W1))=B:,GP%WEA?.YC -!@DJADB&]PT!`0$%
M``2"`0"G.B1[RQ!=L &0Z3Q- at 9;$GQ=T7TZ8J"IX&<2!M)=/5(JSW<BPTP]#
MO<GJ<\ACDRQ:DQ5LTO(?5=$/WP$4<N.^+BT985#9=.+$)$H12JV_SLN*F]=;
M<3P5-0LE6Z(@8"AFM"7^BBIQP:WII2G&89BR[:OE]DN8;4O&8N0,M\9<0P(_
MW,<'WF/,/&S%Z*()TVWUG&9 at 8D1YY=3?K6,^D<17_'@H)XU48P-1`?O4$,[G
M3ST,^ 0TW*P%._I75XYRN)<.L3*WVMJC]RB#Y2 ZR^QHP%,:GV"$FA2+<$F,
J8":S*= *5F8G7N/MD15V)MNEF^\/<S9[T^X^+ at BT\S.4@!TJ````````
`
end


From jim at carroll.com  Thu Jul 21 23:01:56 2016
From: jim at carroll.com (Jim Carroll)
Date: Thu, 21 Jul 2016 19:01:56 -0400
Subject: [openssl-users] X509 Version changes?
Message-ID: <001601d1e3a3$e1433eb0$a3c9bc10$@carroll.com>

I've run into what appears to be a change to defaults between 0.9.8 and
1.1.0, and I wanted to make sure it's not a bug we've introduced. 

While reviewing unittests, we see that calls to X509_REQ_new() generate an
X509 object with the version set to -1.  When we write this object to a PEM
file and read it back, the version is set then set to 0.  Is this expected
(GIGO) behavior?



begin 666 smime.p7s
M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$'
M`0``H((.$3""!#8P@@,>H ,"`0("`0$P#08)*H9(AO<-`0$%!0`P;S$+, D&
M`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T($%",28P) 8#500+$QU!9&14
M<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B," &`U4$`Q,9061D5')U<W0@
M17AT97)N86P at 0T$@4F]O=# >%PTP,# U,S Q,#0X,SA:%PTR,# U,S Q,#0X
M,SA:,&\Q"S )!@-5! 83`E-%,10P$@8#500*$PM!9&14<G5S="!!0C$F,"0&
M`U4$"Q,=061D5')U<W0 at 17AT97)N86P at 5%10($YE='=O<FLQ(C @!@-5! ,3
M&4%D9%1R=7-T($5X=&5R;F%L($-!(%)O;W0P@@$B, T&"2J&2(;W#0$!`04`
M`X(!#P`P@@$*`H(!`0"W]QHSYO(`!"TYX$Y;[1^\; _-M?HCML[>FQ$SEZ0I
M3'V3G[U*O)/M`QKCC\_E;5!:UI<IE%J L$EZVRZ5_;C*OS<X+1X^D4&M<%;'
M\$\_Z#*>=,K(D%3IQE\/>)V:0#P.K&&J7A2/GH>A:E#<UYI.KP6SIG&4G'&S
M4& *QQ.=. >&`JCIJ&DF&)"K3+!/(ZLZ3X38W\Z?X6EON]="UVM$Y,>M[FU!
M7W):<0 at WLWEEI%F at E#?W`"\-PI)RVM X<ML4J$7$72I]M[36Q.ZLS1-$M\DK
MW4,`)?IAN6EJ6",1MZ<SCU9U6?7-*==&MPHK9;;30F\5LKA[^^_I75/5-%HG
M`@,!``&C@=PP@=DP'08#51T.!!8$%*V]F'HTM";W^L0F5.\#O> DRU0:, L&
M`U4=#P0$`P(!!C /!@-5'1,!`?\$!3 #`0'_,(&9!@-5'2,$@9$P at 8Z %*V]
MF'HTM";W^L0F5.\#O> DRU0:H7.D<3!O,0LP"08#500&$P)313$4,!(&`U4$
M"A,+061D5')U<W0 at 04(Q)C D!@-5! L3'4%D9%1R=7-T($5X=&5R;F%L(%14
M4"!.971W;W)K,2(P( 8#500#$QE!9&14<G5S="!%>'1E<FYA;"!#02!2;V]T
M@@$!, T&"2J&2(;W#0$!!04``X(!`0"PF^"%)<+6(^(/E@:2G4&8G-F$>8'9
M'EL4!R,V98^PV'>[K$%L1V"#4;#Y,CWG_/8F$\> %J6_6OR'SWAYB2&:XDP'
M"H8UO/+>4<32EK?<?D[N</T<.>L,`E$4+8Z]%N#!WT9UYR2M[/1"M(63<!!G
MNIT&-4H8TRMZS%%"H7ICT>:[H<4KPC:^$PWFO6-^>7NG"0U JVK=CXK#]O:,
M&D(%4=1%]9^G8B%H%2!#/)GG?+TDV*F1%W.(/U8;,3 at 8M'$/FLW(#IZ.+AOA
MC)B#RQ\Q\41,Q at 1S279@#\?XO1> :R[IS$P.6IIY#R *+M6>8R8>59*4V((7
M6GO0O,>/3H8$,(($KS""`Y>@`P(!`@(1`. CRQ42 at U.)K6%N>E1G:R$P#08)
M*H9(AO<-`0$+!0`P;S$+, D&`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T
M($%",28P) 8#500+$QU!9&14<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B
M," &`U4$`Q,9061D5')U<W0 at 17AT97)N86P at 0T$@4F]O=# >%PTQ-#$R,C(P
M,# P,#!:%PTR,# U,S Q,#0X,SA:,(&;,0LP"08#500&$P)'0C$;,!D&`U4$
M"!,21W)E871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#
M500*$Q%#3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR
M-38 at 0VQI96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$P
M@@$B, T&"2J&2(;W#0$!`04``X(!#P`P@@$*`H(!`0")L0W:>E,93G!2';Q6
MI at 8FM[A)X);G4:OQ\%H3216CM(P;8+QZ44*G>8RD(M\784Z1U78C"A332@)_
MMAT)@&ZE!#W9NKL6_J&'J2Y#4D,6?*\R4,BF3UKI"-C/DR6<>XCH,&3FI/A6
M@/TJ)!0S%YFL1.5IBZ-&!DO",]3I0)\&L+&LDT"YM0B3.IPJ4Z,0VST at 83Q5
M`X[93G8E`B$I^J-\<79/[N%?@>G[5(#;PWLU4K>$WB(]+# M,7]9O5(WL#-I
M+4/K^M:E\9=W9U&,V>XGZ[RE!SAVC*2I./_?C/4#K$F^RO=SF3H/,JN<E3H3
M/0Y&.E=T85"^QD _R^3BGZ(A`@,!``&C@@$7,((!$S ?!@-5'2,$&# 6@!2M
MO9AZ-+0F]_K$)E3O`[W@),M4&C =!@-5'0X$%@04DF%K at N&BH*I/[&?QPJ/W
MM( `P>PP#@8#51T/`0'_! 0#`@&&,!(&`U4=$P$!_P0(, 8!`?\"`0`P'08#
M51TE!!8P% 8(*P8!!04'`P(&""L&`04%!P,$,!$&`U4=( 0*, @P!@8$51T@
M`#!$!@-5'1\$/3 [,#F at -Z UAC-H='1P.B\O8W)L+G5S97)T<G5S="YC;VTO
M061D5')U<W1%>'1E<FYA;$-!4F]O="YC<FPP-08(*P8!!04'`0$$*3 G,"4&
M""L&`04%!S !AAEH='1P.B\O;V-S<"YU<V5R=')U<W0N8V]M, T&"2J&2(;W
M#0$!"P4``X(!`0`;*FZL5<$ZJXC%V.W-5?.J:V$KP D0(YD/Q69J;['UM+5W
M7@\"80#??07^$K.D@( `_/L=6VIR`@I!O 6ZP5C5)L+JU4V$^_Z"F,]8&^,B
M8YQ2^+L%-JM]6*7>JSMCY=K5<^_LX/M[XJ/_\$(CG,JVC4T^Y$L8`[*H+=38
MNT)+D&F%$-NF-S3H>^ !$*6<RCK'GT^(-&Z*9= :BKNIW,K*-M'T_,)D*36O
MUK&G<1'2`T.QCSZ:[)XR4_1VDLJ&- >Y+,KF'$K8F0W!AN*0DOM:0FHC(1#I
M9<?UU;M^ZHR%( )BZM$Z!RQ9Q9DS\CB)Y;;I%GH?>13V2A :)OI\BON;,((%
M(#""! B@`P(!`@(1`-4+#]T2278FC)\!=Y87SN8P#08)*H9(AO<-`0$+!0`P
M at 9LQ"S )!@-5! 83`D=",1LP&08#500($Q)'<F5A=&5R($UA;F-H97-T97(Q
M$# .!@-5! <3!U-A;&9O<F0Q&C 8!@-5! H3$4-/34]$3R!#02!,:6UI=&5D
M,4$P/P8#500#$SA#3TU/1$\@4TA!+3(U-B!#;&EE;G0 at 075T:&5N=&EC871I
M;VX at 86YD(%-E8W5R92!%;6%I;"!#03 >%PTQ-C Q,3,P,# P,#!:%PTQ-S Q
M,3(R,S4Y-3E:," Q'C <!@DJADB&]PT!"0$6#VII;4!C87)R;VQL+F-O;3""
M`2(P#08)*H9(AO<-`0$!!0`#@@$/`#""`0H"@@$!`-K\XS'GF('[$TPZLMT=
MY]ID(UGI at 9^?K.$F3&?)JS.0Q"6)OD@;8S<+1#[2QFG.S045<BKJ-D6O9FQ\
M<*2_A$&HWT6R`S' 7$<4M7HIO_"G at U#-`1,6W2HZ`,L53(EL?:P_[H%Y/6VB
MJU\01/0U<U7T/"K$+CFK\>HV/H^"EPS!W)_L#3<"[3T(BZ3LDTHN"#(\B5A1
M^VO2XN77=+Z\+IU=@1UR!40:,<7&)5,P,O1STRE:UFFYLS65=GVT*:ZY[YK9
M':(_+75)?UCOJQ: M-%=9XH<_VNPXG^;7/:6"2-DDFNH3JMIBVKH$1G/E$ 9
MD8XE<3>#8^@.89*P$#)O+'$"`P$``:."`=<P@@'3,!\&`U4=(P08,!: %))A
M:X+AHJ"J3^QG\<*C][2 `,'L,!T&`U4=#@06!!0P:UC0J,N<!7>SB(9<*/G'
MV*_ SS .!@-5'0\!`?\$! ,"!: P# 8#51T3`0'_! (P`# =!@-5'24$%C 4
M!@@K!@$%!0<#! 8(*P8!!04'`P(P1 at 8#51T@!#\P/3 [!@PK!@$$`;(Q`0(!
M`P4P*S I!@@K!@$%!0<"`18=:'1T<',Z+R]S96-U<F4N8V]M;V1O+FYE="]#
M4%,P708#51T?!%8P5#!2H%"@3H9,:'1T<#HO+V-R;"YC;VUO9&]C82YC;VTO
M0T]-3T1/4TA!,C4V0VQI96YT075T:&5N=&EC871I;VYA;F1396-U<F5%;6%I
M;$-!+F-R;#"!D 8(*P8!!04'`0$$@8,P at 8 P6 8(*P8!!04', *&3&AT=' Z
M+R]C<G0N8V]M;V1O8V$N8V]M+T-/34]$3U-(03(U-D-L:65N=$%U=&AE;G1I
M8V%T:6]N86YD4V5C=7)E16UA:6Q#02YC<G0P) 8(*P8!!04', &&&&AT=' Z
M+R]O8W-P+F-O;6]D;V-A+F-O;3 :!@-5'1$$$S 1 at 0]J:6U 8V%R<F]L;"YC
M;VTP#08)*H9(AO<-`0$+!0`#@@$!`&7_YE!"6I-N>DE*'QH34=CM%+[K`1M]
M]CL[U/FRY5[^LX>0V\F[3S&JAG>8?S4(\8%YC7"@FZN?&[XNG;*71FB1VC5\
M[C at 1T1/1VFB^.U_DY "31W;:;K"NZ]K)Q3#HO(@&45E,YCJ!NY$AC!C\IGQ:
M2/NGP"_K'85*^(.K.&Q*INS)?2E26GN'Y^%BLAID at HA<[DL&']YY*Z 9#&;V
MFJ3HYV^Y[HF)FFH-]D/]<5G):'.LJD*"]IJWI4,'-BQ;060E4[7[NKAN!^P\
MBTU&T;&8EQ; '\I'[_^.1-;+K'J.:_]/&2]A0 at L9SC^8NO*8S_4,>"4TRIOH
MI'J>$[1$P4TQ@@0C,(($'P(!`3"!L3"!FS$+, D&`U4$!A,"1T(Q&S 9!@-5
M! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'4V%L9F]R9#$:,!@&
M`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3.$-/34]$3R!32$$M
M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C=7)E($5M86EL($-!
M`A$`U0L/W1))=B:,GP%WEA?.YC )!@4K#@,"&@4`H(("1C 8!@DJADB&]PT!
M"0,Q"P8)*H9(AO<-`0<!,!P&"2J&2(;W#0$)!3$/%PTQ-C W,C$R,S Q-35:
M,",&"2J&2(;W#0$)!#$6!!25V&84D^W+9\? ! O"8!5A#)#!K3!;!@DJADB&
M]PT!"0\Q3C!,, H&""J&2(;W#0,', X&""J&2(;W#0,"`@(`@# -!@@JADB&
M]PT#`@(!0# '!@4K#@,"!S -!@@JADB&]PT#`@(!*# '!@4K#@,"&C"!P at 8)
M*P8!! &"-Q $,8&T,(&Q,(&;,0LP"08#500&$P)'0C$;,!D&`U4$"!,21W)E
M871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#500*$Q%#
M3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR-38 at 0VQI
M96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$"$0#5"P_=
M$DEV)HR?`7>6%\[F,('$!@LJADB&]PT!"1 ""S&!M*"!L3"!FS$+, D&`U4$
M!A,"1T(Q&S 9!@-5! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'
M4V%L9F]R9#$:,!@&`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3
M.$-/34]$3R!32$$M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C
M=7)E($5M86EL($-!`A$`U0L/W1))=B:,GP%WEA?.YC -!@DJADB&]PT!`0$%
M``2"`0".%(\/;7FV;?>S?@K@<2ZO,8+(+M)NZR.V%(A+RRA1'<RID DC0%97
MQKX37BFIE%!6J92J^ F'*\" KHP*9RE$](DZ@>)B:.H(Q%![^^!N)G1IF]:L
MW$P8)SO'^4ZYH*Q(4ROI='BXLT(ZK[0@$Y2#6/*G_79HSVM^<Z9B.TOY& B"
M8%BO\%[GE,./'!FF;1^3RR_!D%P;6-]D]!@L:#%QE!0Z",\-*3<4:BG2:?2J
MS0TQZ)X)N*_>2&Y'<"C'>SBAW&Z\T)P&33-FD$/CN 3U.4":1UT=]-S9X\&(
JNDG:2+,OH,,[XE6'P9,Q;[(RO4AOV)]A[WZ,2%(NZ2B9Q\R6````````
`
end


From Saurabh.Gupta at cavium.com  Fri Jul 22 06:44:48 2016
From: Saurabh.Gupta at cavium.com (Gupta, Saurabh)
Date: Fri, 22 Jul 2016 06:44:48 +0000
Subject: [openssl-users] Openssl software failure for RSA 16K modulus
Message-ID: <BN3PR07MB2467C715E5093E51C5D7B8FB970A0@BN3PR07MB2467.namprd07.prod.outlook.com>

1: I didn't get it, Why this behaviour is not coming for other ciphers while doing the server/client handshake?

It should fail for other ciphers also.


Ciphers:  working

DHE-RSA-AES128-SHA
ECDHE-RSA-AES256-GCM-SHA384
...... etc

Ciphers: Not working
AES128-SHA
AES256-SHA
...... etc


Protocols:

tls1/tls1_1/tls1_2


2: if anyway I want to use 16k modulus, Do we have solution to avoid this issue so that it won't harm to other application or create any new attack?

3: ECC cipher is not my main concerned.

4: I didn't face any issue like memory utilisation or CPU utilisation is more if I'm running more than one client in the case of 16k modulus.

Regards,
Saurabh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160722/2ce87bce/attachment.html>

From rsalz at akamai.com  Fri Jul 22 07:53:05 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 22 Jul 2016 07:53:05 +0000
Subject: [openssl-users] Openssl software failure for RSA 16K modulus
In-Reply-To: <BN3PR07MB2467C715E5093E51C5D7B8FB970A0@BN3PR07MB2467.namprd07.prod.outlook.com>
References: <BN3PR07MB2467C715E5093E51C5D7B8FB970A0@BN3PR07MB2467.namprd07.prod.outlook.com>
Message-ID: <2243e51be81440bca71693be9584a93d@usma1ex-dag1mb1.msg.corp.akamai.com>

> 2: if anyway I want to use 16k modulus, Do we have solution to avoid this issue so that it won't harm to other application or create any new attack?

No.


From Saurabh.Gupta at cavium.com  Fri Jul 22 09:52:08 2016
From: Saurabh.Gupta at cavium.com (Gupta, Saurabh)
Date: Fri, 22 Jul 2016 09:52:08 +0000
Subject: [openssl-users] Openssl software failure for RSA 16K modulus
Message-ID: <BN3PR07MB2467EFC04C9D501B28B9D407970A0@BN3PR07MB2467.namprd07.prod.outlook.com>

> The DoS issue is still there.  How can you prevent the "other side" from consuming all your CPU with a large key?

> Who needs 16K RSA keys, such that openssl by default should support that for everyone?


We have cryptographic accelerators on cavium platforms which minimize CPU usage. So our customers are looking for 16K support.


Regards,
Saurabh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160722/14b5890d/attachment.html>

From Erwann.Abalea at docusign.com  Fri Jul 22 09:59:17 2016
From: Erwann.Abalea at docusign.com (Erwann Abalea)
Date: Fri, 22 Jul 2016 09:59:17 +0000
Subject: [openssl-users] Openssl software failure for RSA 16K modulus
In-Reply-To: <BN3PR07MB2467C715E5093E51C5D7B8FB970A0@BN3PR07MB2467.namprd07.prod.outlook.com>
References: <BN3PR07MB2467C715E5093E51C5D7B8FB970A0@BN3PR07MB2467.namprd07.prod.outlook.com>
Message-ID: <806A89EC-D7FB-48ED-9A9C-B7C25447D2E5@docusign.com>

Bonjour,

Le 22 juil. 2016 ? 08:44, Gupta, Saurabh <Saurabh.Gupta at cavium.com<mailto:Saurabh.Gupta at cavium.com>> a ?crit :


1: I didn't get it, Why this behaviour is not coming for other ciphers while doing the server/client handshake?

It should fail for other ciphers also.


Ciphers:  working

DHE-RSA-AES128-SHA
ECDHE-RSA-AES256-GCM-SHA384
...... etc

Because the key exchange is performed using DHE or ECDHE here, and parameters are much smaller than your server authentication key.
If you configure a 16k DH group and choose to use DHE as the key exchange algorithm, you?ll surely fall under the same error.

Ciphers: Not working
AES128-SHA
AES256-SHA
...... etc

RSA key exchange.

2: if anyway I want to use 16k modulus, Do we have solution to avoid this issue so that it won't harm to other application or create any new attack?

3: ECC cipher is not my main concerned.

You should be concerned about the security provided by your choices, and not pure raw numbers.


4: I didn't face any issue like memory utilisation or CPU utilisation is more if I'm running more than one client in the case of 16k modulus.

Your measuring tools are bad, change them ;)
Signing with a 16k RSA key is way slower than with a 2048bits key, and again way slower than using ECC.

According to NIST, equivalent ? security levels ?:
RSA15360, DH15360, ECC512 (or 521)
RSA7680, DH7680, ECC384
RSA3072, DH3072, ECC256

Measurements done on my machine:
Signing with ECDSA over the P521 curve is 600x faster than signing with a 15kRSA key.
Performing a key exchange with ECDH over the P521 curve is about 180x faster than decrypting with a 15k RSA key.

Using the P384 curve and a 7kRSA key, the numbers are 180x faster and 50x faster.
Using the P256 curve and a 4kRSA key, numbers are about 90x faster for both operations.

I don?t have any measurements for DH key exchange, but it should cost twice more than doing a private RSA operation, and also impacts the client, and when used within TLS it comes in addition to an RSA signing operation.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160722/22c74b70/attachment-0001.html>

From rsalz at akamai.com  Fri Jul 22 10:23:56 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 22 Jul 2016 10:23:56 +0000
Subject: [openssl-users] Openssl software failure for RSA 16K modulus
In-Reply-To: <BN3PR07MB2467EFC04C9D501B28B9D407970A0@BN3PR07MB2467.namprd07.prod.outlook.com>
References: <BN3PR07MB2467EFC04C9D501B28B9D407970A0@BN3PR07MB2467.namprd07.prod.outlook.com>
Message-ID: <b89f926ff72f417fb757fff264942770@usma1ex-dag1mb1.msg.corp.akamai.com>

> We have cryptographic accelerators on cavium platforms which minimize CPU usage. So our customers are looking for 16K support.

Well, sorry, but by default most other sides won't be able to use them.  Not sure anything else to say.

From mcepl at cepl.eu  Fri Jul 22 13:32:36 2016
From: mcepl at cepl.eu (=?UTF-8?Q?Mat=c4=9bj_Cepl?=)
Date: Fri, 22 Jul 2016 15:32:36 +0200
Subject: [openssl-users] [ANN] M2Crypto 0.25.0
Message-ID: <16b7fe89-8965-7e1d-2e12-6bffd7bd8de1@cepl.eu>

Hi, everybody,

after trials and tribulations I have the honor to announce new release
of M2Crypto 0.25.0. This is an intermediary version on our way towards
port to python 3 (or rather to the bi-versional state of both py2k and
py3k compatibility). Particularly we have made these achievements (whole
changelog since 0.21.1 follows, because I am not sure whether previous
changes were properly announced).

Of course any help on python3 porting branch
(https://gitlab.com/m2crypto/m2crypto/merge_requests/65) is very welcome!

Happy security hacking!

Mat?j

-- 
https://matej.ceplovi.cz/blog/, Jabber: mcepl at ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8

Do not long for the night, when people vanish in their place.
Be careful, do not turn to evil; for you have preferred this to
affliction.
      -- Job 36:20f (NASB)
=================================================================

0.25.0 - 2016-03-21
-------------------
- More cleanups, removal of obsolete stuff, and moves towards py3k
  compatibility.
- Add support for EC.get_builtin_curves() and use it for testing.
- Enable AES CTR mode
- Bundle-in six module v. 1.10.0
- add rand_file_name and rand_status
- remove all LHASH fiddling
- Extend Travis and GitLab CI configuration to test also py3k (with
  allowed_failures) and CentOS6 (on GitLab CI).
- Add CONTRIBUTORS.rst. Thank you!
- Add PEP-484 type hints in comments to all Python files (except for
  tests)
- Use context managers for file handling wherever possible instead of
  leaking open file descriptors.
- Improve defaults handling for SSL_CTX_new().
- Fix PGP tests to actually run

0.24.0 - 2016-03-21
-------------------
- More cleanups, removal of obsolete stuff, and moves towards py3k
  compatibility.
- Add DSA.pub_key_from_params() factory function (and m2.dsa_set_pub()).
- Allow import/export of EC public key with binary values
- Add EVP.load_key_string_pubkey() function, as well as helper functions
- Add EVP.get_digestbyname() functionality.
- Convert documentation to rST (and add instructions for building on Mac
  OS X)
- Another round of fixing multiarch building.
- Disable tests with weak ciphers on some platforms (Debain)

0.23.0 - 2016-01-29
-------------------
- Add Travis and GitLab CI configurations
- Allow building without SSLv2
- More cleanups and removing obsolete code
- Fix README
- Fix buffer overflow in pkcs5_pbkdf2_hmac_sha1
- First moves towards Python 3 compatibility
- Removed rather large and completely unmaintained demo/ subdirectory
  (now in a separate repo https://gitlab.com/m2crypto/m2crypto_demo)
- Automatically generated test data files
- Finally fix building on multiarch systems
- All objects derived from BIO.BIO now could work as context managers
- Switch setup.py to setuptools

0.22.5 - 2015-10-13
-------------------
- Add forgoteen SWIG/*.h among distributed files.

0.22.4 - 2015-10-13
-------------------
- Mat?j Cepl takes over leadership of the upstream maintenance
- Fedora/RHEL distribution patches merged to the main development
  (mainly, but not only, upgrading to the more recent versions of
  OpenSSL, swig which is now at 3.0.5, but anything above 2.0.4 is
  supported as well, and python which now has to be at least 2.6).
- Tons of cleaning up the code for obsolete constructs, PEP8ization,
  etc.

0.22.3 - 2014-01-22
-------------------
(released by Martin Paljak, later development started on top of 0.21.1
with his improvements cherry picked to the new development branch)

0.21.1 - 2011-01-15
-------------------
- Distribution fix



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160722/28b76737/attachment.sig>

From jim at carroll.com  Tue Jul 26 14:25:24 2016
From: jim at carroll.com (Jim Carroll)
Date: Tue, 26 Jul 2016 10:25:24 -0400
Subject: [openssl-users] PKCS7_sign conflict with PKCS7_decrypt?
Message-ID: <008401d1e749$8d021d90$a70658b0$@carroll.com>

Running into trouble -- any attempt to PKCS7_decrypt() S/MIME content that
was created with PKCS7_sign()+PKCS7_encrypt() yields an empty result set.  I
have the distinct impression I'm doing something dumb -- but several days of
debugging I'm completely stuck.

I've created an MVCE and included it below. The code was built and run on
Windows 8.1 Pro, Visual C++ 2008 Express, using OpenSSL 1.1.0-pre6-dev
(32-bit build).

Interesting point -- If I remove the PKCS7_sign() code, I have no problem
encrypting and decrypting the content. I strongly suspect my issue has
something todo with S/MIME headers interfering with encryption or
decryption.  But that theory would suggest there's a bug in OpenSSL's S/MIME
handling. I find that hard to swallow -- more likely I'm missing some sort
of required flag.

One more point -- I understand Sign-then-Encrypt has weaknesses and may not
be recommended (http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html).
The reason I'm even trying to debug this is to complete the port of an
M2Crypto unittest to OpenSSL 1.1.0, which means the procedure works
acceptably under OpenSSL 0.9.8.

Any assistance would be greatly appreciated


---------------- Here is the output from running the code

>>> Version OpenSSL 1.1.0-pre6-dev  xx XXX xxxx (0x10100006)
>>> Generate keys and certs
Generating a 1024 bit RSA private key
...............++++++
.............................................++++++
writing new private key to 'signer_key.pem'
-----
Generating a 1024 bit RSA private key
......................++++++
.........................++++++
writing new private key to 'recipient_key.pem'
-----
>>> Read keys and certs
>>> Create recipient cert stack (for encryption)
>>> Sign
>>> Generate signed S/MIME
>>> Encrypt
>>> Generate encrypted S/MIME
>>> Convert S/MIME to PKCS7
>>> Decrypt PKCS7
decrypted text => len -1 ''
mismatched response size




---------------- MVCE CODE

#include "stdafx.h"

#include <string.h>

#pragma warning(disable:4996)
#include <openssl/applink.c>
#include <openssl/bio.h>
#include <openssl/err.h>
#include <openssl/pem.h>
#include <openssl/x509.h>

#pragma comment(lib, "libcrypto")

EVP_PKEY *load_key(const char fname[]);
X509 *load_cert(const char fname[]);

int _tmain(int argc, _TCHAR* argv[]) {
    BIO *mem, *bcont;
    EVP_PKEY *signer_pkey, *rcpt_pkey;
    PKCS7 *p7;
    STACK_OF(X509) *rcpt_stack;
    X509 *signer_cert, *rcpt_cert;
    char cleartext[] = "some text to manipulate";
    char text[128];
    const EVP_CIPHER *cipher = EVP_des_ede3_cbc();
    int len, rc;

    printf(">>> Version %s (0x%lx)\n", OPENSSL_VERSION_TEXT, 
            OPENSSL_VERSION_NUMBER);

    printf(">>> Generate keys and certs\n");

    if ((rc = system("openssl req -new -x509 -nodes "
        "-subj /C=US/ST=STATE/CN=localhost/emailAddress=signer at example.com "
        "-newkey rsa:1024 -keyout signer_key.pem -out signer_cert.pem"))) {
        printf("error %d generating signer cert", rc);
        return -1;
        }
    if ((rc = system("openssl req -new -x509 -nodes "
        "-subj
/C=US/ST=STATE/CN=localhost/emailAddress=recipient at example.com "
        "-newkey rsa:1024 -keyout recipient_key.pem -out
recipient_cert.pem"))) {
        printf("error %d generating recipient cert", rc);
        return -1;
        }

    printf(">>> Read keys and certs\n");

    if (!(signer_pkey = load_key("signer_key.pem")) ||
        !(signer_cert = load_cert("signer_cert.pem")) ||
        !(rcpt_pkey = load_key("recipient_key.pem")) ||
        !(rcpt_cert = load_cert("recipient_cert.pem")))
        return -1;

    printf(">>> Create recipient cert stack (for encryption)\n");

    if (!(rcpt_stack = sk_X509_new_null()) || 
        !sk_X509_push(rcpt_stack, rcpt_cert)) {
        ERR_print_errors_fp(stdout);
        return -1;
        }

    printf(">>> Sign\n");

    if (!(mem = BIO_new_mem_buf(cleartext, sizeof(cleartext))) ||
        !(p7 = PKCS7_sign(signer_cert, signer_pkey, NULL, mem, 0))) {
        ERR_print_errors_fp(stdout);
        return -1;
        }
    BIO_free(mem);

    printf(">>> Generate signed S/MIME\n");

    if (!(mem = BIO_new(BIO_s_mem())) ||
        !SMIME_write_PKCS7(mem, p7, NULL, 0)) {
        ERR_print_errors_fp(stdout);
        return -1;
        }
    PKCS7_free(p7);

    printf(">>> Encrypt\n");

    BIO_set_mem_eof_return(mem, 0);
    if (!(p7 = PKCS7_encrypt(rcpt_stack, mem, cipher, 0))) {
        ERR_print_errors_fp(stdout);
        return -1;
        }
    BIO_free(mem);

    printf(">>> Generate encrypted S/MIME\n");

    if (!(mem = BIO_new(BIO_s_mem())) ||
        !SMIME_write_PKCS7(mem, p7, NULL, 0)) {
        ERR_print_errors_fp(stdout);
        return -1;
        }
    PKCS7_free(p7);

    printf(">>> Convert S/MIME to PKCS7\n");

    BIO_set_mem_eof_return(mem, 0);
    if (!(p7 = SMIME_read_PKCS7(mem, &bcont))) {
        ERR_print_errors_fp(stdout);
        return -1;
        }
    BIO_free(mem);

    printf(">>> Decrypt PKCS7\n");

    if (!(mem = BIO_new(BIO_s_mem())) ||
        !PKCS7_decrypt(p7, rcpt_pkey, rcpt_cert, mem, 0)) {
        ERR_print_errors_fp(stdout);
        return -1;
        }

    len = BIO_read(mem, text, sizeof(text));
    printf("decrypted text => len %d '%s'\n", len, len > 0 ? text : "");
    if (len != strlen(cleartext))
        printf("mismatched response size\n");
    else if (strcmp(cleartext, text) != 0)
        printf("mismatched content\n");

    return 0;
    }

EVP_PKEY *load_key(const char fname[]) {
    BIO *bio = NULL;
    EVP_PKEY *key = NULL;
    if (!(bio = BIO_new_file(fname, "r")) ||
        !(key = PEM_read_bio_PrivateKey(bio, NULL, NULL, NULL))) {
        printf("error reading keyfile: %s\n", fname);
        ERR_print_errors_fp(stdout);
        }
    BIO_free(bio);
    return key;
    }

X509 *load_cert(const char fname[]) {
    BIO *bio = NULL;
    X509 *cert = NULL;
    if (!(bio = BIO_new_file(fname, "r")) ||
        !(cert = PEM_read_bio_X509(bio, NULL, NULL, NULL))) {
        printf("error reading certfile: %s\n", fname);
        ERR_print_errors_fp(stdout);
        }
    BIO_free(bio);
    return cert;
    }


begin 666 smime.p7s
M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$'
M`0``H((.$3""!#8P@@,>H ,"`0("`0$P#08)*H9(AO<-`0$%!0`P;S$+, D&
M`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T($%",28P) 8#500+$QU!9&14
M<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B," &`U4$`Q,9061D5')U<W0@
M17AT97)N86P at 0T$@4F]O=# >%PTP,# U,S Q,#0X,SA:%PTR,# U,S Q,#0X
M,SA:,&\Q"S )!@-5! 83`E-%,10P$@8#500*$PM!9&14<G5S="!!0C$F,"0&
M`U4$"Q,=061D5')U<W0 at 17AT97)N86P at 5%10($YE='=O<FLQ(C @!@-5! ,3
M&4%D9%1R=7-T($5X=&5R;F%L($-!(%)O;W0P@@$B, T&"2J&2(;W#0$!`04`
M`X(!#P`P@@$*`H(!`0"W]QHSYO(`!"TYX$Y;[1^\; _-M?HCML[>FQ$SEZ0I
M3'V3G[U*O)/M`QKCC\_E;5!:UI<IE%J L$EZVRZ5_;C*OS<X+1X^D4&M<%;'
M\$\_Z#*>=,K(D%3IQE\/>)V:0#P.K&&J7A2/GH>A:E#<UYI.KP6SIG&4G'&S
M4& *QQ.=. >&`JCIJ&DF&)"K3+!/(ZLZ3X38W\Z?X6EON]="UVM$Y,>M[FU!
M7W):<0 at WLWEEI%F at E#?W`"\-PI)RVM X<ML4J$7$72I]M[36Q.ZLS1-$M\DK
MW4,`)?IAN6EJ6",1MZ<SCU9U6?7-*==&MPHK9;;30F\5LKA[^^_I75/5-%HG
M`@,!``&C@=PP@=DP'08#51T.!!8$%*V]F'HTM";W^L0F5.\#O> DRU0:, L&
M`U4=#P0$`P(!!C /!@-5'1,!`?\$!3 #`0'_,(&9!@-5'2,$@9$P at 8Z %*V]
MF'HTM";W^L0F5.\#O> DRU0:H7.D<3!O,0LP"08#500&$P)313$4,!(&`U4$
M"A,+061D5')U<W0 at 04(Q)C D!@-5! L3'4%D9%1R=7-T($5X=&5R;F%L(%14
M4"!.971W;W)K,2(P( 8#500#$QE!9&14<G5S="!%>'1E<FYA;"!#02!2;V]T
M@@$!, T&"2J&2(;W#0$!!04``X(!`0"PF^"%)<+6(^(/E@:2G4&8G-F$>8'9
M'EL4!R,V98^PV'>[K$%L1V"#4;#Y,CWG_/8F$\> %J6_6OR'SWAYB2&:XDP'
M"H8UO/+>4<32EK?<?D[N</T<.>L,`E$4+8Z]%N#!WT9UYR2M[/1"M(63<!!G
MNIT&-4H8TRMZS%%"H7ICT>:[H<4KPC:^$PWFO6-^>7NG"0U JVK=CXK#]O:,
M&D(%4=1%]9^G8B%H%2!#/)GG?+TDV*F1%W.(/U8;,3 at 8M'$/FLW(#IZ.+AOA
MC)B#RQ\Q\41,Q at 1S279@#\?XO1> :R[IS$P.6IIY#R *+M6>8R8>59*4V((7
M6GO0O,>/3H8$,(($KS""`Y>@`P(!`@(1`. CRQ42 at U.)K6%N>E1G:R$P#08)
M*H9(AO<-`0$+!0`P;S$+, D&`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T
M($%",28P) 8#500+$QU!9&14<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B
M," &`U4$`Q,9061D5')U<W0 at 17AT97)N86P at 0T$@4F]O=# >%PTQ-#$R,C(P
M,# P,#!:%PTR,# U,S Q,#0X,SA:,(&;,0LP"08#500&$P)'0C$;,!D&`U4$
M"!,21W)E871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#
M500*$Q%#3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR
M-38 at 0VQI96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$P
M@@$B, T&"2J&2(;W#0$!`04``X(!#P`P@@$*`H(!`0")L0W:>E,93G!2';Q6
MI at 8FM[A)X);G4:OQ\%H3216CM(P;8+QZ44*G>8RD(M\784Z1U78C"A332@)_
MMAT)@&ZE!#W9NKL6_J&'J2Y#4D,6?*\R4,BF3UKI"-C/DR6<>XCH,&3FI/A6
M@/TJ)!0S%YFL1.5IBZ-&!DO",]3I0)\&L+&LDT"YM0B3.IPJ4Z,0VST at 83Q5
M`X[93G8E`B$I^J-\<79/[N%?@>G[5(#;PWLU4K>$WB(]+# M,7]9O5(WL#-I
M+4/K^M:E\9=W9U&,V>XGZ[RE!SAVC*2I./_?C/4#K$F^RO=SF3H/,JN<E3H3
M/0Y&.E=T85"^QD _R^3BGZ(A`@,!``&C@@$7,((!$S ?!@-5'2,$&# 6@!2M
MO9AZ-+0F]_K$)E3O`[W@),M4&C =!@-5'0X$%@04DF%K at N&BH*I/[&?QPJ/W
MM( `P>PP#@8#51T/`0'_! 0#`@&&,!(&`U4=$P$!_P0(, 8!`?\"`0`P'08#
M51TE!!8P% 8(*P8!!04'`P(&""L&`04%!P,$,!$&`U4=( 0*, @P!@8$51T@
M`#!$!@-5'1\$/3 [,#F at -Z UAC-H='1P.B\O8W)L+G5S97)T<G5S="YC;VTO
M061D5')U<W1%>'1E<FYA;$-!4F]O="YC<FPP-08(*P8!!04'`0$$*3 G,"4&
M""L&`04%!S !AAEH='1P.B\O;V-S<"YU<V5R=')U<W0N8V]M, T&"2J&2(;W
M#0$!"P4``X(!`0`;*FZL5<$ZJXC%V.W-5?.J:V$KP D0(YD/Q69J;['UM+5W
M7@\"80#??07^$K.D@( `_/L=6VIR`@I!O 6ZP5C5)L+JU4V$^_Z"F,]8&^,B
M8YQ2^+L%-JM]6*7>JSMCY=K5<^_LX/M[XJ/_\$(CG,JVC4T^Y$L8`[*H+=38
MNT)+D&F%$-NF-S3H>^ !$*6<RCK'GT^(-&Z*9= :BKNIW,K*-M'T_,)D*36O
MUK&G<1'2`T.QCSZ:[)XR4_1VDLJ&- >Y+,KF'$K8F0W!AN*0DOM:0FHC(1#I
M9<?UU;M^ZHR%( )BZM$Z!RQ9Q9DS\CB)Y;;I%GH?>13V2A :)OI\BON;,((%
M(#""! B@`P(!`@(1`-4+#]T2278FC)\!=Y87SN8P#08)*H9(AO<-`0$+!0`P
M at 9LQ"S )!@-5! 83`D=",1LP&08#500($Q)'<F5A=&5R($UA;F-H97-T97(Q
M$# .!@-5! <3!U-A;&9O<F0Q&C 8!@-5! H3$4-/34]$3R!#02!,:6UI=&5D
M,4$P/P8#500#$SA#3TU/1$\@4TA!+3(U-B!#;&EE;G0 at 075T:&5N=&EC871I
M;VX at 86YD(%-E8W5R92!%;6%I;"!#03 >%PTQ-C Q,3,P,# P,#!:%PTQ-S Q
M,3(R,S4Y-3E:," Q'C <!@DJADB&]PT!"0$6#VII;4!C87)R;VQL+F-O;3""
M`2(P#08)*H9(AO<-`0$!!0`#@@$/`#""`0H"@@$!`-K\XS'GF('[$TPZLMT=
MY]ID(UGI at 9^?K.$F3&?)JS.0Q"6)OD@;8S<+1#[2QFG.S045<BKJ-D6O9FQ\
M<*2_A$&HWT6R`S' 7$<4M7HIO_"G at U#-`1,6W2HZ`,L53(EL?:P_[H%Y/6VB
MJU\01/0U<U7T/"K$+CFK\>HV/H^"EPS!W)_L#3<"[3T(BZ3LDTHN"#(\B5A1
M^VO2XN77=+Z\+IU=@1UR!40:,<7&)5,P,O1STRE:UFFYLS65=GVT*:ZY[YK9
M':(_+75)?UCOJQ: M-%=9XH<_VNPXG^;7/:6"2-DDFNH3JMIBVKH$1G/E$ 9
MD8XE<3>#8^@.89*P$#)O+'$"`P$``:."`=<P@@'3,!\&`U4=(P08,!: %))A
M:X+AHJ"J3^QG\<*C][2 `,'L,!T&`U4=#@06!!0P:UC0J,N<!7>SB(9<*/G'
MV*_ SS .!@-5'0\!`?\$! ,"!: P# 8#51T3`0'_! (P`# =!@-5'24$%C 4
M!@@K!@$%!0<#! 8(*P8!!04'`P(P1 at 8#51T@!#\P/3 [!@PK!@$$`;(Q`0(!
M`P4P*S I!@@K!@$%!0<"`18=:'1T<',Z+R]S96-U<F4N8V]M;V1O+FYE="]#
M4%,P708#51T?!%8P5#!2H%"@3H9,:'1T<#HO+V-R;"YC;VUO9&]C82YC;VTO
M0T]-3T1/4TA!,C4V0VQI96YT075T:&5N=&EC871I;VYA;F1396-U<F5%;6%I
M;$-!+F-R;#"!D 8(*P8!!04'`0$$@8,P at 8 P6 8(*P8!!04', *&3&AT=' Z
M+R]C<G0N8V]M;V1O8V$N8V]M+T-/34]$3U-(03(U-D-L:65N=$%U=&AE;G1I
M8V%T:6]N86YD4V5C=7)E16UA:6Q#02YC<G0P) 8(*P8!!04', &&&&AT=' Z
M+R]O8W-P+F-O;6]D;V-A+F-O;3 :!@-5'1$$$S 1 at 0]J:6U 8V%R<F]L;"YC
M;VTP#08)*H9(AO<-`0$+!0`#@@$!`&7_YE!"6I-N>DE*'QH34=CM%+[K`1M]
M]CL[U/FRY5[^LX>0V\F[3S&JAG>8?S4(\8%YC7"@FZN?&[XNG;*71FB1VC5\
M[C at 1T1/1VFB^.U_DY "31W;:;K"NZ]K)Q3#HO(@&45E,YCJ!NY$AC!C\IGQ:
M2/NGP"_K'85*^(.K.&Q*INS)?2E26GN'Y^%BLAID at HA<[DL&']YY*Z 9#&;V
MFJ3HYV^Y[HF)FFH-]D/]<5G):'.LJD*"]IJWI4,'-BQ;060E4[7[NKAN!^P\
MBTU&T;&8EQ; '\I'[_^.1-;+K'J.:_]/&2]A0 at L9SC^8NO*8S_4,>"4TRIOH
MI'J>$[1$P4TQ@@0C,(($'P(!`3"!L3"!FS$+, D&`U4$!A,"1T(Q&S 9!@-5
M! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'4V%L9F]R9#$:,!@&
M`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3.$-/34]$3R!32$$M
M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C=7)E($5M86EL($-!
M`A$`U0L/W1))=B:,GP%WEA?.YC )!@4K#@,"&@4`H(("1C 8!@DJADB&]PT!
M"0,Q"P8)*H9(AO<-`0<!,!P&"2J&2(;W#0$)!3$/%PTQ-C W,C8Q-#(U,C-:
M,",&"2J&2(;W#0$)!#$6!!0<';A(TR 3G49706:]>ZML"&UX$#!;!@DJADB&
M]PT!"0\Q3C!,, H&""J&2(;W#0,', X&""J&2(;W#0,"`@(`@# -!@@JADB&
M]PT#`@(!0# '!@4K#@,"!S -!@@JADB&]PT#`@(!*# '!@4K#@,"&C"!P at 8)
M*P8!! &"-Q $,8&T,(&Q,(&;,0LP"08#500&$P)'0C$;,!D&`U4$"!,21W)E
M871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#500*$Q%#
M3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR-38 at 0VQI
M96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$"$0#5"P_=
M$DEV)HR?`7>6%\[F,('$!@LJADB&]PT!"1 ""S&!M*"!L3"!FS$+, D&`U4$
M!A,"1T(Q&S 9!@-5! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'
M4V%L9F]R9#$:,!@&`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3
M.$-/34]$3R!32$$M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C
M=7)E($5M86EL($-!`A$`U0L/W1))=B:,GP%WEA?.YC -!@DJADB&]PT!`0$%
M``2"`0`X8UMHRZC;[0?$\65.4:_VF*Q!OS>;K_S5KA<$]28 at A8'M]4H.7L/?
M`GQ_N at F,M4"G"CB#1"LUS$1?/$!)@2@#]H,SFZ72ZEH;Y-_)J[SU+1NPB:5N
MK at U6X>_F#0<6B VE018PGQZ?#:7L\@H&XI.2/9U[9CZ]R(-$DVN'-_B]7.R<
MI$Z:<$'?Q[0`O0/!@=2XEW/USH\\"5&2:'Q2!PUIO^RUSRFV\*MV'AXOSA+L
MD at RN,GS$V#E25?E_$CC_H3'J1'0WTQP at OE #PTG#%SUU"" ;UR at FP*]L=AD#
J"DEXEF5L^$[[QP8HW3A8=CT;+Q33&2G#"-WT4: 4RIU3,=3^````````
`
end


From piotr.panasewicz at mac.com  Tue Jul 26 14:09:00 2016
From: piotr.panasewicz at mac.com (Piotr Panasewicz)
Date: Tue, 26 Jul 2016 16:09:00 +0200
Subject: [openssl-users] How to properly build OpenSSL with certificates
	inside certs directory
Message-ID: <68CA3C5A-1D54-4AD6-A740-1BB1D210E01F@mac.com>

Hi,

There?s seems to be no good explanation on the website on how to build OpenSSL with CA certificates so I thought I?ll give a try here.
I?ve copied all the CA certs I have to the certs folder and built, unfortunately I still get certificate validation errors with the library I uses (it links to OpenSSL dynamically).
I have all the CA certs in pem format, should I include some kind of flag or do something else?

Thanks in advance,
Peter



From steve at openssl.org  Tue Jul 26 15:21:44 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 26 Jul 2016 15:21:44 +0000
Subject: [openssl-users] PKCS7_sign conflict with PKCS7_decrypt?
In-Reply-To: <008401d1e749$8d021d90$a70658b0$@carroll.com>
References: <008401d1e749$8d021d90$a70658b0$@carroll.com>
Message-ID: <20160726152144.GA6638@openssl.org>

On Tue, Jul 26, 2016, Jim Carroll wrote:

> Running into trouble -- any attempt to PKCS7_decrypt() S/MIME content that
> was created with PKCS7_sign()+PKCS7_encrypt() yields an empty result set.  I
> have the distinct impression I'm doing something dumb -- but several days of
> debugging I'm completely stuck.
> 
> I've created an MVCE and included it below. The code was built and run on
> Windows 8.1 Pro, Visual C++ 2008 Express, using OpenSSL 1.1.0-pre6-dev
> (32-bit build).
> 
> Interesting point -- If I remove the PKCS7_sign() code, I have no problem
> encrypting and decrypting the content. I strongly suspect my issue has
> something todo with S/MIME headers interfering with encryption or
> decryption.  But that theory would suggest there's a bug in OpenSSL's S/MIME
> handling. I find that hard to swallow -- more likely I'm missing some sort
> of required flag.
> 

What you're doing is sign followed by encrypt which gives a signed messsage
within an encrypted one.

Then you just decrypt which ends up giving you the signed content back. So if
you want to process that you have to verify it first.

Note there is a big in the current master which breaks CMS/PKCS#7 (overlapping
buffers check) so you'll have to either try an earlier version or wait for it
to be fixed.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From steve at openssl.org  Tue Jul 26 15:22:32 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 26 Jul 2016 15:22:32 +0000
Subject: [openssl-users] X509 Version changes?
In-Reply-To: <001601d1e3a3$e1433eb0$a3c9bc10$@carroll.com>
References: <001601d1e3a3$e1433eb0$a3c9bc10$@carroll.com>
Message-ID: <20160726152232.GB6638@openssl.org>

On Thu, Jul 21, 2016, Jim Carroll wrote:

> I've run into what appears to be a change to defaults between 0.9.8 and
> 1.1.0, and I wanted to make sure it's not a bug we've introduced. 
> 
> While reviewing unittests, we see that calls to X509_REQ_new() generate an
> X509 object with the version set to -1.  When we write this object to a PEM
> file and read it back, the version is set then set to 0.  Is this expected
> (GIGO) behavior?
> 

Can you give a few more details about how you are doing this?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From jim at carroll.com  Tue Jul 26 15:28:47 2016
From: jim at carroll.com (Jim Carroll)
Date: Tue, 26 Jul 2016 11:28:47 -0400
Subject: [openssl-users] PKCS7_sign conflict with PKCS7_decrypt?
In-Reply-To: <20160726152144.GA6638@openssl.org>
References: <008401d1e749$8d021d90$a70658b0$@carroll.com>
 <20160726152144.GA6638@openssl.org>
Message-ID: <00a201d1e752$67c23390$37469ab0$@carroll.com>

Steve -- thanks, but I don't think I was clear enough. 

I am trying to get back the signed content, but when I call PKCS7_decrpyt()
I get back an empty buffer.  Is this my flawed understanding of
PKCS7_sign().  Is there some other way to get back the original signed
content that I'm missing?

>From the NOTES section of PKCS7_sign():

	The data being signed is included in the PKCS7 structure, unless 
	PKCS7_DETACHED is set in which case it is omitted



> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
> Behalf Of Dr. Stephen Henson
> Sent: Tuesday, July 26, 2016 11:22 AM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] PKCS7_sign conflict with PKCS7_decrypt?
> 
> On Tue, Jul 26, 2016, Jim Carroll wrote:
> 
> > Running into trouble -- any attempt to PKCS7_decrypt() S/MIME content
> that
> > was created with PKCS7_sign()+PKCS7_encrypt() yields an empty result
> set.  I
> > have the distinct impression I'm doing something dumb -- but several
> days of
> > debugging I'm completely stuck.
> >
> > I've created an MVCE and included it below. The code was built and
> run on
> > Windows 8.1 Pro, Visual C++ 2008 Express, using OpenSSL 1.1.0-pre6-
> dev
> > (32-bit build).
> >
> > Interesting point -- If I remove the PKCS7_sign() code, I have no
> problem
> > encrypting and decrypting the content. I strongly suspect my issue
> has
> > something todo with S/MIME headers interfering with encryption or
> > decryption.  But that theory would suggest there's a bug in OpenSSL's
> S/MIME
> > handling. I find that hard to swallow -- more likely I'm missing some
> sort
> > of required flag.
> >
> 
> What you're doing is sign followed by encrypt which gives a signed
> messsage
> within an encrypted one.
> 
> Then you just decrypt which ends up giving you the signed content back.
> So if
> you want to process that you have to verify it first.
> 
> Note there is a big in the current master which breaks CMS/PKCS#7
> (overlapping
> buffers check) so you'll have to either try an earlier version or wait
> for it
> to be fixed.
> 
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


begin 666 smime.p7s
M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$'
M`0``H((.$3""!#8P@@,>H ,"`0("`0$P#08)*H9(AO<-`0$%!0`P;S$+, D&
M`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T($%",28P) 8#500+$QU!9&14
M<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B," &`U4$`Q,9061D5')U<W0@
M17AT97)N86P at 0T$@4F]O=# >%PTP,# U,S Q,#0X,SA:%PTR,# U,S Q,#0X
M,SA:,&\Q"S )!@-5! 83`E-%,10P$@8#500*$PM!9&14<G5S="!!0C$F,"0&
M`U4$"Q,=061D5')U<W0 at 17AT97)N86P at 5%10($YE='=O<FLQ(C @!@-5! ,3
M&4%D9%1R=7-T($5X=&5R;F%L($-!(%)O;W0P@@$B, T&"2J&2(;W#0$!`04`
M`X(!#P`P@@$*`H(!`0"W]QHSYO(`!"TYX$Y;[1^\; _-M?HCML[>FQ$SEZ0I
M3'V3G[U*O)/M`QKCC\_E;5!:UI<IE%J L$EZVRZ5_;C*OS<X+1X^D4&M<%;'
M\$\_Z#*>=,K(D%3IQE\/>)V:0#P.K&&J7A2/GH>A:E#<UYI.KP6SIG&4G'&S
M4& *QQ.=. >&`JCIJ&DF&)"K3+!/(ZLZ3X38W\Z?X6EON]="UVM$Y,>M[FU!
M7W):<0 at WLWEEI%F at E#?W`"\-PI)RVM X<ML4J$7$72I]M[36Q.ZLS1-$M\DK
MW4,`)?IAN6EJ6",1MZ<SCU9U6?7-*==&MPHK9;;30F\5LKA[^^_I75/5-%HG
M`@,!``&C@=PP@=DP'08#51T.!!8$%*V]F'HTM";W^L0F5.\#O> DRU0:, L&
M`U4=#P0$`P(!!C /!@-5'1,!`?\$!3 #`0'_,(&9!@-5'2,$@9$P at 8Z %*V]
MF'HTM";W^L0F5.\#O> DRU0:H7.D<3!O,0LP"08#500&$P)313$4,!(&`U4$
M"A,+061D5')U<W0 at 04(Q)C D!@-5! L3'4%D9%1R=7-T($5X=&5R;F%L(%14
M4"!.971W;W)K,2(P( 8#500#$QE!9&14<G5S="!%>'1E<FYA;"!#02!2;V]T
M@@$!, T&"2J&2(;W#0$!!04``X(!`0"PF^"%)<+6(^(/E@:2G4&8G-F$>8'9
M'EL4!R,V98^PV'>[K$%L1V"#4;#Y,CWG_/8F$\> %J6_6OR'SWAYB2&:XDP'
M"H8UO/+>4<32EK?<?D[N</T<.>L,`E$4+8Z]%N#!WT9UYR2M[/1"M(63<!!G
MNIT&-4H8TRMZS%%"H7ICT>:[H<4KPC:^$PWFO6-^>7NG"0U JVK=CXK#]O:,
M&D(%4=1%]9^G8B%H%2!#/)GG?+TDV*F1%W.(/U8;,3 at 8M'$/FLW(#IZ.+AOA
MC)B#RQ\Q\41,Q at 1S279@#\?XO1> :R[IS$P.6IIY#R *+M6>8R8>59*4V((7
M6GO0O,>/3H8$,(($KS""`Y>@`P(!`@(1`. CRQ42 at U.)K6%N>E1G:R$P#08)
M*H9(AO<-`0$+!0`P;S$+, D&`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T
M($%",28P) 8#500+$QU!9&14<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B
M," &`U4$`Q,9061D5')U<W0 at 17AT97)N86P at 0T$@4F]O=# >%PTQ-#$R,C(P
M,# P,#!:%PTR,# U,S Q,#0X,SA:,(&;,0LP"08#500&$P)'0C$;,!D&`U4$
M"!,21W)E871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#
M500*$Q%#3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR
M-38 at 0VQI96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$P
M@@$B, T&"2J&2(;W#0$!`04``X(!#P`P@@$*`H(!`0")L0W:>E,93G!2';Q6
MI at 8FM[A)X);G4:OQ\%H3216CM(P;8+QZ44*G>8RD(M\784Z1U78C"A332@)_
MMAT)@&ZE!#W9NKL6_J&'J2Y#4D,6?*\R4,BF3UKI"-C/DR6<>XCH,&3FI/A6
M@/TJ)!0S%YFL1.5IBZ-&!DO",]3I0)\&L+&LDT"YM0B3.IPJ4Z,0VST at 83Q5
M`X[93G8E`B$I^J-\<79/[N%?@>G[5(#;PWLU4K>$WB(]+# M,7]9O5(WL#-I
M+4/K^M:E\9=W9U&,V>XGZ[RE!SAVC*2I./_?C/4#K$F^RO=SF3H/,JN<E3H3
M/0Y&.E=T85"^QD _R^3BGZ(A`@,!``&C@@$7,((!$S ?!@-5'2,$&# 6@!2M
MO9AZ-+0F]_K$)E3O`[W@),M4&C =!@-5'0X$%@04DF%K at N&BH*I/[&?QPJ/W
MM( `P>PP#@8#51T/`0'_! 0#`@&&,!(&`U4=$P$!_P0(, 8!`?\"`0`P'08#
M51TE!!8P% 8(*P8!!04'`P(&""L&`04%!P,$,!$&`U4=( 0*, @P!@8$51T@
M`#!$!@-5'1\$/3 [,#F at -Z UAC-H='1P.B\O8W)L+G5S97)T<G5S="YC;VTO
M061D5')U<W1%>'1E<FYA;$-!4F]O="YC<FPP-08(*P8!!04'`0$$*3 G,"4&
M""L&`04%!S !AAEH='1P.B\O;V-S<"YU<V5R=')U<W0N8V]M, T&"2J&2(;W
M#0$!"P4``X(!`0`;*FZL5<$ZJXC%V.W-5?.J:V$KP D0(YD/Q69J;['UM+5W
M7@\"80#??07^$K.D@( `_/L=6VIR`@I!O 6ZP5C5)L+JU4V$^_Z"F,]8&^,B
M8YQ2^+L%-JM]6*7>JSMCY=K5<^_LX/M[XJ/_\$(CG,JVC4T^Y$L8`[*H+=38
MNT)+D&F%$-NF-S3H>^ !$*6<RCK'GT^(-&Z*9= :BKNIW,K*-M'T_,)D*36O
MUK&G<1'2`T.QCSZ:[)XR4_1VDLJ&- >Y+,KF'$K8F0W!AN*0DOM:0FHC(1#I
M9<?UU;M^ZHR%( )BZM$Z!RQ9Q9DS\CB)Y;;I%GH?>13V2A :)OI\BON;,((%
M(#""! B@`P(!`@(1`-4+#]T2278FC)\!=Y87SN8P#08)*H9(AO<-`0$+!0`P
M at 9LQ"S )!@-5! 83`D=",1LP&08#500($Q)'<F5A=&5R($UA;F-H97-T97(Q
M$# .!@-5! <3!U-A;&9O<F0Q&C 8!@-5! H3$4-/34]$3R!#02!,:6UI=&5D
M,4$P/P8#500#$SA#3TU/1$\@4TA!+3(U-B!#;&EE;G0 at 075T:&5N=&EC871I
M;VX at 86YD(%-E8W5R92!%;6%I;"!#03 >%PTQ-C Q,3,P,# P,#!:%PTQ-S Q
M,3(R,S4Y-3E:," Q'C <!@DJADB&]PT!"0$6#VII;4!C87)R;VQL+F-O;3""
M`2(P#08)*H9(AO<-`0$!!0`#@@$/`#""`0H"@@$!`-K\XS'GF('[$TPZLMT=
MY]ID(UGI at 9^?K.$F3&?)JS.0Q"6)OD@;8S<+1#[2QFG.S045<BKJ-D6O9FQ\
M<*2_A$&HWT6R`S' 7$<4M7HIO_"G at U#-`1,6W2HZ`,L53(EL?:P_[H%Y/6VB
MJU\01/0U<U7T/"K$+CFK\>HV/H^"EPS!W)_L#3<"[3T(BZ3LDTHN"#(\B5A1
M^VO2XN77=+Z\+IU=@1UR!40:,<7&)5,P,O1STRE:UFFYLS65=GVT*:ZY[YK9
M':(_+75)?UCOJQ: M-%=9XH<_VNPXG^;7/:6"2-DDFNH3JMIBVKH$1G/E$ 9
MD8XE<3>#8^@.89*P$#)O+'$"`P$``:."`=<P@@'3,!\&`U4=(P08,!: %))A
M:X+AHJ"J3^QG\<*C][2 `,'L,!T&`U4=#@06!!0P:UC0J,N<!7>SB(9<*/G'
MV*_ SS .!@-5'0\!`?\$! ,"!: P# 8#51T3`0'_! (P`# =!@-5'24$%C 4
M!@@K!@$%!0<#! 8(*P8!!04'`P(P1 at 8#51T@!#\P/3 [!@PK!@$$`;(Q`0(!
M`P4P*S I!@@K!@$%!0<"`18=:'1T<',Z+R]S96-U<F4N8V]M;V1O+FYE="]#
M4%,P708#51T?!%8P5#!2H%"@3H9,:'1T<#HO+V-R;"YC;VUO9&]C82YC;VTO
M0T]-3T1/4TA!,C4V0VQI96YT075T:&5N=&EC871I;VYA;F1396-U<F5%;6%I
M;$-!+F-R;#"!D 8(*P8!!04'`0$$@8,P at 8 P6 8(*P8!!04', *&3&AT=' Z
M+R]C<G0N8V]M;V1O8V$N8V]M+T-/34]$3U-(03(U-D-L:65N=$%U=&AE;G1I
M8V%T:6]N86YD4V5C=7)E16UA:6Q#02YC<G0P) 8(*P8!!04', &&&&AT=' Z
M+R]O8W-P+F-O;6]D;V-A+F-O;3 :!@-5'1$$$S 1 at 0]J:6U 8V%R<F]L;"YC
M;VTP#08)*H9(AO<-`0$+!0`#@@$!`&7_YE!"6I-N>DE*'QH34=CM%+[K`1M]
M]CL[U/FRY5[^LX>0V\F[3S&JAG>8?S4(\8%YC7"@FZN?&[XNG;*71FB1VC5\
M[C at 1T1/1VFB^.U_DY "31W;:;K"NZ]K)Q3#HO(@&45E,YCJ!NY$AC!C\IGQ:
M2/NGP"_K'85*^(.K.&Q*INS)?2E26GN'Y^%BLAID at HA<[DL&']YY*Z 9#&;V
MFJ3HYV^Y[HF)FFH-]D/]<5G):'.LJD*"]IJWI4,'-BQ;060E4[7[NKAN!^P\
MBTU&T;&8EQ; '\I'[_^.1-;+K'J.:_]/&2]A0 at L9SC^8NO*8S_4,>"4TRIOH
MI'J>$[1$P4TQ@@0C,(($'P(!`3"!L3"!FS$+, D&`U4$!A,"1T(Q&S 9!@-5
M! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'4V%L9F]R9#$:,!@&
M`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3.$-/34]$3R!32$$M
M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C=7)E($5M86EL($-!
M`A$`U0L/W1))=B:,GP%WEA?.YC )!@4K#@,"&@4`H(("1C 8!@DJADB&]PT!
M"0,Q"P8)*H9(AO<-`0<!,!P&"2J&2(;W#0$)!3$/%PTQ-C W,C8Q-3(X-#=:
M,",&"2J&2(;W#0$)!#$6!!0X;($@YY]=NC)=;;FS\YK48 "S!3!;!@DJADB&
M]PT!"0\Q3C!,, H&""J&2(;W#0,', X&""J&2(;W#0,"`@(`@# -!@@JADB&
M]PT#`@(!0# '!@4K#@,"!S -!@@JADB&]PT#`@(!*# '!@4K#@,"&C"!P at 8)
M*P8!! &"-Q $,8&T,(&Q,(&;,0LP"08#500&$P)'0C$;,!D&`U4$"!,21W)E
M871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#500*$Q%#
M3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR-38 at 0VQI
M96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$"$0#5"P_=
M$DEV)HR?`7>6%\[F,('$!@LJADB&]PT!"1 ""S&!M*"!L3"!FS$+, D&`U4$
M!A,"1T(Q&S 9!@-5! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'
M4V%L9F]R9#$:,!@&`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3
M.$-/34]$3R!32$$M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C
M=7)E($5M86EL($-!`A$`U0L/W1))=B:,GP%WEA?.YC -!@DJADB&]PT!`0$%
M``2"`0!G.[^^K L6[8IJMMHY)H3/!1U!LVGLE?!W#INX,/%*._UQP_^<AL73
M`FJD+ERE\AA#MDE$&8RU8!1J2?AQ./KEH8)#F'&1VRD<VA>K'M7Q1E-(D';!
M]_:E"S+\033S*R$KY G:=;GF_*_X(5%3=(HYZQVX3/WJBG):[V;1"QI?%<3"
M5,3+I8N9=BJM^VX@]N'2U_"?L!Q+CTP%O9F:@]&Z\.K_'DWW7P],BRUWB;1%
M?_HD2H7S&B$F,G3K>8*,>"7[(0'08\1HS;RQ2!2XAN7M<Q;6%:9YV':C%0:2
J:L$QM"8M,;M"VI6JVRV/4.[->4S5-5KCW58KQR):9%L4F.L^````````
`
end


From steve at openssl.org  Tue Jul 26 16:06:53 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 26 Jul 2016 16:06:53 +0000
Subject: [openssl-users] PKCS7_sign conflict with PKCS7_decrypt?
In-Reply-To: <00a201d1e752$67c23390$37469ab0$@carroll.com>
References: <008401d1e749$8d021d90$a70658b0$@carroll.com>
 <20160726152144.GA6638@openssl.org>
 <00a201d1e752$67c23390$37469ab0$@carroll.com>
Message-ID: <20160726160653.GA7351@openssl.org>

On Tue, Jul 26, 2016, Jim Carroll wrote:

> Steve -- thanks, but I don't think I was clear enough. 
> 
> I am trying to get back the signed content, but when I call PKCS7_decrpyt()
> I get back an empty buffer.  Is this my flawed understanding of
> PKCS7_sign().  Is there some other way to get back the original signed
> content that I'm missing?
> 

That is the overlapping buffers bug (ticket 4628). I suggest you try pre5
instead of the current master or wait for this bug to be fixed 

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From jim at carroll.com  Tue Jul 26 18:01:07 2016
From: jim at carroll.com (Jim Carroll)
Date: Tue, 26 Jul 2016 14:01:07 -0400
Subject: [openssl-users] PKCS7_sign conflict with PKCS7_decrypt?
In-Reply-To: <20160726160653.GA7351@openssl.org>
References: <008401d1e749$8d021d90$a70658b0$@carroll.com>
 <20160726152144.GA6638@openssl.org>
 <00a201d1e752$67c23390$37469ab0$@carroll.com>
 <20160726160653.GA7351@openssl.org>
Message-ID: <00d701d1e767$af695a60$0e3c0f20$@carroll.com>

After experimenting, I can confirm this is the same issue we're seeing,
although experiencing it very differently from the MIT/Kerberos team.  I can
confirm that right now PKCS7 sign/encrypt/decrypt is broken. I'd love to
help fix it, but I'm not yet up to speed on bio_enc.c and evp_enc.c. For
now, I think wait for a fix is the best approach. 

What is the accepted way for "the great unwashed" to follow tickets?  I got
into the ticket system as a guest, but as guest I can't asked to be notified
about status updates.  Is there a process to request a full account on
rt.openssl.org?

Once the fix is ready, I'll submit a unittest to help with regression
testing PKCS7 sign-encrypt-decrypt-verify. 

Thanks for you help.


> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
> Behalf Of Dr. Stephen Henson
> Sent: Tuesday, July 26, 2016 12:07 PM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] PKCS7_sign conflict with PKCS7_decrypt?
> 
> On Tue, Jul 26, 2016, Jim Carroll wrote:
> 
> > Steve -- thanks, but I don't think I was clear enough.
> >
> > I am trying to get back the signed content, but when I call
> PKCS7_decrpyt()
> > I get back an empty buffer.  Is this my flawed understanding of
> > PKCS7_sign().  Is there some other way to get back the original
> signed
> > content that I'm missing?
> >
> 
> That is the overlapping buffers bug (ticket 4628). I suggest you try
> pre5
> instead of the current master or wait for this bug to be fixed
> 
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


begin 666 smime.p7s
M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$'
M`0``H((.$3""!#8P@@,>H ,"`0("`0$P#08)*H9(AO<-`0$%!0`P;S$+, D&
M`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T($%",28P) 8#500+$QU!9&14
M<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B," &`U4$`Q,9061D5')U<W0@
M17AT97)N86P at 0T$@4F]O=# >%PTP,# U,S Q,#0X,SA:%PTR,# U,S Q,#0X
M,SA:,&\Q"S )!@-5! 83`E-%,10P$@8#500*$PM!9&14<G5S="!!0C$F,"0&
M`U4$"Q,=061D5')U<W0 at 17AT97)N86P at 5%10($YE='=O<FLQ(C @!@-5! ,3
M&4%D9%1R=7-T($5X=&5R;F%L($-!(%)O;W0P@@$B, T&"2J&2(;W#0$!`04`
M`X(!#P`P@@$*`H(!`0"W]QHSYO(`!"TYX$Y;[1^\; _-M?HCML[>FQ$SEZ0I
M3'V3G[U*O)/M`QKCC\_E;5!:UI<IE%J L$EZVRZ5_;C*OS<X+1X^D4&M<%;'
M\$\_Z#*>=,K(D%3IQE\/>)V:0#P.K&&J7A2/GH>A:E#<UYI.KP6SIG&4G'&S
M4& *QQ.=. >&`JCIJ&DF&)"K3+!/(ZLZ3X38W\Z?X6EON]="UVM$Y,>M[FU!
M7W):<0 at WLWEEI%F at E#?W`"\-PI)RVM X<ML4J$7$72I]M[36Q.ZLS1-$M\DK
MW4,`)?IAN6EJ6",1MZ<SCU9U6?7-*==&MPHK9;;30F\5LKA[^^_I75/5-%HG
M`@,!``&C@=PP@=DP'08#51T.!!8$%*V]F'HTM";W^L0F5.\#O> DRU0:, L&
M`U4=#P0$`P(!!C /!@-5'1,!`?\$!3 #`0'_,(&9!@-5'2,$@9$P at 8Z %*V]
MF'HTM";W^L0F5.\#O> DRU0:H7.D<3!O,0LP"08#500&$P)313$4,!(&`U4$
M"A,+061D5')U<W0 at 04(Q)C D!@-5! L3'4%D9%1R=7-T($5X=&5R;F%L(%14
M4"!.971W;W)K,2(P( 8#500#$QE!9&14<G5S="!%>'1E<FYA;"!#02!2;V]T
M@@$!, T&"2J&2(;W#0$!!04``X(!`0"PF^"%)<+6(^(/E@:2G4&8G-F$>8'9
M'EL4!R,V98^PV'>[K$%L1V"#4;#Y,CWG_/8F$\> %J6_6OR'SWAYB2&:XDP'
M"H8UO/+>4<32EK?<?D[N</T<.>L,`E$4+8Z]%N#!WT9UYR2M[/1"M(63<!!G
MNIT&-4H8TRMZS%%"H7ICT>:[H<4KPC:^$PWFO6-^>7NG"0U JVK=CXK#]O:,
M&D(%4=1%]9^G8B%H%2!#/)GG?+TDV*F1%W.(/U8;,3 at 8M'$/FLW(#IZ.+AOA
MC)B#RQ\Q\41,Q at 1S279@#\?XO1> :R[IS$P.6IIY#R *+M6>8R8>59*4V((7
M6GO0O,>/3H8$,(($KS""`Y>@`P(!`@(1`. CRQ42 at U.)K6%N>E1G:R$P#08)
M*H9(AO<-`0$+!0`P;S$+, D&`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T
M($%",28P) 8#500+$QU!9&14<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B
M," &`U4$`Q,9061D5')U<W0 at 17AT97)N86P at 0T$@4F]O=# >%PTQ-#$R,C(P
M,# P,#!:%PTR,# U,S Q,#0X,SA:,(&;,0LP"08#500&$P)'0C$;,!D&`U4$
M"!,21W)E871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#
M500*$Q%#3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR
M-38 at 0VQI96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$P
M@@$B, T&"2J&2(;W#0$!`04``X(!#P`P@@$*`H(!`0")L0W:>E,93G!2';Q6
MI at 8FM[A)X);G4:OQ\%H3216CM(P;8+QZ44*G>8RD(M\784Z1U78C"A332@)_
MMAT)@&ZE!#W9NKL6_J&'J2Y#4D,6?*\R4,BF3UKI"-C/DR6<>XCH,&3FI/A6
M@/TJ)!0S%YFL1.5IBZ-&!DO",]3I0)\&L+&LDT"YM0B3.IPJ4Z,0VST at 83Q5
M`X[93G8E`B$I^J-\<79/[N%?@>G[5(#;PWLU4K>$WB(]+# M,7]9O5(WL#-I
M+4/K^M:E\9=W9U&,V>XGZ[RE!SAVC*2I./_?C/4#K$F^RO=SF3H/,JN<E3H3
M/0Y&.E=T85"^QD _R^3BGZ(A`@,!``&C@@$7,((!$S ?!@-5'2,$&# 6@!2M
MO9AZ-+0F]_K$)E3O`[W@),M4&C =!@-5'0X$%@04DF%K at N&BH*I/[&?QPJ/W
MM( `P>PP#@8#51T/`0'_! 0#`@&&,!(&`U4=$P$!_P0(, 8!`?\"`0`P'08#
M51TE!!8P% 8(*P8!!04'`P(&""L&`04%!P,$,!$&`U4=( 0*, @P!@8$51T@
M`#!$!@-5'1\$/3 [,#F at -Z UAC-H='1P.B\O8W)L+G5S97)T<G5S="YC;VTO
M061D5')U<W1%>'1E<FYA;$-!4F]O="YC<FPP-08(*P8!!04'`0$$*3 G,"4&
M""L&`04%!S !AAEH='1P.B\O;V-S<"YU<V5R=')U<W0N8V]M, T&"2J&2(;W
M#0$!"P4``X(!`0`;*FZL5<$ZJXC%V.W-5?.J:V$KP D0(YD/Q69J;['UM+5W
M7@\"80#??07^$K.D@( `_/L=6VIR`@I!O 6ZP5C5)L+JU4V$^_Z"F,]8&^,B
M8YQ2^+L%-JM]6*7>JSMCY=K5<^_LX/M[XJ/_\$(CG,JVC4T^Y$L8`[*H+=38
MNT)+D&F%$-NF-S3H>^ !$*6<RCK'GT^(-&Z*9= :BKNIW,K*-M'T_,)D*36O
MUK&G<1'2`T.QCSZ:[)XR4_1VDLJ&- >Y+,KF'$K8F0W!AN*0DOM:0FHC(1#I
M9<?UU;M^ZHR%( )BZM$Z!RQ9Q9DS\CB)Y;;I%GH?>13V2A :)OI\BON;,((%
M(#""! B@`P(!`@(1`-4+#]T2278FC)\!=Y87SN8P#08)*H9(AO<-`0$+!0`P
M at 9LQ"S )!@-5! 83`D=",1LP&08#500($Q)'<F5A=&5R($UA;F-H97-T97(Q
M$# .!@-5! <3!U-A;&9O<F0Q&C 8!@-5! H3$4-/34]$3R!#02!,:6UI=&5D
M,4$P/P8#500#$SA#3TU/1$\@4TA!+3(U-B!#;&EE;G0 at 075T:&5N=&EC871I
M;VX at 86YD(%-E8W5R92!%;6%I;"!#03 >%PTQ-C Q,3,P,# P,#!:%PTQ-S Q
M,3(R,S4Y-3E:," Q'C <!@DJADB&]PT!"0$6#VII;4!C87)R;VQL+F-O;3""
M`2(P#08)*H9(AO<-`0$!!0`#@@$/`#""`0H"@@$!`-K\XS'GF('[$TPZLMT=
MY]ID(UGI at 9^?K.$F3&?)JS.0Q"6)OD@;8S<+1#[2QFG.S045<BKJ-D6O9FQ\
M<*2_A$&HWT6R`S' 7$<4M7HIO_"G at U#-`1,6W2HZ`,L53(EL?:P_[H%Y/6VB
MJU\01/0U<U7T/"K$+CFK\>HV/H^"EPS!W)_L#3<"[3T(BZ3LDTHN"#(\B5A1
M^VO2XN77=+Z\+IU=@1UR!40:,<7&)5,P,O1STRE:UFFYLS65=GVT*:ZY[YK9
M':(_+75)?UCOJQ: M-%=9XH<_VNPXG^;7/:6"2-DDFNH3JMIBVKH$1G/E$ 9
MD8XE<3>#8^@.89*P$#)O+'$"`P$``:."`=<P@@'3,!\&`U4=(P08,!: %))A
M:X+AHJ"J3^QG\<*C][2 `,'L,!T&`U4=#@06!!0P:UC0J,N<!7>SB(9<*/G'
MV*_ SS .!@-5'0\!`?\$! ,"!: P# 8#51T3`0'_! (P`# =!@-5'24$%C 4
M!@@K!@$%!0<#! 8(*P8!!04'`P(P1 at 8#51T@!#\P/3 [!@PK!@$$`;(Q`0(!
M`P4P*S I!@@K!@$%!0<"`18=:'1T<',Z+R]S96-U<F4N8V]M;V1O+FYE="]#
M4%,P708#51T?!%8P5#!2H%"@3H9,:'1T<#HO+V-R;"YC;VUO9&]C82YC;VTO
M0T]-3T1/4TA!,C4V0VQI96YT075T:&5N=&EC871I;VYA;F1396-U<F5%;6%I
M;$-!+F-R;#"!D 8(*P8!!04'`0$$@8,P at 8 P6 8(*P8!!04', *&3&AT=' Z
M+R]C<G0N8V]M;V1O8V$N8V]M+T-/34]$3U-(03(U-D-L:65N=$%U=&AE;G1I
M8V%T:6]N86YD4V5C=7)E16UA:6Q#02YC<G0P) 8(*P8!!04', &&&&AT=' Z
M+R]O8W-P+F-O;6]D;V-A+F-O;3 :!@-5'1$$$S 1 at 0]J:6U 8V%R<F]L;"YC
M;VTP#08)*H9(AO<-`0$+!0`#@@$!`&7_YE!"6I-N>DE*'QH34=CM%+[K`1M]
M]CL[U/FRY5[^LX>0V\F[3S&JAG>8?S4(\8%YC7"@FZN?&[XNG;*71FB1VC5\
M[C at 1T1/1VFB^.U_DY "31W;:;K"NZ]K)Q3#HO(@&45E,YCJ!NY$AC!C\IGQ:
M2/NGP"_K'85*^(.K.&Q*INS)?2E26GN'Y^%BLAID at HA<[DL&']YY*Z 9#&;V
MFJ3HYV^Y[HF)FFH-]D/]<5G):'.LJD*"]IJWI4,'-BQ;060E4[7[NKAN!^P\
MBTU&T;&8EQ; '\I'[_^.1-;+K'J.:_]/&2]A0 at L9SC^8NO*8S_4,>"4TRIOH
MI'J>$[1$P4TQ@@0C,(($'P(!`3"!L3"!FS$+, D&`U4$!A,"1T(Q&S 9!@-5
M! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'4V%L9F]R9#$:,!@&
M`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3.$-/34]$3R!32$$M
M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C=7)E($5M86EL($-!
M`A$`U0L/W1))=B:,GP%WEA?.YC )!@4K#@,"&@4`H(("1C 8!@DJADB&]PT!
M"0,Q"P8)*H9(AO<-`0<!,!P&"2J&2(;W#0$)!3$/%PTQ-C W,C8Q.# Q,#9:
M,",&"2J&2(;W#0$)!#$6!!2E:5W=DV%,T]RD6W67;LL$9P;'DS!;!@DJADB&
M]PT!"0\Q3C!,, H&""J&2(;W#0,', X&""J&2(;W#0,"`@(`@# -!@@JADB&
M]PT#`@(!0# '!@4K#@,"!S -!@@JADB&]PT#`@(!*# '!@4K#@,"&C"!P at 8)
M*P8!! &"-Q $,8&T,(&Q,(&;,0LP"08#500&$P)'0C$;,!D&`U4$"!,21W)E
M871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#500*$Q%#
M3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR-38 at 0VQI
M96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$"$0#5"P_=
M$DEV)HR?`7>6%\[F,('$!@LJADB&]PT!"1 ""S&!M*"!L3"!FS$+, D&`U4$
M!A,"1T(Q&S 9!@-5! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'
M4V%L9F]R9#$:,!@&`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3
M.$-/34]$3R!32$$M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C
M=7)E($5M86EL($-!`A$`U0L/W1))=B:,GP%WEA?.YC -!@DJADB&]PT!`0$%
M``2"`0`"DKM,M?FG),3E=O4-"338Y\_DV53/"H#$UP'6-&1*TP"0(CNG<%O4
M_%MZF3S,T5O*@B7\$9!%(G$Z68C,=@2D['Q"M]QC]OC<*8"34()5AZ.>:?\S
M<_D:/^'*P%0EW8I0\.'=[6KX[<;!OF_1$@@(\;G^DAC:\2<ZB ZXI<E-5FC\
M-*/C==Z:SEB_>/('L3;+OU>UYK(UT JBS3>/[#R,^YLT+EJB)N.RD3?N10ES
MB3CLJ=G1N0>.O0EY5Y18I(*N<]$T9%Q+P@[&$2]_GBT(Q&\(6AC=@NBP!/ &
J,(;1;9&I#DJ_-7M at 9MI2#(YHT<@'E8HJ4H?IT+WT^<!#@XNR````````
`
end


From rsalz at akamai.com  Tue Jul 26 18:26:59 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 26 Jul 2016 18:26:59 +0000
Subject: [openssl-users] PKCS7_sign conflict with PKCS7_decrypt?
In-Reply-To: <00d701d1e767$af695a60$0e3c0f20$@carroll.com>
References: <008401d1e749$8d021d90$a70658b0$@carroll.com>
 <20160726152144.GA6638@openssl.org>
 <00a201d1e752$67c23390$37469ab0$@carroll.com>
 <20160726160653.GA7351@openssl.org>
 <00d701d1e767$af695a60$0e3c0f20$@carroll.com>
Message-ID: <bfa81723b8d142dab95b9b3e234179f9@usma1ex-dag1mb1.msg.corp.akamai.com>


> What is the accepted way for "the great unwashed" to follow tickets? 

All updates are forwarded to openssl-dev.



From jim at carroll.com  Tue Jul 26 18:29:24 2016
From: jim at carroll.com (Jim Carroll)
Date: Tue, 26 Jul 2016 14:29:24 -0400
Subject: [openssl-users] PKCS7_sign conflict with PKCS7_decrypt?
In-Reply-To: <bfa81723b8d142dab95b9b3e234179f9@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <008401d1e749$8d021d90$a70658b0$@carroll.com>
 <20160726152144.GA6638@openssl.org>
 <00a201d1e752$67c23390$37469ab0$@carroll.com>
 <20160726160653.GA7351@openssl.org>
 <00d701d1e767$af695a60$0e3c0f20$@carroll.com>
 <bfa81723b8d142dab95b9b3e234179f9@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <010501d1e76b$a2ca2a10$e85e7e30$@carroll.com>

Perfect. thanks

> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
> Behalf Of Salz, Rich
> Sent: Tuesday, July 26, 2016 2:27 PM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] PKCS7_sign conflict with PKCS7_decrypt?
> 
> 
> > What is the accepted way for "the great unwashed" to follow tickets?
> 
> All updates are forwarded to openssl-dev.
> 
> 
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


begin 666 smime.p7s
M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$'
M`0``H((.$3""!#8P@@,>H ,"`0("`0$P#08)*H9(AO<-`0$%!0`P;S$+, D&
M`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T($%",28P) 8#500+$QU!9&14
M<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B," &`U4$`Q,9061D5')U<W0@
M17AT97)N86P at 0T$@4F]O=# >%PTP,# U,S Q,#0X,SA:%PTR,# U,S Q,#0X
M,SA:,&\Q"S )!@-5! 83`E-%,10P$@8#500*$PM!9&14<G5S="!!0C$F,"0&
M`U4$"Q,=061D5')U<W0 at 17AT97)N86P at 5%10($YE='=O<FLQ(C @!@-5! ,3
M&4%D9%1R=7-T($5X=&5R;F%L($-!(%)O;W0P@@$B, T&"2J&2(;W#0$!`04`
M`X(!#P`P@@$*`H(!`0"W]QHSYO(`!"TYX$Y;[1^\; _-M?HCML[>FQ$SEZ0I
M3'V3G[U*O)/M`QKCC\_E;5!:UI<IE%J L$EZVRZ5_;C*OS<X+1X^D4&M<%;'
M\$\_Z#*>=,K(D%3IQE\/>)V:0#P.K&&J7A2/GH>A:E#<UYI.KP6SIG&4G'&S
M4& *QQ.=. >&`JCIJ&DF&)"K3+!/(ZLZ3X38W\Z?X6EON]="UVM$Y,>M[FU!
M7W):<0 at WLWEEI%F at E#?W`"\-PI)RVM X<ML4J$7$72I]M[36Q.ZLS1-$M\DK
MW4,`)?IAN6EJ6",1MZ<SCU9U6?7-*==&MPHK9;;30F\5LKA[^^_I75/5-%HG
M`@,!``&C@=PP@=DP'08#51T.!!8$%*V]F'HTM";W^L0F5.\#O> DRU0:, L&
M`U4=#P0$`P(!!C /!@-5'1,!`?\$!3 #`0'_,(&9!@-5'2,$@9$P at 8Z %*V]
MF'HTM";W^L0F5.\#O> DRU0:H7.D<3!O,0LP"08#500&$P)313$4,!(&`U4$
M"A,+061D5')U<W0 at 04(Q)C D!@-5! L3'4%D9%1R=7-T($5X=&5R;F%L(%14
M4"!.971W;W)K,2(P( 8#500#$QE!9&14<G5S="!%>'1E<FYA;"!#02!2;V]T
M@@$!, T&"2J&2(;W#0$!!04``X(!`0"PF^"%)<+6(^(/E@:2G4&8G-F$>8'9
M'EL4!R,V98^PV'>[K$%L1V"#4;#Y,CWG_/8F$\> %J6_6OR'SWAYB2&:XDP'
M"H8UO/+>4<32EK?<?D[N</T<.>L,`E$4+8Z]%N#!WT9UYR2M[/1"M(63<!!G
MNIT&-4H8TRMZS%%"H7ICT>:[H<4KPC:^$PWFO6-^>7NG"0U JVK=CXK#]O:,
M&D(%4=1%]9^G8B%H%2!#/)GG?+TDV*F1%W.(/U8;,3 at 8M'$/FLW(#IZ.+AOA
MC)B#RQ\Q\41,Q at 1S279@#\?XO1> :R[IS$P.6IIY#R *+M6>8R8>59*4V((7
M6GO0O,>/3H8$,(($KS""`Y>@`P(!`@(1`. CRQ42 at U.)K6%N>E1G:R$P#08)
M*H9(AO<-`0$+!0`P;S$+, D&`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T
M($%",28P) 8#500+$QU!9&14<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B
M," &`U4$`Q,9061D5')U<W0 at 17AT97)N86P at 0T$@4F]O=# >%PTQ-#$R,C(P
M,# P,#!:%PTR,# U,S Q,#0X,SA:,(&;,0LP"08#500&$P)'0C$;,!D&`U4$
M"!,21W)E871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#
M500*$Q%#3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR
M-38 at 0VQI96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$P
M@@$B, T&"2J&2(;W#0$!`04``X(!#P`P@@$*`H(!`0")L0W:>E,93G!2';Q6
MI at 8FM[A)X);G4:OQ\%H3216CM(P;8+QZ44*G>8RD(M\784Z1U78C"A332@)_
MMAT)@&ZE!#W9NKL6_J&'J2Y#4D,6?*\R4,BF3UKI"-C/DR6<>XCH,&3FI/A6
M@/TJ)!0S%YFL1.5IBZ-&!DO",]3I0)\&L+&LDT"YM0B3.IPJ4Z,0VST at 83Q5
M`X[93G8E`B$I^J-\<79/[N%?@>G[5(#;PWLU4K>$WB(]+# M,7]9O5(WL#-I
M+4/K^M:E\9=W9U&,V>XGZ[RE!SAVC*2I./_?C/4#K$F^RO=SF3H/,JN<E3H3
M/0Y&.E=T85"^QD _R^3BGZ(A`@,!``&C@@$7,((!$S ?!@-5'2,$&# 6@!2M
MO9AZ-+0F]_K$)E3O`[W@),M4&C =!@-5'0X$%@04DF%K at N&BH*I/[&?QPJ/W
MM( `P>PP#@8#51T/`0'_! 0#`@&&,!(&`U4=$P$!_P0(, 8!`?\"`0`P'08#
M51TE!!8P% 8(*P8!!04'`P(&""L&`04%!P,$,!$&`U4=( 0*, @P!@8$51T@
M`#!$!@-5'1\$/3 [,#F at -Z UAC-H='1P.B\O8W)L+G5S97)T<G5S="YC;VTO
M061D5')U<W1%>'1E<FYA;$-!4F]O="YC<FPP-08(*P8!!04'`0$$*3 G,"4&
M""L&`04%!S !AAEH='1P.B\O;V-S<"YU<V5R=')U<W0N8V]M, T&"2J&2(;W
M#0$!"P4``X(!`0`;*FZL5<$ZJXC%V.W-5?.J:V$KP D0(YD/Q69J;['UM+5W
M7@\"80#??07^$K.D@( `_/L=6VIR`@I!O 6ZP5C5)L+JU4V$^_Z"F,]8&^,B
M8YQ2^+L%-JM]6*7>JSMCY=K5<^_LX/M[XJ/_\$(CG,JVC4T^Y$L8`[*H+=38
MNT)+D&F%$-NF-S3H>^ !$*6<RCK'GT^(-&Z*9= :BKNIW,K*-M'T_,)D*36O
MUK&G<1'2`T.QCSZ:[)XR4_1VDLJ&- >Y+,KF'$K8F0W!AN*0DOM:0FHC(1#I
M9<?UU;M^ZHR%( )BZM$Z!RQ9Q9DS\CB)Y;;I%GH?>13V2A :)OI\BON;,((%
M(#""! B@`P(!`@(1`-4+#]T2278FC)\!=Y87SN8P#08)*H9(AO<-`0$+!0`P
M at 9LQ"S )!@-5! 83`D=",1LP&08#500($Q)'<F5A=&5R($UA;F-H97-T97(Q
M$# .!@-5! <3!U-A;&9O<F0Q&C 8!@-5! H3$4-/34]$3R!#02!,:6UI=&5D
M,4$P/P8#500#$SA#3TU/1$\@4TA!+3(U-B!#;&EE;G0 at 075T:&5N=&EC871I
M;VX at 86YD(%-E8W5R92!%;6%I;"!#03 >%PTQ-C Q,3,P,# P,#!:%PTQ-S Q
M,3(R,S4Y-3E:," Q'C <!@DJADB&]PT!"0$6#VII;4!C87)R;VQL+F-O;3""
M`2(P#08)*H9(AO<-`0$!!0`#@@$/`#""`0H"@@$!`-K\XS'GF('[$TPZLMT=
MY]ID(UGI at 9^?K.$F3&?)JS.0Q"6)OD@;8S<+1#[2QFG.S045<BKJ-D6O9FQ\
M<*2_A$&HWT6R`S' 7$<4M7HIO_"G at U#-`1,6W2HZ`,L53(EL?:P_[H%Y/6VB
MJU\01/0U<U7T/"K$+CFK\>HV/H^"EPS!W)_L#3<"[3T(BZ3LDTHN"#(\B5A1
M^VO2XN77=+Z\+IU=@1UR!40:,<7&)5,P,O1STRE:UFFYLS65=GVT*:ZY[YK9
M':(_+75)?UCOJQ: M-%=9XH<_VNPXG^;7/:6"2-DDFNH3JMIBVKH$1G/E$ 9
MD8XE<3>#8^@.89*P$#)O+'$"`P$``:."`=<P@@'3,!\&`U4=(P08,!: %))A
M:X+AHJ"J3^QG\<*C][2 `,'L,!T&`U4=#@06!!0P:UC0J,N<!7>SB(9<*/G'
MV*_ SS .!@-5'0\!`?\$! ,"!: P# 8#51T3`0'_! (P`# =!@-5'24$%C 4
M!@@K!@$%!0<#! 8(*P8!!04'`P(P1 at 8#51T@!#\P/3 [!@PK!@$$`;(Q`0(!
M`P4P*S I!@@K!@$%!0<"`18=:'1T<',Z+R]S96-U<F4N8V]M;V1O+FYE="]#
M4%,P708#51T?!%8P5#!2H%"@3H9,:'1T<#HO+V-R;"YC;VUO9&]C82YC;VTO
M0T]-3T1/4TA!,C4V0VQI96YT075T:&5N=&EC871I;VYA;F1396-U<F5%;6%I
M;$-!+F-R;#"!D 8(*P8!!04'`0$$@8,P at 8 P6 8(*P8!!04', *&3&AT=' Z
M+R]C<G0N8V]M;V1O8V$N8V]M+T-/34]$3U-(03(U-D-L:65N=$%U=&AE;G1I
M8V%T:6]N86YD4V5C=7)E16UA:6Q#02YC<G0P) 8(*P8!!04', &&&&AT=' Z
M+R]O8W-P+F-O;6]D;V-A+F-O;3 :!@-5'1$$$S 1 at 0]J:6U 8V%R<F]L;"YC
M;VTP#08)*H9(AO<-`0$+!0`#@@$!`&7_YE!"6I-N>DE*'QH34=CM%+[K`1M]
M]CL[U/FRY5[^LX>0V\F[3S&JAG>8?S4(\8%YC7"@FZN?&[XNG;*71FB1VC5\
M[C at 1T1/1VFB^.U_DY "31W;:;K"NZ]K)Q3#HO(@&45E,YCJ!NY$AC!C\IGQ:
M2/NGP"_K'85*^(.K.&Q*INS)?2E26GN'Y^%BLAID at HA<[DL&']YY*Z 9#&;V
MFJ3HYV^Y[HF)FFH-]D/]<5G):'.LJD*"]IJWI4,'-BQ;060E4[7[NKAN!^P\
MBTU&T;&8EQ; '\I'[_^.1-;+K'J.:_]/&2]A0 at L9SC^8NO*8S_4,>"4TRIOH
MI'J>$[1$P4TQ@@0C,(($'P(!`3"!L3"!FS$+, D&`U4$!A,"1T(Q&S 9!@-5
M! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'4V%L9F]R9#$:,!@&
M`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3.$-/34]$3R!32$$M
M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C=7)E($5M86EL($-!
M`A$`U0L/W1))=B:,GP%WEA?.YC )!@4K#@,"&@4`H(("1C 8!@DJADB&]PT!
M"0,Q"P8)*H9(AO<-`0<!,!P&"2J&2(;W#0$)!3$/%PTQ-C W,C8Q.#(Y,C1:
M,",&"2J&2(;W#0$)!#$6!!2*Q4A+*P6)2A^X$6?%:H['/,S\0S!;!@DJADB&
M]PT!"0\Q3C!,, H&""J&2(;W#0,', X&""J&2(;W#0,"`@(`@# -!@@JADB&
M]PT#`@(!0# '!@4K#@,"!S -!@@JADB&]PT#`@(!*# '!@4K#@,"&C"!P at 8)
M*P8!! &"-Q $,8&T,(&Q,(&;,0LP"08#500&$P)'0C$;,!D&`U4$"!,21W)E
M871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#500*$Q%#
M3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR-38 at 0VQI
M96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$"$0#5"P_=
M$DEV)HR?`7>6%\[F,('$!@LJADB&]PT!"1 ""S&!M*"!L3"!FS$+, D&`U4$
M!A,"1T(Q&S 9!@-5! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'
M4V%L9F]R9#$:,!@&`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3
M.$-/34]$3R!32$$M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C
M=7)E($5M86EL($-!`A$`U0L/W1))=B:,GP%WEA?.YC -!@DJADB&]PT!`0$%
M``2"`0"4^X?/K+HJ,+<]D !_#:56U(-!OOA-`JB&D7Y_4;5_QK'V8>+6:.N[
MQ\8D(C WP"XW)O!;*LX*-5I5X\6(&H,$M,7)55T(].ILR2W9*71<)KFN==$5
MIR>VD3H$TY;[+(D=7+N,B6-L74))<QM";DU8T/A!``_:D;?I'"'.<L<R9UG6
M)'X7(H?A$0!B<%]>^<L<7GP*KU;)5FF1+MI!9Q7<TZ\'H;V3DKQ_20T\3FI1
MD;"?`4-ZR+C"78H%B)@79.984"L%V(= 8OL>+9=97X $@BYB/^3S+-Q$P:#*
JYH\PG<9?IV&7UY9UIJD?7MN;OC,,4&89V9P#6#U%]"1Q4M4)````````
`
end


From steve at openssl.org  Tue Jul 26 19:24:43 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 26 Jul 2016 19:24:43 +0000
Subject: [openssl-users] PKCS7_sign conflict with PKCS7_decrypt?
In-Reply-To: <00d701d1e767$af695a60$0e3c0f20$@carroll.com>
References: <008401d1e749$8d021d90$a70658b0$@carroll.com>
 <20160726152144.GA6638@openssl.org>
 <00a201d1e752$67c23390$37469ab0$@carroll.com>
 <20160726160653.GA7351@openssl.org>
 <00d701d1e767$af695a60$0e3c0f20$@carroll.com>
Message-ID: <20160726192443.GA10941@openssl.org>

On Tue, Jul 26, 2016, Jim Carroll wrote:

> After experimenting, I can confirm this is the same issue we're seeing,
> although experiencing it very differently from the MIT/Kerberos team.  I can
> confirm that right now PKCS7 sign/encrypt/decrypt is broken. I'd love to
> help fix it, but I'm not yet up to speed on bio_enc.c and evp_enc.c. For
> now, I think wait for a fix is the best approach. 
> 
> What is the accepted way for "the great unwashed" to follow tickets?  I got
> into the ticket system as a guest, but as guest I can't asked to be notified
> about status updates.  Is there a process to request a full account on
> rt.openssl.org?
> 
> Once the fix is ready, I'll submit a unittest to help with regression
> testing PKCS7 sign-encrypt-decrypt-verify. 
> 

A fix is currently being reviewed. It includes a test. It just happense that
the standard CMS/PKCS#7 tests use a very short content length. If it is a
little longer they trigger the bug.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From jim at carroll.com  Tue Jul 26 19:26:29 2016
From: jim at carroll.com (Jim Carroll)
Date: Tue, 26 Jul 2016 15:26:29 -0400
Subject: [openssl-users] PKCS7_sign conflict with PKCS7_decrypt?
In-Reply-To: <20160726192443.GA10941@openssl.org>
References: <008401d1e749$8d021d90$a70658b0$@carroll.com>
 <20160726152144.GA6638@openssl.org>
 <00a201d1e752$67c23390$37469ab0$@carroll.com>
 <20160726160653.GA7351@openssl.org>
 <00d701d1e767$af695a60$0e3c0f20$@carroll.com>
 <20160726192443.GA10941@openssl.org>
Message-ID: <01a801d1e773$9c04f180$d40ed480$@carroll.com>

Thanks for the update. OpenSSL is a great project and I'm willing to pitch
in if I can be assistance.

> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
> Behalf Of Dr. Stephen Henson
> Sent: Tuesday, July 26, 2016 3:25 PM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] PKCS7_sign conflict with PKCS7_decrypt?
> 
> On Tue, Jul 26, 2016, Jim Carroll wrote:
> 
> > After experimenting, I can confirm this is the same issue we're
> seeing,
> > although experiencing it very differently from the MIT/Kerberos team.
> I can
> > confirm that right now PKCS7 sign/encrypt/decrypt is broken. I'd love
> to
> > help fix it, but I'm not yet up to speed on bio_enc.c and evp_enc.c.
> For
> > now, I think wait for a fix is the best approach.
> >
> > What is the accepted way for "the great unwashed" to follow tickets?
> I got
> > into the ticket system as a guest, but as guest I can't asked to be
> notified
> > about status updates.  Is there a process to request a full account
> on
> > rt.openssl.org?
> >
> > Once the fix is ready, I'll submit a unittest to help with regression
> > testing PKCS7 sign-encrypt-decrypt-verify.
> >
> 
> A fix is currently being reviewed. It includes a test. It just happense
> that
> the standard CMS/PKCS#7 tests use a very short content length. If it is
> a
> little longer they trigger the bug.
> 
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


begin 666 smime.p7s
M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$'
M`0``H((.$3""!#8P@@,>H ,"`0("`0$P#08)*H9(AO<-`0$%!0`P;S$+, D&
M`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T($%",28P) 8#500+$QU!9&14
M<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B," &`U4$`Q,9061D5')U<W0@
M17AT97)N86P at 0T$@4F]O=# >%PTP,# U,S Q,#0X,SA:%PTR,# U,S Q,#0X
M,SA:,&\Q"S )!@-5! 83`E-%,10P$@8#500*$PM!9&14<G5S="!!0C$F,"0&
M`U4$"Q,=061D5')U<W0 at 17AT97)N86P at 5%10($YE='=O<FLQ(C @!@-5! ,3
M&4%D9%1R=7-T($5X=&5R;F%L($-!(%)O;W0P@@$B, T&"2J&2(;W#0$!`04`
M`X(!#P`P@@$*`H(!`0"W]QHSYO(`!"TYX$Y;[1^\; _-M?HCML[>FQ$SEZ0I
M3'V3G[U*O)/M`QKCC\_E;5!:UI<IE%J L$EZVRZ5_;C*OS<X+1X^D4&M<%;'
M\$\_Z#*>=,K(D%3IQE\/>)V:0#P.K&&J7A2/GH>A:E#<UYI.KP6SIG&4G'&S
M4& *QQ.=. >&`JCIJ&DF&)"K3+!/(ZLZ3X38W\Z?X6EON]="UVM$Y,>M[FU!
M7W):<0 at WLWEEI%F at E#?W`"\-PI)RVM X<ML4J$7$72I]M[36Q.ZLS1-$M\DK
MW4,`)?IAN6EJ6",1MZ<SCU9U6?7-*==&MPHK9;;30F\5LKA[^^_I75/5-%HG
M`@,!``&C@=PP@=DP'08#51T.!!8$%*V]F'HTM";W^L0F5.\#O> DRU0:, L&
M`U4=#P0$`P(!!C /!@-5'1,!`?\$!3 #`0'_,(&9!@-5'2,$@9$P at 8Z %*V]
MF'HTM";W^L0F5.\#O> DRU0:H7.D<3!O,0LP"08#500&$P)313$4,!(&`U4$
M"A,+061D5')U<W0 at 04(Q)C D!@-5! L3'4%D9%1R=7-T($5X=&5R;F%L(%14
M4"!.971W;W)K,2(P( 8#500#$QE!9&14<G5S="!%>'1E<FYA;"!#02!2;V]T
M@@$!, T&"2J&2(;W#0$!!04``X(!`0"PF^"%)<+6(^(/E@:2G4&8G-F$>8'9
M'EL4!R,V98^PV'>[K$%L1V"#4;#Y,CWG_/8F$\> %J6_6OR'SWAYB2&:XDP'
M"H8UO/+>4<32EK?<?D[N</T<.>L,`E$4+8Z]%N#!WT9UYR2M[/1"M(63<!!G
MNIT&-4H8TRMZS%%"H7ICT>:[H<4KPC:^$PWFO6-^>7NG"0U JVK=CXK#]O:,
M&D(%4=1%]9^G8B%H%2!#/)GG?+TDV*F1%W.(/U8;,3 at 8M'$/FLW(#IZ.+AOA
MC)B#RQ\Q\41,Q at 1S279@#\?XO1> :R[IS$P.6IIY#R *+M6>8R8>59*4V((7
M6GO0O,>/3H8$,(($KS""`Y>@`P(!`@(1`. CRQ42 at U.)K6%N>E1G:R$P#08)
M*H9(AO<-`0$+!0`P;S$+, D&`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T
M($%",28P) 8#500+$QU!9&14<G5S="!%>'1E<FYA;"!45% @3F5T=V]R:S$B
M," &`U4$`Q,9061D5')U<W0 at 17AT97)N86P at 0T$@4F]O=# >%PTQ-#$R,C(P
M,# P,#!:%PTR,# U,S Q,#0X,SA:,(&;,0LP"08#500&$P)'0C$;,!D&`U4$
M"!,21W)E871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#
M500*$Q%#3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR
M-38 at 0VQI96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$P
M@@$B, T&"2J&2(;W#0$!`04``X(!#P`P@@$*`H(!`0")L0W:>E,93G!2';Q6
MI at 8FM[A)X);G4:OQ\%H3216CM(P;8+QZ44*G>8RD(M\784Z1U78C"A332@)_
MMAT)@&ZE!#W9NKL6_J&'J2Y#4D,6?*\R4,BF3UKI"-C/DR6<>XCH,&3FI/A6
M@/TJ)!0S%YFL1.5IBZ-&!DO",]3I0)\&L+&LDT"YM0B3.IPJ4Z,0VST at 83Q5
M`X[93G8E`B$I^J-\<79/[N%?@>G[5(#;PWLU4K>$WB(]+# M,7]9O5(WL#-I
M+4/K^M:E\9=W9U&,V>XGZ[RE!SAVC*2I./_?C/4#K$F^RO=SF3H/,JN<E3H3
M/0Y&.E=T85"^QD _R^3BGZ(A`@,!``&C@@$7,((!$S ?!@-5'2,$&# 6@!2M
MO9AZ-+0F]_K$)E3O`[W@),M4&C =!@-5'0X$%@04DF%K at N&BH*I/[&?QPJ/W
MM( `P>PP#@8#51T/`0'_! 0#`@&&,!(&`U4=$P$!_P0(, 8!`?\"`0`P'08#
M51TE!!8P% 8(*P8!!04'`P(&""L&`04%!P,$,!$&`U4=( 0*, @P!@8$51T@
M`#!$!@-5'1\$/3 [,#F at -Z UAC-H='1P.B\O8W)L+G5S97)T<G5S="YC;VTO
M061D5')U<W1%>'1E<FYA;$-!4F]O="YC<FPP-08(*P8!!04'`0$$*3 G,"4&
M""L&`04%!S !AAEH='1P.B\O;V-S<"YU<V5R=')U<W0N8V]M, T&"2J&2(;W
M#0$!"P4``X(!`0`;*FZL5<$ZJXC%V.W-5?.J:V$KP D0(YD/Q69J;['UM+5W
M7@\"80#??07^$K.D@( `_/L=6VIR`@I!O 6ZP5C5)L+JU4V$^_Z"F,]8&^,B
M8YQ2^+L%-JM]6*7>JSMCY=K5<^_LX/M[XJ/_\$(CG,JVC4T^Y$L8`[*H+=38
MNT)+D&F%$-NF-S3H>^ !$*6<RCK'GT^(-&Z*9= :BKNIW,K*-M'T_,)D*36O
MUK&G<1'2`T.QCSZ:[)XR4_1VDLJ&- >Y+,KF'$K8F0W!AN*0DOM:0FHC(1#I
M9<?UU;M^ZHR%( )BZM$Z!RQ9Q9DS\CB)Y;;I%GH?>13V2A :)OI\BON;,((%
M(#""! B@`P(!`@(1`-4+#]T2278FC)\!=Y87SN8P#08)*H9(AO<-`0$+!0`P
M at 9LQ"S )!@-5! 83`D=",1LP&08#500($Q)'<F5A=&5R($UA;F-H97-T97(Q
M$# .!@-5! <3!U-A;&9O<F0Q&C 8!@-5! H3$4-/34]$3R!#02!,:6UI=&5D
M,4$P/P8#500#$SA#3TU/1$\@4TA!+3(U-B!#;&EE;G0 at 075T:&5N=&EC871I
M;VX at 86YD(%-E8W5R92!%;6%I;"!#03 >%PTQ-C Q,3,P,# P,#!:%PTQ-S Q
M,3(R,S4Y-3E:," Q'C <!@DJADB&]PT!"0$6#VII;4!C87)R;VQL+F-O;3""
M`2(P#08)*H9(AO<-`0$!!0`#@@$/`#""`0H"@@$!`-K\XS'GF('[$TPZLMT=
MY]ID(UGI at 9^?K.$F3&?)JS.0Q"6)OD@;8S<+1#[2QFG.S045<BKJ-D6O9FQ\
M<*2_A$&HWT6R`S' 7$<4M7HIO_"G at U#-`1,6W2HZ`,L53(EL?:P_[H%Y/6VB
MJU\01/0U<U7T/"K$+CFK\>HV/H^"EPS!W)_L#3<"[3T(BZ3LDTHN"#(\B5A1
M^VO2XN77=+Z\+IU=@1UR!40:,<7&)5,P,O1STRE:UFFYLS65=GVT*:ZY[YK9
M':(_+75)?UCOJQ: M-%=9XH<_VNPXG^;7/:6"2-DDFNH3JMIBVKH$1G/E$ 9
MD8XE<3>#8^@.89*P$#)O+'$"`P$``:."`=<P@@'3,!\&`U4=(P08,!: %))A
M:X+AHJ"J3^QG\<*C][2 `,'L,!T&`U4=#@06!!0P:UC0J,N<!7>SB(9<*/G'
MV*_ SS .!@-5'0\!`?\$! ,"!: P# 8#51T3`0'_! (P`# =!@-5'24$%C 4
M!@@K!@$%!0<#! 8(*P8!!04'`P(P1 at 8#51T@!#\P/3 [!@PK!@$$`;(Q`0(!
M`P4P*S I!@@K!@$%!0<"`18=:'1T<',Z+R]S96-U<F4N8V]M;V1O+FYE="]#
M4%,P708#51T?!%8P5#!2H%"@3H9,:'1T<#HO+V-R;"YC;VUO9&]C82YC;VTO
M0T]-3T1/4TA!,C4V0VQI96YT075T:&5N=&EC871I;VYA;F1396-U<F5%;6%I
M;$-!+F-R;#"!D 8(*P8!!04'`0$$@8,P at 8 P6 8(*P8!!04', *&3&AT=' Z
M+R]C<G0N8V]M;V1O8V$N8V]M+T-/34]$3U-(03(U-D-L:65N=$%U=&AE;G1I
M8V%T:6]N86YD4V5C=7)E16UA:6Q#02YC<G0P) 8(*P8!!04', &&&&AT=' Z
M+R]O8W-P+F-O;6]D;V-A+F-O;3 :!@-5'1$$$S 1 at 0]J:6U 8V%R<F]L;"YC
M;VTP#08)*H9(AO<-`0$+!0`#@@$!`&7_YE!"6I-N>DE*'QH34=CM%+[K`1M]
M]CL[U/FRY5[^LX>0V\F[3S&JAG>8?S4(\8%YC7"@FZN?&[XNG;*71FB1VC5\
M[C at 1T1/1VFB^.U_DY "31W;:;K"NZ]K)Q3#HO(@&45E,YCJ!NY$AC!C\IGQ:
M2/NGP"_K'85*^(.K.&Q*INS)?2E26GN'Y^%BLAID at HA<[DL&']YY*Z 9#&;V
MFJ3HYV^Y[HF)FFH-]D/]<5G):'.LJD*"]IJWI4,'-BQ;060E4[7[NKAN!^P\
MBTU&T;&8EQ; '\I'[_^.1-;+K'J.:_]/&2]A0 at L9SC^8NO*8S_4,>"4TRIOH
MI'J>$[1$P4TQ@@0C,(($'P(!`3"!L3"!FS$+, D&`U4$!A,"1T(Q&S 9!@-5
M! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'4V%L9F]R9#$:,!@&
M`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3.$-/34]$3R!32$$M
M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C=7)E($5M86EL($-!
M`A$`U0L/W1))=B:,GP%WEA?.YC )!@4K#@,"&@4`H(("1C 8!@DJADB&]PT!
M"0,Q"P8)*H9(AO<-`0<!,!P&"2J&2(;W#0$)!3$/%PTQ-C W,C8Q.3(V,CE:
M,",&"2J&2(;W#0$)!#$6!!2+MJ M[Y81SU5ZIL&M%6I7UI^7=#!;!@DJADB&
M]PT!"0\Q3C!,, H&""J&2(;W#0,', X&""J&2(;W#0,"`@(`@# -!@@JADB&
M]PT#`@(!0# '!@4K#@,"!S -!@@JADB&]PT#`@(!*# '!@4K#@,"&C"!P at 8)
M*P8!! &"-Q $,8&T,(&Q,(&;,0LP"08#500&$P)'0C$;,!D&`U4$"!,21W)E
M871E<B!-86YC:&5S=&5R,1 P#@8#500'$P=386QF;W)D,1HP& 8#500*$Q%#
M3TU/1$\@0T$@3&EM:71E9#%!,#\&`U4$`Q,X0T]-3T1/(%-(02TR-38 at 0VQI
M96YT($%U=&AE;G1I8V%T:6]N(&%N9"!396-U<F4 at 16UA:6P at 0T$"$0#5"P_=
M$DEV)HR?`7>6%\[F,('$!@LJADB&]PT!"1 ""S&!M*"!L3"!FS$+, D&`U4$
M!A,"1T(Q&S 9!@-5! @3$D=R96%T97(@36%N8VAE<W1E<C$0, X&`U4$!Q,'
M4V%L9F]R9#$:,!@&`U4$"A,10T]-3T1/($-!($QI;6ET960Q03 _!@-5! ,3
M.$-/34]$3R!32$$M,C4V($-L:65N="!!=71H96YT:6-A=&EO;B!A;F0 at 4V5C
M=7)E($5M86EL($-!`A$`U0L/W1))=B:,GP%WEA?.YC -!@DJADB&]PT!`0$%
M``2"`0`,%S>P9M1 at R+GC0'XUEUZOKH 8)HP-+#Y702SA_9$J=2Y-/>*EN81A
MDAPGM_D#]EB<\=,[+0 at NMO(LR2E\C4#8W3P[GVOPSU@?H7Z-<LH$:\T7FUJU
MC[4L[]D)CQD3D at P<[T24:N>,9+1>3@"!1J0.S+()(J _838#(,ZI3G[A,7V@
ME6#8]'OW9;#A,H"/`,"X_N'#5%>;13!?UASR at KM(CEFW]:,R._'-QYCWH/:5
M]"8U5"$EU3F9</_VE:GY_&TX\0-MK^."\)1B6Y30O3/L0YZD_Z EXT at 9"JQU
JBA&KPYWN8_A<(@`LC<&&RM]"B&XCW8O\"?2<6P:0T6;T,[B6````````
`
end


From skumarde at akamai.com  Wed Jul 27 13:39:52 2016
From: skumarde at akamai.com (Deka, Sanjeeb)
Date: Wed, 27 Jul 2016 13:39:52 +0000
Subject: [openssl-users] Complete CA chain is not getting delivered.
Message-ID: <A25958DB-9AA5-4D56-87FC-DBFB84798AA6@akamai.com>


Hi,

We needed your input for the following.

We have three different files for the secrets to be used to support SSL.

?         File1(x.certificate) --> It contains the certificate of the Server.

----BEGIN CERTIFICATE----
Base-64 encoded data for server?s certificate
----END CERTIFICATE----

?         File2(y.private_key) --> It contains the private key of the Server.
?         File3(z.chain_cert) -->  It contains the CA certificate chain(starting with the certificate of the immediate issuer and ending with the certificate of the Root CA).

----BEGIN CERTIFICATE----
Encoded data for certificate of Issuer of server?s certificate
----END CERTIFICATE----

----BEGIN CERTIFICATE----
Encoded data for certificate of Root CA
----END CERTIFICATE----

?         Created complete certificate chain(a.chains) from x.certificate and z.chain_cert; created starting with content from x.certificate and followed by content
from z.chain_cert.

----BEGIN CERTIFICATE----
Encoded data for server?s certificate
----END CERTIFICATE----

----BEGIN CERTIFICATE----
Encoded data for certificate of Issuer of server?s certificate
----END CERTIFICATE----

----BEGIN CERTIFICATE----
Encoded data for certificate of Root CA
----END CERTIFICATE----

?         We used SSL_CTX_use_certificate_file() to load the Server?s certificate(ie. x.certificate) and SSL_CTX_use_certificate_chain_file() to load the complete
certificate chain(a.chains)

With this approach, when we connect to the server, the server was not delivering the complete certificate chain in the CERTIFICATE message of the SSL Handshake.
We could only see certificates of Server followed by certificate of the Root CA; certificate of the intermediate CA was missing.











-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160727/e468512a/attachment-0001.html>

From glosterj9 at gmail.com  Wed Jul 27 15:58:55 2016
From: glosterj9 at gmail.com (john gloster)
Date: Wed, 27 Jul 2016 21:28:55 +0530
Subject: [openssl-users] Load secrets to context.
Message-ID: <CAPJ95F_ntqJwA3hWMi5NCKMnSHv7ZnewQa6a6bLz7gQ_PiLjPQ@mail.gmail.com>

Hi,

Can we use both the following APIs in the same application to load
certificate to the SSL context?

*SSL_CTX_use_certificate_file()*
*SSL_CTX_use_certificate_chain_file()*

If we can how to use them?

Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160727/f937bbbd/attachment.html>

From openssl-users at dukhovni.org  Wed Jul 27 16:38:20 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 27 Jul 2016 16:38:20 +0000
Subject: [openssl-users] Load secrets to context.
In-Reply-To: <CAPJ95F_ntqJwA3hWMi5NCKMnSHv7ZnewQa6a6bLz7gQ_PiLjPQ@mail.gmail.com>
References: <CAPJ95F_ntqJwA3hWMi5NCKMnSHv7ZnewQa6a6bLz7gQ_PiLjPQ@mail.gmail.com>
Message-ID: <20160727163820.GQ4670@mournblade.imrryr.org>

On Wed, Jul 27, 2016 at 09:28:55PM +0530, john gloster wrote:

> Can we use both the following APIs in the same application to load
> certificate to the SSL context?
> 
> *SSL_CTX_use_certificate_file()*
> *SSL_CTX_use_certificate_chain_file()*

For any given certificate chain use either one or the other, but
in many cases SSL_CTX_use_certificate_chain_file() is the more
convenient choice.

> If we can how to use them?

    ERR_clear_error();
    if (SSL_CTX_use_certificate_chain_file(ctx, cert_file) <= 0) {
	/* Handle error */
    }
    if (SSL_CTX_use_PrivateKey_file(ctx, key_file, SSL_FILETYPE_PEM) <= 0) {
	/* Handle error */
    }
    if (!SSL_CTX_check_private_key(ctx)) {
	/* Handle error */
    }
    /* Success */

See the SSL_CTX_use_certificate(3) manpage for a more detailed
description.

-- 
	Viktor.

From jb-openssl at wisemo.com  Wed Jul 27 16:53:20 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 27 Jul 2016 18:53:20 +0200
Subject: [openssl-users] How to properly build OpenSSL with certificates
 inside certs directory
In-Reply-To: <68CA3C5A-1D54-4AD6-A740-1BB1D210E01F@mac.com>
References: <68CA3C5A-1D54-4AD6-A740-1BB1D210E01F@mac.com>
Message-ID: <f4075f29-dd56-35aa-1aa9-f07684ff0926@wisemo.com>

On 26/07/2016 16:09, Piotr Panasewicz wrote:
> Hi,
>
> There?s seems to be no good explanation on the website on how to build OpenSSL with CA certificates so I thought I?ll give a try here.
> I?ve copied all the CA certs I have to the certs folder and built, unfortunately I still get certificate validation errors with the library I uses (it links to OpenSSL dynamically).
> I have all the CA certs in pem format, should I include some kind of flag or do something else?
>
> Thanks in advance,
> Peter
>
>
You also need to create the relevant symlinks with the c_rehash
script or equivalent.  This is documented in the c_rehash manpage
included in OpenSSL (in doc/apps/c_rehash.pod before compiling).

If a single /etc/cert directory is shared by OpenSSL 0.9.x and
OpenSSL 1.0.x, you will need symlinks for both the old and new
digest formulas.  Like this:

c_rehash /etc/certs
# Only do this second step if OpenSSL 0.9.x is sharing the directory 
with 1.0.x
# (Situation with OpenSSL 1.1.x is unknown):
c_rehash -n -old /etc/certs

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


From glosterj9 at gmail.com  Wed Jul 27 16:55:42 2016
From: glosterj9 at gmail.com (john gloster)
Date: Wed, 27 Jul 2016 22:25:42 +0530
Subject: [openssl-users] Load secrets to context.
In-Reply-To: <20160727163820.GQ4670@mournblade.imrryr.org>
References: <CAPJ95F_ntqJwA3hWMi5NCKMnSHv7ZnewQa6a6bLz7gQ_PiLjPQ@mail.gmail.com>
 <20160727163820.GQ4670@mournblade.imrryr.org>
Message-ID: <CAPJ95F9LMU5pFx=tttWBiTgnNytcaBN+VS4+fVKV3WjUaOh6Qg@mail.gmail.com>

Thanks Victor.

Could you explain the reason in below cases? These are in cases when we use
both the APIs as mentioned above.

cert_file : Server's certifcate
chain_file: Complete certificate chain; starting with Server's certifcate,
followed by intermediate CA certificate and ending with Root CA certificate


Scenario 1 - Failing case

SSL_CTX_use_certificate_file() : Loaded cert_file
SSL_CTX_use_certificate_chain_file() : Loaded chain_file

Test: When tried to connect to the server, only Server's certificate and
Root CA certificate were presented in the CERTIFICATE message of the
handshake; intermediate CA certificates were missing.

Scenario 2 - Successful case

SSL_CTX_use_certificate_file() : Loaded chain_file
SSL_CTX_use_certificate_chain_file() : Loaded chain_file

Test: When tried to connect to the server, complete certificate chain was
presented in the CERTIFICATE message of the handshake.







On Wed, Jul 27, 2016 at 10:08 PM, Viktor Dukhovni <
openssl-users at dukhovni.org> wrote:

> On Wed, Jul 27, 2016 at 09:28:55PM +0530, john gloster wrote:
>
> > Can we use both the following APIs in the same application to load
> > certificate to the SSL context?
> >
> > *SSL_CTX_use_certificate_file()*
> > *SSL_CTX_use_certificate_chain_file()*
>
> For any given certificate chain use either one or the other, but
> in many cases SSL_CTX_use_certificate_chain_file() is the more
> convenient choice.
>
> > If we can how to use them?
>
>     ERR_clear_error();
>     if (SSL_CTX_use_certificate_chain_file(ctx, cert_file) <= 0) {
>         /* Handle error */
>     }
>     if (SSL_CTX_use_PrivateKey_file(ctx, key_file, SSL_FILETYPE_PEM) <= 0)
> {
>         /* Handle error */
>     }
>     if (!SSL_CTX_check_private_key(ctx)) {
>         /* Handle error */
>     }
>     /* Success */
>
> See the SSL_CTX_use_certificate(3) manpage for a more detailed
> description.
>
> --
>         Viktor.
> --
> 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/20160727/52fc728d/attachment.html>

From steve at openssl.org  Wed Jul 27 17:08:50 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 27 Jul 2016 17:08:50 +0000
Subject: [openssl-users] Load secrets to context.
In-Reply-To: <CAPJ95F9LMU5pFx=tttWBiTgnNytcaBN+VS4+fVKV3WjUaOh6Qg@mail.gmail.com>
References: <CAPJ95F_ntqJwA3hWMi5NCKMnSHv7ZnewQa6a6bLz7gQ_PiLjPQ@mail.gmail.com>
 <20160727163820.GQ4670@mournblade.imrryr.org>
 <CAPJ95F9LMU5pFx=tttWBiTgnNytcaBN+VS4+fVKV3WjUaOh6Qg@mail.gmail.com>
Message-ID: <20160727170850.GA26618@openssl.org>

On Wed, Jul 27, 2016, john gloster wrote:

> Thanks Victor.
> 
> Could you explain the reason in below cases? These are in cases when we use
> both the APIs as mentioned above.
> 
> cert_file : Server's certifcate
> chain_file: Complete certificate chain; starting with Server's certifcate,
> followed by intermediate CA certificate and ending with Root CA certificate
> 
> 
> Scenario 1 - Failing case
> 
> SSL_CTX_use_certificate_file() : Loaded cert_file
> SSL_CTX_use_certificate_chain_file() : Loaded chain_file
> 
> Test: When tried to connect to the server, only Server's certificate and
> Root CA certificate were presented in the CERTIFICATE message of the
> handshake; intermediate CA certificates were missing.
> 
> 

Do you get an error from either function? Do you get the same behaviour if you
omit SSL_CTX_use_certificate_chain_file()?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From openssl-users at dukhovni.org  Wed Jul 27 17:56:42 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 27 Jul 2016 17:56:42 +0000
Subject: [openssl-users] Load secrets to context.
In-Reply-To: <CAPJ95F9LMU5pFx=tttWBiTgnNytcaBN+VS4+fVKV3WjUaOh6Qg@mail.gmail.com>
References: <CAPJ95F_ntqJwA3hWMi5NCKMnSHv7ZnewQa6a6bLz7gQ_PiLjPQ@mail.gmail.com>
 <20160727163820.GQ4670@mournblade.imrryr.org>
 <CAPJ95F9LMU5pFx=tttWBiTgnNytcaBN+VS4+fVKV3WjUaOh6Qg@mail.gmail.com>
Message-ID: <20160727175642.GR4670@mournblade.imrryr.org>

On Wed, Jul 27, 2016 at 10:25:42PM +0530, john gloster wrote:

> Scenario 1 - Failing case
> 
> SSL_CTX_use_certificate_file() : Loaded cert_file
> SSL_CTX_use_certificate_chain_file() : Loaded chain_file

Doing this makes no sense.  If you're loading the complete chain
file, there's no reason to first load just the certificate.

Just use SSL_CTX_use_certificate_chain_file(3), debugging incorrect
usage is not a good use of time.

-- 
	Viktor.

From noloader at gmail.com  Wed Jul 27 19:28:36 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 27 Jul 2016 15:28:36 -0400
Subject: [openssl-users] Load secrets to context.
In-Reply-To: <20160727175642.GR4670@mournblade.imrryr.org>
References: <CAPJ95F_ntqJwA3hWMi5NCKMnSHv7ZnewQa6a6bLz7gQ_PiLjPQ@mail.gmail.com>
 <20160727163820.GQ4670@mournblade.imrryr.org>
 <CAPJ95F9LMU5pFx=tttWBiTgnNytcaBN+VS4+fVKV3WjUaOh6Qg@mail.gmail.com>
 <20160727175642.GR4670@mournblade.imrryr.org>
Message-ID: <CAH8yC8m1sfbNjE=82Sh8kcxUmLDLDyYV=qJzdqkb8gQUe54CJw@mail.gmail.com>

>> Scenario 1 - Failing case
>>
>> SSL_CTX_use_certificate_file() : Loaded cert_file
>> SSL_CTX_use_certificate_chain_file() : Loaded chain_file
>
> Doing this makes no sense.  If you're loading the complete chain
> file, there's no reason to first load just the certificate.
>
> Just use SSL_CTX_use_certificate_chain_file(3), debugging incorrect
> usage is not a good use of time.

The best I can tell, its not an correct configuration. The NOTES
section says SSL_CTX_use_certificate_chain_file should be preferred,
but its not forbidden. Confer,
https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_use_certificate.html
.

Perhaps its best to address the problem rather than attacking the
user. Its OK to disregard the feedback you are getting, but please
don't attack the users.

Jeff

From pratyush.parimal at gmail.com  Thu Jul 28 00:18:21 2016
From: pratyush.parimal at gmail.com (pratyush parimal)
Date: Wed, 27 Jul 2016 20:18:21 -0400
Subject: [openssl-users] Custom Random number generation while in Fips mode
In-Reply-To: <CALvRNOEmqejqA3_WaOMp8vN3s7Kq6_GRTDT6ZOMyGDDiQNi6yg@mail.gmail.com>
References: <CALvRNOHYaGLW7BqM3qer2dFGJCx9k+eL1wCgAFxDBd9YW0hjqQ@mail.gmail.com>
 <CALvRNOEmqejqA3_WaOMp8vN3s7Kq6_GRTDT6ZOMyGDDiQNi6yg@mail.gmail.com>
Message-ID: <CALvRNOH7m-F5w6MrMhsohh7svVNSDYs9kfwrq_AbCGjGZtak=A@mail.gmail.com>

Hi all,

I work on a consumer application which is striving to be fips-140-2
compliant.

I'm using OpenSSL as recommended in the fips guide by invoking
fips_mode_set(). However, in certain parts of the same application, I'm
using my own non-OpenSSL random number generator to generate salts for
hashing passwords for the app user accounts(I'm not using RAND_bytes).

Does anyone know if using my custom random number generator in this way
violates the app's fips compliance? Am I really supposed to be using
RAND_bytes for compliance reasons?

Thanks in advance!
Pratyush.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160727/431a350e/attachment.html>

From lists-sa at protonmail.com  Thu Jul 28 06:33:51 2016
From: lists-sa at protonmail.com (Socrates)
Date: Thu, 28 Jul 2016 02:33:51 -0400
Subject: [openssl-users] How can I generate an RSA Public Key with OAEP
	padding?
Message-ID: <TyPg-4im3MF8EUns279RtF8kIWp-ztgcL8AUts84vY8Vr3R50W4lxQSj8dwZ_sQ3nJ6x8R5DfbCud0w2ghQOWoxa-kUVra6vSj8Qn7TdGpE=@protonmail.com>

Hi,

Even though I have used openssl or ssh-keygen for years to generate key pairs mainly for SSH purposes, I don't know much about the underlying theory and finer details of cryptography.

I want to use JSON Web Encryption (JWE) and there we have this concept of Key Encryption. Key Encryption can be done using RSAES-PKCS1-v1_5 or RSA-OAEP or RSA-OAEP-256 (c.f. https://tools.ietf.org/html/rfc7518#section-4.2 and https://tools.ietf.org/html/rfc7518#section-4.3).

The question is how can I use openssl command line tool to create a public key using RSAES-PKCS1-v1_5, RSA-OAEP, or RSA-OAEP-256 (paddings?)?

At the moment, I use the following command to create a PEM file:

openssl genrsa -out example.pem 2048

Then I use the following command to extract the public key:

openssl rsa -in example.pem -pubout example.pub

What padding is used for this public key? How can I specify that I want it to be generated with RSAES-PKCS1-v1_5, RSA-OAEP, or RSA-OAEP-256 paddings?

Thanks in advance,
Socrates
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160728/2ee78a33/attachment.html>

From Suman.Patro-TRN at lntebg.com  Thu Jul 28 11:19:55 2016
From: Suman.Patro-TRN at lntebg.com (R-D intern)
Date: Thu, 28 Jul 2016 04:19:55 -0700 (MST)
Subject: [openssl-users] different encrypted text for the same plain text
	message
Message-ID: <1469704795494-67595.post@n7.nabble.com>

Hello,
I am using ECDSA-ECDHE-AES-SHA cipher suite for client -server security.I
tried understanding the mechanism handshake mechanism. What still quizzes me
is ; communication between a specific client -server for a specific session
generates different encrypted text for the same plain text message. What
leads  to this? Can anybody elaborate?
Please reply.
Thanks and regards,
Suman



--
View this message in context: http://openssl.6102.n7.nabble.com/different-encrypted-text-for-the-same-plain-text-message-tp67595.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From Suman.Patro-TRN at lntebg.com  Thu Jul 28 12:07:54 2016
From: Suman.Patro-TRN at lntebg.com (R-D intern)
Date: Thu, 28 Jul 2016 05:07:54 -0700 (MST)
Subject: [openssl-users] server key exchange use case in ECDSA-ECDHE-AES-SHA
Message-ID: <1469707674316-67596.post@n7.nabble.com>

Hello,
I have used ECDSA-ECDHE-AES-SHA as the cipher suite in my client- server
communication. To use ECDHE key exchange algorithm I used ECDHE parameters
and what I see is an additional server key exchange in my SSL handshake
process. What  does that imply? Does that increase the security strength of
the system?Is it redundant?
Please elaborate  its significance.
Thanks and regards,
Suman




--
View this message in context: http://openssl.6102.n7.nabble.com/server-key-exchange-use-case-in-ECDSA-ECDHE-AES-SHA-tp67596.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From rsalz at akamai.com  Thu Jul 28 13:41:43 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 28 Jul 2016 13:41:43 +0000
Subject: [openssl-users] server key exchange use case in
 ECDSA-ECDHE-AES-SHA
In-Reply-To: <1469707674316-67596.post@n7.nabble.com>
References: <1469707674316-67596.post@n7.nabble.com>
Message-ID: <0de1a335ab3b46cda7e527a0b3812f58@usma1ex-dag1mb1.msg.corp.akamai.com>

You have asked two very basic questions about cryptography.  I suggest you start doing a literature search; for example, Wikipedia.


--  
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz

From thomas.francis.jr at pobox.com  Thu Jul 28 14:23:04 2016
From: thomas.francis.jr at pobox.com (Thomas Francis, Jr.)
Date: Thu, 28 Jul 2016 10:23:04 -0400
Subject: [openssl-users] Custom Random number generation while in Fips
	mode
In-Reply-To: <CALvRNOH7m-F5w6MrMhsohh7svVNSDYs9kfwrq_AbCGjGZtak=A@mail.gmail.com>
References: <CALvRNOHYaGLW7BqM3qer2dFGJCx9k+eL1wCgAFxDBd9YW0hjqQ@mail.gmail.com>
 <CALvRNOEmqejqA3_WaOMp8vN3s7Kq6_GRTDT6ZOMyGDDiQNi6yg@mail.gmail.com>
 <CALvRNOH7m-F5w6MrMhsohh7svVNSDYs9kfwrq_AbCGjGZtak=A@mail.gmail.com>
Message-ID: <47898D85-8028-44A1-96A2-9C913D4A9527@pobox.com>


> On Jul 27, 2016, at 8:18 PM, pratyush parimal <pratyush.parimal at gmail.com> wrote:
> 
> Hi all,
> 
> I work on a consumer application which is striving to be fips-140-2 compliant.
> 
> I'm using OpenSSL as recommended in the fips guide by invoking fips_mode_set(). However, in certain parts of the same application, I'm using my own non-OpenSSL random number generator to generate salts for hashing passwords for the app user accounts(I'm not using RAND_bytes).
> 
> Does anyone know if using my custom random number generator in this way violates the app's fips compliance?

That?s almost certainly a violation.  There might be a few edge cases where it is not, but they?re very unlikely.  To determine if you?re even close to such cases, ask: Does the RNG I?m using come from another FIPS 140 validated cryptographic module?  Am I using that module in approved mode?  Am I using that module according to its security policy?  Do I have explicit permission from the customers? auditors to mix two modules in my product?

If the answer to all of those questions is yes, you _might_ be OK, for now.  A few auditors (in the past, anyway) considered it OK to mix modules, while other auditors say no.  My own reading of FIPS 140-2 is that you may not mix modules.  But I?m not an auditor or a lawyer. :)

The other question to ask is: can I clearly explain that the use of the non-approved RNG is for non-cryptographic purposes, and easily justify that explanation?  Given what you said about why you?re using it, I?m pretty sure the answer to that one is ?no?. :)  And even if you could, that?s still a very weak argument to be making to your customers? auditors, who may decide it?s still not allowed even if they agree it?s for non-cryptographic purposes.

> Am I really supposed to be using 
> RAND_bytes for compliance reasons?

Yes.

> Thanks in advance!
> Pratyush.
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From openssl-users at dukhovni.org  Thu Jul 28 14:32:11 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 28 Jul 2016 10:32:11 -0400
Subject: [openssl-users] How can I generate an RSA Public Key with OAEP
	padding?
In-Reply-To: <TyPg-4im3MF8EUns279RtF8kIWp-ztgcL8AUts84vY8Vr3R50W4lxQSj8dwZ_sQ3nJ6x8R5DfbCud0w2ghQOWoxa-kUVra6vSj8Qn7TdGpE=@protonmail.com>
References: <TyPg-4im3MF8EUns279RtF8kIWp-ztgcL8AUts84vY8Vr3R50W4lxQSj8dwZ_sQ3nJ6x8R5DfbCud0w2ghQOWoxa-kUVra6vSj8Qn7TdGpE=@protonmail.com>
Message-ID: <A29C14A4-399E-4F85-AAE9-FCF6926E795A@dukhovni.org>


> On Jul 28, 2016, at 2:33 AM, Socrates <lists-sa at protonmail.com> wrote:
> 
> The question is how can I use openssl command line tool to create a public key using RSAES-PKCS1-v1_5, RSA-OAEP, or RSA-OAEP-256 (paddings?)?

RSA public keys don't have padding, signature and encryption formats have padding.

-- 
	Viktor.


From pratyush.parimal at gmail.com  Thu Jul 28 15:00:33 2016
From: pratyush.parimal at gmail.com (pratyush parimal)
Date: Thu, 28 Jul 2016 11:00:33 -0400
Subject: [openssl-users] Custom Random number generation while in Fips
	mode
In-Reply-To: <47898D85-8028-44A1-96A2-9C913D4A9527@pobox.com>
References: <CALvRNOHYaGLW7BqM3qer2dFGJCx9k+eL1wCgAFxDBd9YW0hjqQ@mail.gmail.com>
 <CALvRNOEmqejqA3_WaOMp8vN3s7Kq6_GRTDT6ZOMyGDDiQNi6yg@mail.gmail.com>
 <CALvRNOH7m-F5w6MrMhsohh7svVNSDYs9kfwrq_AbCGjGZtak=A@mail.gmail.com>
 <47898D85-8028-44A1-96A2-9C913D4A9527@pobox.com>
Message-ID: <CALvRNOHvccrkphP4iKixafg9Z6zaND_riFRkC8aP-48qT28B7A@mail.gmail.com>

Hi Thomas,

Thanks for your response! It clears up matters a lot :)

There's one thing that I thought of though -- even though I'm generating
the salt via non-OpenSSL means, the actual function that I'm using for
hashing is "SHA512" from FIPS OpenSSL.
Does the mere usage of salt that was generated via a non-FIPS-recommended
approach violate my compliance ?

I understand what you mean by "I'm not an auditor or a lawyer" , but I'd
still appreciate your opinion / experience in the matter :)

Thanks,
Pratyush.

On Thu, Jul 28, 2016 at 10:23 AM, Thomas Francis, Jr. <
thomas.francis.jr at pobox.com> wrote:

>
> > On Jul 27, 2016, at 8:18 PM, pratyush parimal <
> pratyush.parimal at gmail.com> wrote:
> >
> > Hi all,
> >
> > I work on a consumer application which is striving to be fips-140-2
> compliant.
> >
> > I'm using OpenSSL as recommended in the fips guide by invoking
> fips_mode_set(). However, in certain parts of the same application, I'm
> using my own non-OpenSSL random number generator to generate salts for
> hashing passwords for the app user accounts(I'm not using RAND_bytes).
> >
> > Does anyone know if using my custom random number generator in this way
> violates the app's fips compliance?
>
> That?s almost certainly a violation.  There might be a few edge cases
> where it is not, but they?re very unlikely.  To determine if you?re even
> close to such cases, ask: Does the RNG I?m using come from another FIPS 140
> validated cryptographic module?  Am I using that module in approved mode?
> Am I using that module according to its security policy?  Do I have
> explicit permission from the customers? auditors to mix two modules in my
> product?
>
> If the answer to all of those questions is yes, you _might_ be OK, for
> now.  A few auditors (in the past, anyway) considered it OK to mix modules,
> while other auditors say no.  My own reading of FIPS 140-2 is that you may
> not mix modules.  But I?m not an auditor or a lawyer. :)
>
> The other question to ask is: can I clearly explain that the use of the
> non-approved RNG is for non-cryptographic purposes, and easily justify that
> explanation?  Given what you said about why you?re using it, I?m pretty
> sure the answer to that one is ?no?. :)  And even if you could, that?s
> still a very weak argument to be making to your customers? auditors, who
> may decide it?s still not allowed even if they agree it?s for
> non-cryptographic purposes.
>
> > Am I really supposed to be using
> > RAND_bytes for compliance reasons?
>
> Yes.
>
> > Thanks in advance!
> > Pratyush.
> >
> > --
> > 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/20160728/71335cf8/attachment-0001.html>

From bkaduk at akamai.com  Thu Jul 28 15:15:15 2016
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Thu, 28 Jul 2016 10:15:15 -0500
Subject: [openssl-users] different encrypted text for the same plain
 text message
In-Reply-To: <1469704795494-67595.post@n7.nabble.com>
References: <1469704795494-67595.post@n7.nabble.com>
Message-ID: <b2a3f91d-9eed-6446-c870-d764558d514e@akamai.com>

There are several places where a per-connection random input is
introduced, with a specific goal of making encryptions of the same
plaintext produce different ciphertexts (as well as other benefits).  If
a plaintext always produced the same ciphertext, then an attacker could
make a dictionary of different observed ciphertexts and know when the
same plaintext was being repeated, which violates the confidentiality
property desired from the protocol.

-Ben

On 07/28/2016 06:19 AM, R-D intern wrote:
> Hello,
> I am using ECDSA-ECDHE-AES-SHA cipher suite for client -server security.I
> tried understanding the mechanism handshake mechanism. What still quizzes me
> is ; communication between a specific client -server for a specific session
> generates different encrypted text for the same plain text message. What
> leads  to this? Can anybody elaborate?
> Please reply.
> Thanks and regards,
> Suman
>
>
>
> --
> View this message in context: http://openssl.6102.n7.nabble.com/different-encrypted-text-for-the-same-plain-text-message-tp67595.html
> Sent from the OpenSSL - User mailing list archive at Nabble.com.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160728/68d2f497/attachment.html>

From tshort at akamai.com  Thu Jul 28 15:23:41 2016
From: tshort at akamai.com (Short, Todd)
Date: Thu, 28 Jul 2016 15:23:41 +0000
Subject: [openssl-users] different encrypted text for the same plain
 text message
In-Reply-To: <b2a3f91d-9eed-6446-c870-d764558d514e@akamai.com>
References: <1469704795494-67595.post@n7.nabble.com>
 <b2a3f91d-9eed-6446-c870-d764558d514e@akamai.com>
Message-ID: <30FB638A-2A47-49DF-B8A1-CC568BB4B123@akamai.com>

Rich Salz basically told this guy to read Wikipedia about cryptography? :)
--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On Jul 28, 2016, at 11:15 AM, Benjamin Kaduk <bkaduk at akamai.com<mailto:bkaduk at akamai.com>> wrote:

There are several places where a per-connection random input is introduced, with a specific goal of making encryptions of the same plaintext produce different ciphertexts (as well as other benefits).  If a plaintext always produced the same ciphertext, then an attacker could make a dictionary of different observed ciphertexts and know when the same plaintext was being repeated, which violates the confidentiality property desired from the protocol.

-Ben

On 07/28/2016 06:19 AM, R-D intern wrote:

Hello,
I am using ECDSA-ECDHE-AES-SHA cipher suite for client -server security.I
tried understanding the mechanism handshake mechanism. What still quizzes me
is ; communication between a specific client -server for a specific session
generates different encrypted text for the same plain text message. What
leads  to this? Can anybody elaborate?
Please reply.
Thanks and regards,
Suman



--
View this message in context: http://openssl.6102.n7.nabble.com/different-encrypted-text-for-the-same-plain-text-message-tp67595.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__openssl.6102.n7.nabble.com_different-2Dencrypted-2Dtext-2Dfor-2Dthe-2Dsame-2Dplain-2Dtext-2Dmessage-2Dtp67595.html&d=DQMD-g&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=bXJZ2KhOMl-dRHmkx3vDqeINnhhmqrdHUExGJDpoZ_E&s=aB8p8X69xD0FHcMAtF6HiF1qymHpB5kXmLjGMOACGFg&e=>
Sent from the OpenSSL - User mailing list archive at Nabble.com<http://nabble.com>.


--
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/20160728/728b9c38/attachment.html>

From thomas.francis.jr at pobox.com  Thu Jul 28 15:50:53 2016
From: thomas.francis.jr at pobox.com (Thomas Francis, Jr.)
Date: Thu, 28 Jul 2016 11:50:53 -0400
Subject: [openssl-users] Custom Random number generation while in Fips
	mode
In-Reply-To: <CALvRNOHvccrkphP4iKixafg9Z6zaND_riFRkC8aP-48qT28B7A@mail.gmail.com>
References: <CALvRNOHYaGLW7BqM3qer2dFGJCx9k+eL1wCgAFxDBd9YW0hjqQ@mail.gmail.com>
 <CALvRNOEmqejqA3_WaOMp8vN3s7Kq6_GRTDT6ZOMyGDDiQNi6yg@mail.gmail.com>
 <CALvRNOH7m-F5w6MrMhsohh7svVNSDYs9kfwrq_AbCGjGZtak=A@mail.gmail.com>
 <47898D85-8028-44A1-96A2-9C913D4A9527@pobox.com>
 <CALvRNOHvccrkphP4iKixafg9Z6zaND_riFRkC8aP-48qT28B7A@mail.gmail.com>
Message-ID: <420A880D-8F85-48E7-BB70-AE65F1A9BD8C@pobox.com>


> On Jul 28, 2016, at 11:00 AM, pratyush parimal <pratyush.parimal at gmail.com> wrote:
> 
> Hi Thomas,
> 
> Thanks for your response! It clears up matters a lot :)
> 
> There's one thing that I thought of though -- even though I'm generating the salt via non-OpenSSL means, the actual function that I'm using for hashing is "SHA512" from FIPS OpenSSL.
> Does the mere usage of salt that was generated via a non-FIPS-recommended approach violate my compliance ?

You used what is typically considered a cryptographic function (some form of RNG) from a source other than your cryptographic module running in approved mode.  Unless you can fully justify that use as for non-cryptographic purposes, your product is not complying with FIPS 140.  Given that it?s a salt for hashing passwords, I think you?ll have a really hard time convincing customers and auditors that the salt generation is for non-cryptographic purposes.  After all, if that?s not cryptographic, why didn?t you use something more deterministic (like a counter, or a user name) for the salt?

> I understand what you mean by "I'm not an auditor or a lawyer" , but I'd still appreciate your opinion / experience in the matter :)

In my limited experience, auditors are not computer security experts.  They?re smart people, but they tend to fall back on very simple guidelines when it comes to things outside their own expertise (like what?s a cryptographic algorithm, and what?s a cryptographic purpose).  You might be able to get away with it, but I wouldn?t want to stake a sale on it.  Especially not if there are penalties attached for failing an audit.

TOM

> Thanks,
> Pratyush.
> 
> On Thu, Jul 28, 2016 at 10:23 AM, Thomas Francis, Jr. <thomas.francis.jr at pobox.com> wrote:
> 
> > On Jul 27, 2016, at 8:18 PM, pratyush parimal <pratyush.parimal at gmail.com> wrote:
> >
> > Hi all,
> >
> > I work on a consumer application which is striving to be fips-140-2 compliant.
> >
> > I'm using OpenSSL as recommended in the fips guide by invoking fips_mode_set(). However, in certain parts of the same application, I'm using my own non-OpenSSL random number generator to generate salts for hashing passwords for the app user accounts(I'm not using RAND_bytes).
> >
> > Does anyone know if using my custom random number generator in this way violates the app's fips compliance?
> 
> That?s almost certainly a violation.  There might be a few edge cases where it is not, but they?re very unlikely.  To determine if you?re even close to such cases, ask: Does the RNG I?m using come from another FIPS 140 validated cryptographic module?  Am I using that module in approved mode?  Am I using that module according to its security policy?  Do I have explicit permission from the customers? auditors to mix two modules in my product?
> 
> If the answer to all of those questions is yes, you _might_ be OK, for now.  A few auditors (in the past, anyway) considered it OK to mix modules, while other auditors say no.  My own reading of FIPS 140-2 is that you may not mix modules.  But I?m not an auditor or a lawyer. :)
> 
> The other question to ask is: can I clearly explain that the use of the non-approved RNG is for non-cryptographic purposes, and easily justify that explanation?  Given what you said about why you?re using it, I?m pretty sure the answer to that one is ?no?. :)  And even if you could, that?s still a very weak argument to be making to your customers? auditors, who may decide it?s still not allowed even if they agree it?s for non-cryptographic purposes.
> 
> > Am I really supposed to be using
> > RAND_bytes for compliance reasons?
> 
> Yes.
> 
> > Thanks in advance!
> > Pratyush.
> >
> > --
> > 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


From brian at virtru.com  Thu Jul 28 22:04:29 2016
From: brian at virtru.com (Brian Jost)
Date: Thu, 28 Jul 2016 15:04:29 -0700
Subject: [openssl-users] iOS FIPS armv7, armv7s, arm64
In-Reply-To: <CAK0RZ3o1mtiXwLeVHXv-Q61ZjjYVwt9o06yGgYDBgzWxJu=+eg@mail.gmail.com>
References: <CAK0RZ3o1mtiXwLeVHXv-Q61ZjjYVwt9o06yGgYDBgzWxJu=+eg@mail.gmail.com>
Message-ID: <CAK0RZ3rTNUzh9WOU7Xkipi7sWbRcjNL4qmSjEhK-BgR_BUVj3g@mail.gmail.com>

>
> I have been trying for the life of me to get the FIPS module to compile
> for those supported platforms. Our app compiles for those platforms so
> without a compatible version of the openssl FIPS it causes errors.
>
> Is there any plans to have the FIPS module support those architectures?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160728/24b25d1e/attachment.html>

From asmarner at yahoo.com  Fri Jul 29 04:13:37 2016
From: asmarner at yahoo.com (asmarner at yahoo.com)
Date: Fri, 29 Jul 2016 04:13:37 +0000 (UTC)
Subject: [openssl-users] CA chain.
References: <579644300.7729662.1469765617231.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <579644300.7729662.1469765617231.JavaMail.yahoo@mail.yahoo.com>

Hi,
I am new to SSL stuff.
I was wondering whether the CA chain of a certificate can be changed.
Let say the initial chain is 

Server->Intermediate CA1->Intermediate CA2->Root CA
and during renewal we have Server->Root CA

Sent from Yahoo Mail. Get the app
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160729/f4a78663/attachment-0001.html>

From jb-openssl at wisemo.com  Fri Jul 29 08:16:35 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 29 Jul 2016 10:16:35 +0200
Subject: [openssl-users] CA chain.
In-Reply-To: <579644300.7729662.1469765617231.JavaMail.yahoo@mail.yahoo.com>
References: <579644300.7729662.1469765617231.JavaMail.yahoo.ref@mail.yahoo.com>
 <579644300.7729662.1469765617231.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <75a28aa1-3499-f4ea-e5e3-6fcb7e96686b@wisemo.com>

On 29/07/2016 06:13, asmarner at yahoo.com wrote:
> Hi,
>
> I am new to SSL stuff.
>
> I was wondering whether the CA chain of a certificate can be changed.
>
> Let say the initial chain is
>
> Server->Intermediate CA1->Intermediate CA2->Root CA
>
> and during renewal we have Server->Root CA
>
>
>

Renewal creates a brand new key with a brand new certificate,
which can (and often does) have an entirely new chain.For
example:

Server cert 2014->Big Name Intermediate G2014->Big Name Root CA R2010
Server cert 2016->Big Name Intermediate G2016->Big Name Root CA R2015

Also, it is possible to have more than one chain leading
to the same server cert, with the possibility to
reconfigure the server to send a different one of those
chains:

Server cert->Intermediate CA1->Intermediate CA2->Root CA1
Server cert->Intermediate CA1->Root CA2

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


From Suman.Patro-TRN at lntebg.com  Fri Jul 29 07:23:23 2016
From: Suman.Patro-TRN at lntebg.com (R-D intern)
Date: Fri, 29 Jul 2016 00:23:23 -0700 (MST)
Subject: [openssl-users] different encrypted text for the same plain
	text message
In-Reply-To: <b2a3f91d-9eed-6446-c870-d764558d514e@akamai.com>
References: <1469704795494-67595.post@n7.nabble.com>
 <b2a3f91d-9eed-6446-c870-d764558d514e@akamai.com>
Message-ID: <1469777003004-67618.post@n7.nabble.com>

Hello Benjamin,
Thanks for the reply.
I know the purpose and benefit of creating different cipher texts of the
same corresponding plain text.But I would like to know about the places
where this randomness gets introduced to create different encrypted
texts.Because SSL handshake takes place only once. After creation of  pre
secret key(for an entire session) at both the client and the server ends,
master key is created based on pre secret key, identifier label, client and
server random numbers which is again maintained for an entire session . The
master key is responsible for creating MAC key, bulk encryption key and IV
for client - server  read - write.  If the bulk encryption key (which is
responsible for encrypting the message ) for an entire session is fixed and
constant, then how is the encrypted text different?
Regards,
Suman



--
View this message in context: http://openssl.6102.n7.nabble.com/different-encrypted-text-for-the-same-plain-text-message-tp67595p67618.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From jb-openssl at wisemo.com  Fri Jul 29 08:43:14 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 29 Jul 2016 10:43:14 +0200
Subject: [openssl-users] different encrypted text for the same plain
 text message
In-Reply-To: <1469777003004-67618.post@n7.nabble.com>
References: <1469704795494-67595.post@n7.nabble.com>
 <b2a3f91d-9eed-6446-c870-d764558d514e@akamai.com>
 <1469777003004-67618.post@n7.nabble.com>
Message-ID: <0efb03d1-aca4-b88e-e786-b4b4a7a4943a@wisemo.com>

On 29/07/2016 09:23, R-D intern wrote:
> Hello Benjamin,
> Thanks for the reply.
> I know the purpose and benefit of creating different cipher texts of the
> same corresponding plain text.But I would like to know about the places
> where this randomness gets introduced to create different encrypted
> texts.Because SSL handshake takes place only once. After creation of  pre
> secret key(for an entire session) at both the client and the server ends,
> master key is created based on pre secret key, identifier label, client and
> server random numbers which is again maintained for an entire session . The
> master key is responsible for creating MAC key, bulk encryption key and IV
> for client - server  read - write.  If the bulk encryption key (which is
> responsible for encrypting the message ) for an entire session is fixed and
> constant, then how is the encrypted text different?
> Regards,
> Suman
>
The IV changes.  The precise method of changing the IV
depends on the TLS version, because the method used in
SSL 3 and TLS 1.0 was not as secure as it should be.

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


From Suman.Patro-TRN at lntebg.com  Fri Jul 29 07:30:09 2016
From: Suman.Patro-TRN at lntebg.com (R-D intern)
Date: Fri, 29 Jul 2016 00:30:09 -0700 (MST)
Subject: [openssl-users] server key exchange use case in
	ECDSA-ECDHE-AES-SHA
In-Reply-To: <0de1a335ab3b46cda7e527a0b3812f58@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <1469707674316-67596.post@n7.nabble.com>
 <0de1a335ab3b46cda7e527a0b3812f58@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <1469777409980-67620.post@n7.nabble.com>

Thanks Salz for the reply. I do understand the server key exchange is used to
involve even the server in the key exchange process to send the ECDHE public
key with the EC domain parameters so that the client creates the ECDHE
public key and the pre master secret. But even if there is no server key
exchange , what is the impact on the secure system? and what impact does it
show when used? 
Regards,
Suman



--
View this message in context: http://openssl.6102.n7.nabble.com/server-key-exchange-use-case-in-ECDSA-ECDHE-AES-SHA-tp67596p67620.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From Suman.Patro-TRN at lntebg.com  Fri Jul 29 07:35:04 2016
From: Suman.Patro-TRN at lntebg.com (R-D intern)
Date: Fri, 29 Jul 2016 00:35:04 -0700 (MST)
Subject: [openssl-users] different encrypted text for the same plain
	text message
In-Reply-To: <0efb03d1-aca4-b88e-e786-b4b4a7a4943a@wisemo.com>
References: <1469704795494-67595.post@n7.nabble.com>
 <b2a3f91d-9eed-6446-c870-d764558d514e@akamai.com>
 <1469777003004-67618.post@n7.nabble.com>
 <0efb03d1-aca4-b88e-e786-b4b4a7a4943a@wisemo.com>
Message-ID: <1469777704156-67621.post@n7.nabble.com>

Thank you, Jakob. 
I had read that the earlier versions IV logic used to use the last block of
the ciphertext as the IV for the next message and this proved vulnerable
giving way to reflection attacks. But is it only the IV that changes? the
bulk encryption and MAC keys remain constant throughput the entire session
right?
Regards,
Suman



--
View this message in context: http://openssl.6102.n7.nabble.com/different-encrypted-text-for-the-same-plain-text-message-tp67595p67621.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From 361719298 at qq.com  Fri Jul 29 08:59:55 2016
From: 361719298 at qq.com (=?ISO-8859-1?B?aGFwcHk=?=)
Date: Fri, 29 Jul 2016 16:59:55 +0800
Subject: [openssl-users]  Happy everyday
Message-ID: <tencent_41DAC958529278DF2D64BE1E@qq.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160729/8cafc2f3/attachment.html>

From Prabhat.Puroshottam at outlook.com  Fri Jul 29 15:13:10 2016
From: Prabhat.Puroshottam at outlook.com (Prabhat Puroshottam)
Date: Fri, 29 Jul 2016 15:13:10 +0000
Subject: [openssl-users] (no subject)
Message-ID: <PN1PR01MB03356384EE2756B6AEBC9B9AEE010@PN1PR01MB0335.INDPRD01.PROD.OUTLOOK.COM>

We are using session resumption with openssl, and to support that we are storing sessions in a file.

On the server side the allowed TLS version can be configured and server admin can change it. It can

be changed for example to allow only TLS 1.2. The problem is that if the client has SSL session

stored on the disk from a previous connection which has different TLS version than what server

expects as per the changed configuration, server drops the connection immediately.


My question is, is it possible for Openssl server to recover from such a scenario, by starting a full

handshake? Right now server drops the connection because of protocol mismatch.

Because if that is not the case the only other option left for us is to reconnect again if server rejects

connection.


Thanks,

Prabhat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160729/4c8a9afc/attachment.html>

From Prabhat.Puroshottam at outlook.com  Fri Jul 29 15:15:23 2016
From: Prabhat.Puroshottam at outlook.com (Prabhat Puroshottam)
Date: Fri, 29 Jul 2016 15:15:23 +0000
Subject: [openssl-users] SSL session resumption from different TLS version
In-Reply-To: <PN1PR01MB03356384EE2756B6AEBC9B9AEE010@PN1PR01MB0335.INDPRD01.PROD.OUTLOOK.COM>
References: <PN1PR01MB03356384EE2756B6AEBC9B9AEE010@PN1PR01MB0335.INDPRD01.PROD.OUTLOOK.COM>
Message-ID: <PN1PR01MB03353E9652559253EF6AAA52EE010@PN1PR01MB0335.INDPRD01.PROD.OUTLOOK.COM>

We are using session resumption with openssl, and to support that we are storing sessions in a file.

On the server side the allowed TLS version can be configured and server admin can change it. It can

be changed for example to allow only TLS 1.2. The problem is that if the client has SSL session

stored on the disk from a previous connection which has different TLS version than what server

expects as per the changed configuration, server drops the connection immediately.


My question is, is it possible for Openssl server to recover from such a scenario, by starting a full

handshake? Right now server drops the connection because of protocol mismatch.

Because if that is not the case the only other option left for us is to reconnect again if server rejects

connection.


Thanks,

Prabhat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160729/539c7593/attachment-0001.html>

From matt at openssl.org  Fri Jul 29 16:01:20 2016
From: matt at openssl.org (Matt Caswell)
Date: Fri, 29 Jul 2016 17:01:20 +0100
Subject: [openssl-users] SSL session resumption from different TLS
	version
In-Reply-To: <PN1PR01MB03353E9652559253EF6AAA52EE010@PN1PR01MB0335.INDPRD01.PROD.OUTLOOK.COM>
References: <PN1PR01MB03356384EE2756B6AEBC9B9AEE010@PN1PR01MB0335.INDPRD01.PROD.OUTLOOK.COM>
 <PN1PR01MB03353E9652559253EF6AAA52EE010@PN1PR01MB0335.INDPRD01.PROD.OUTLOOK.COM>
Message-ID: <37a73a8b-f947-83a0-5444-d2e8896c7a39@openssl.org>



On 29/07/16 16:15, Prabhat Puroshottam wrote:
> We are using session resumption with openssl, and to support that we are
> storing sessions in a file.
> 
> On the server side the allowed TLS version can be configured and server
> admin can change it. It can
> 
> be changed for example to allow only TLS 1.2. The problem is that if the
> client has SSL session
> 
> stored on the disk from a previous connection which has different TLS
> version than what server
> 
> expects as per the changed configuration, server drops the connection
> immediately.
> 
> 
> My question is, is it possible for Openssl server to recover from such a
> scenario, by starting a full
> 
> handshake? Right now server drops the connection because of protocol
> mismatch.
> 
> Because if that is not the case the only other option left for us is to
> reconnect again if server rejects

The problem is on the client side not on the server side.

Currently in 1.0.2 and earlier versions, when a client calls
SSL_set_session(), the method for the negotiated SSL version is also
set. So if the client and server previously negotiated version TLSv1.1,
then when SSL_set_session() is called for the new connection, the
version *on the client side* is fixed at TLSv1.1. If that is no longer
an acceptable version for the server then a failure will result - the
client will only accept TLSv1.1, the server won't accept it - no further
progress can be made.

In the scenario you are talking about this should only be a problem if
the server previously did not support TLSv1.2 at all and then had its
configuration changed to *only* support TLSv1.2. That seems like quite a
strange thing to do (perhaps a better policy is for the server to
support TLSv1.1 *and* TLSv1.2...at least for a while).

IIRC the behaviour is different in the forthcoming OpenSSL 1.1.0. In
that version the client does not fix its version to the session version.
The client remains version flexible - if the server does not wish to use
the same version as was in the session then they can still negotiate a
different one and the session simply does not get used.

Matt

From steve at openssl.org  Fri Jul 29 17:34:00 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 29 Jul 2016 17:34:00 +0000
Subject: [openssl-users] different encrypted text for the same plain
 text message
In-Reply-To: <1469777003004-67618.post@n7.nabble.com>
References: <1469704795494-67595.post@n7.nabble.com>
 <b2a3f91d-9eed-6446-c870-d764558d514e@akamai.com>
 <1469777003004-67618.post@n7.nabble.com>
Message-ID: <20160729173400.GA31182@openssl.org>

On Fri, Jul 29, 2016, R-D intern wrote:

> Hello Benjamin,
> Thanks for the reply.
> I know the purpose and benefit of creating different cipher texts of the
> same corresponding plain text.But I would like to know about the places
> where this randomness gets introduced to create different encrypted
> texts.Because SSL handshake takes place only once. After creation of  pre
> secret key(for an entire session) at both the client and the server ends,
> master key is created based on pre secret key, identifier label, client and
> server random numbers which is again maintained for an entire session . The
> master key is responsible for creating MAC key, bulk encryption key and IV
> for client - server  read - write.  If the bulk encryption key (which is
> responsible for encrypting the message ) for an entire session is fixed and
> constant, then how is the encrypted text different?

The master key along with client and server random values is used to derive
the session keys. That is the random values from the current session. So if
you resume a session the master key is the same but the random values differ
and so the session keys are different too.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From julien at trigofacile.com  Fri Jul 29 19:15:16 2016
From: julien at trigofacile.com (=?UTF-8?Q?Julien_=c3=89LIE?=)
Date: Fri, 29 Jul 2016 21:15:16 +0200
Subject: [openssl-users] Wording in OpenSSL documentation for
	SSL_CTX_set_options
Message-ID: <98066b7a-d9c7-537e-e07d-b72414e4d4ab@trigofacile.com>

Hi,

In a recent discussion in the news.software.nntp newsgroup, we discussed 
the use of SSL_OP_CIPHER_SERVER_PREFERENCE, and would like to point out 
a possible improvement in the wording of the documentation of 
SSL_CTX_set_options.

Currently, there is in OpenSSL documentation:

   https://www.openssl.org/docs/manmaster/ssl/SSL_CONF_cmd.html

"-serverpref
Use server and not client preference order when determining which cipher 
suite, signature algorithm or elliptic curve to use for an incoming 
connection. Equivalent to SSL_OP_CIPHER_SERVER_PREFERENCE. Only used by 
servers."


   https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_options.html

"When choosing a cipher, use the server's preferences instead of the 
client preferences. When not set, the SSL server will always follow the 
clients preferences. When set, the SSL/TLS server will choose following 
its own preferences."


Maybe the documentation of SSL_CTX_set_options should also mention 
signature algorithms and elliptic curves.

Also, Michael B?uerle noted that TLSv1.3 seems to change things a bit 
because FFDHE groups can now be negotiated too (codes starting at 256):
<https://tools.ietf.org/html/draft-ietf-tls-tls13-14#section-4.2.3>
and therefore suggests to mention "(EC)DHE groups" in both the above man 
pages.


Have a nice day,

-- 
Julien ?LIE

? La libertad, Sancho, es uno de los m?s preciosos dones que a los
   hombres dieron los cielos; con ella no pueden igualarse los tesoros
   que encierran la tierra y el mar: por la libertad, as? como por la
   honra, se puede y debe aventurar la vida. ? (Miguel de Cervantes
   Saavedra)

From Suman.Patro-TRN at lntebg.com  Sat Jul 30 08:28:49 2016
From: Suman.Patro-TRN at lntebg.com (R-D intern)
Date: Sat, 30 Jul 2016 01:28:49 -0700 (MST)
Subject: [openssl-users] different encrypted text for the same plain
	text message
In-Reply-To: <20160729173400.GA31182@openssl.org>
References: <1469704795494-67595.post@n7.nabble.com>
 <b2a3f91d-9eed-6446-c870-d764558d514e@akamai.com>
 <1469777003004-67618.post@n7.nabble.com> <20160729173400.GA31182@openssl.org>
Message-ID: <1469867329276-67635.post@n7.nabble.com>

Thank you,  Stephen. 
You answered regarding randomness in different sessions if session
resumption is on. But my question revolves around the same messages within
the same Session. How different encrypted texts are formed of the same
plaintext between a client -server? 
Is it only the iv changes or the MAC,  BULK encryption keys as well? 



--
View this message in context: http://openssl.6102.n7.nabble.com/different-encrypted-text-for-the-same-plain-text-message-tp67595p67635.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From steve at openssl.org  Sat Jul 30 12:33:29 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Sat, 30 Jul 2016 12:33:29 +0000
Subject: [openssl-users] different encrypted text for the same plain
 text message
In-Reply-To: <1469867329276-67635.post@n7.nabble.com>
References: <1469704795494-67595.post@n7.nabble.com>
 <b2a3f91d-9eed-6446-c870-d764558d514e@akamai.com>
 <1469777003004-67618.post@n7.nabble.com>
 <20160729173400.GA31182@openssl.org>
 <1469867329276-67635.post@n7.nabble.com>
Message-ID: <20160730123329.GA18270@openssl.org>

On Sat, Jul 30, 2016, R-D intern wrote:

> Thank you,  Stephen. 
> You answered regarding randomness in different sessions if session
> resumption is on. But my question revolves around the same messages within
> the same Session. How different encrypted texts are formed of the same
> plaintext between a client -server? 
> Is it only the iv changes or the MAC,  BULK encryption keys as well? 
> 

That has already been answered: only the IV changes. The technique used
depends on the version of TLS/SSL. There is also some additional data put
through the MAC which depends on the record sequence number. So even with the
same application data different data is MACed.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From matt at openssl.org  Sun Jul 31 20:43:35 2016
From: matt at openssl.org (Matt Caswell)
Date: Sun, 31 Jul 2016 21:43:35 +0100
Subject: [openssl-users] OpenSSL 1.1.0 release dates
Message-ID: <11b42d9f-9593-d9e8-3d3c-2ef0a360a56a@openssl.org>

FYI, we have recently updated our release strategy for version 1.1.0:
https://www.openssl.org/policies/releasestrat.html

The change is to add the following two dates:

- 4th August 2016, 1.1.0 beta 3 release
- 25th August 2016, 1.1.0 public release

Matt

From asmarner at yahoo.com  Fri Jul 29 04:11:36 2016
From: asmarner at yahoo.com (asmarner at yahoo.com)
Date: Fri, 29 Jul 2016 04:11:36 +0000 (UTC)
Subject: [openssl-users] CA chain.
References: <1234749318.8026242.1469765496260.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <1234749318.8026242.1469765496260.JavaMail.yahoo@mail.yahoo.com>

Hi,
I am new to SSL stuff.
I was wondering whether the CA chain of a certificate can be changed.
Let say the initial chain is 

Server->Intermediate CA1->Intermediate CA2->Root CA
and during renewal we have Server->Root CA


Sent from Yahoo Mail. Get the app
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160729/0c724b58/attachment.html>