Re: [openssl-dev] [openssl.org #2595] Capitalize X509 subject key STREET according to rfc1779
Hodie IV Id. Sep. MMXI, Maarten Billemont via RT scripsit: > According to rfc1779, the key STREET in the subject name should be > capitalized. > > obj_dat.h specifies it as a lower-cased "street". > > This is incorrect and breaks when OpenSSL is used to parse in > rfc1779-compliant distinguished names generated by external parties. > > The solution is to upper-case it to "STREET", just like "C", "CN", etc. The "street" attribute type (OID 2.5.3.9) is not defined by RFC1779. This RFC doesn't state that those tokens are case sensitive (you could even use "cn" instead of "CN"). This RFC is defective at least in one aspect: the following names are not considered equal: CN=James Bond, O=MI6, C=UK CN=James \ Bond, O=MI6, C=UK CN=\ \ jAmeS bonD, O=MI6, C=UK these examples are equal, following X.520 rules. -- Erwann ABALEA Département R&D KEYNECTIS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2596] report possible bug in 1.0.0e install.
On 9/10/2011 1:05 PM, Zaccone, Warren via RT wrote: Below are the results for the 1.0.0e build. It appears to be not be finding gcc as it attempts to use cc. Results? Could you send the output from config and make? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Issue with dtls1_clear changes from issue #2506
On Sep 9, 2011, at 4:56 PM, Paul Witty wrote: > Hi, > Since updating to OpenSSL 1.0.0e from 1.0.0d, I've been suffering a crash > when connecting with DTLS. I've tracked this down to trying to perform a > memcpy of (unsigned int)-13 in do_dtls1_write (where a length of -13 is > passed all the way down from dtls1_do_Write, which seems to be because the > MTU on the DTLS context is 0, despite having manually set it to a non-zero > value. Further investigation shows that the change to dtls1_clear is > clearing everything in the DTLS1_STATE, which includes my previously > configured MTU. Preserving the value of the MTU across the memset in > dtls1_clear fixes the issue. Preserving the MTU might be correct, but it should't crash. So how to you get it to crash? Calling SSL_write() with a len of -13? I would like to be able to recreate the crash... Best regards Michael > > -- > > Paul Witty > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org > __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2596] report possible bug in 1.0.0e install.
I have just downloaded openssl-1.0.0e and attempted to compile on openssl-1.0.0.e on Solaris 10/Sparc platform using GCC 3.4.6 and found that the make fails immediately. I had installed 1.0.0.d a few weeks earlier with no problems. Afer 1.0.0e failed, as a test, I repeated the openssl-1.0.0d and the make proceeds to completion. Nothing on my system changed between the two tests. Below are the results for the 1.0.0e build. It appears to be not be finding gcc as it attempts to use cc. Is there a possible bug or new preequisite introduced for 1.0.0e? thank you. Warren Zaccone Software Engineer, Telcordia Technologies. results for 1.0.0e --- apachedir=/usr/local/apache ./config --openssldir=$apache_dir/ssl shared --prefix=$apache_dir/ssl make __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2595] Capitalize X509 subject key STREET according to rfc1779
According to rfc1779, the key STREET in the subject name should be capitalized. obj_dat.h specifies it as a lower-cased "street". This is incorrect and breaks when OpenSSL is used to parse in rfc1779-compliant distinguished names generated by external parties. The solution is to upper-case it to "STREET", just like "C", "CN", etc. smime.p7s Description: S/MIME cryptographic signature
Issue with dtls1_clear changes from issue #2506
Hi, Since updating to OpenSSL 1.0.0e from 1.0.0d, I've been suffering a crash when connecting with DTLS. I've tracked this down to trying to perform a memcpy of (unsigned int)-13 in do_dtls1_write (where a length of -13 is passed all the way down from dtls1_do_Write, which seems to be because the MTU on the DTLS context is 0, despite having manually set it to a non-zero value. Further investigation shows that the change to dtls1_clear is clearing everything in the DTLS1_STATE, which includes my previously configured MTU. Preserving the value of the MTU across the memset in dtls1_clear fixes the issue. -- Paul Witty __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2505] [PATCH] DTLS Session Resumption Timer Bug
On Sep 10, 2011, at 12:10 AM, David Woodhouse wrote: > On Wed, 2011-04-27 at 16:16 +0200, Robin Seggelmann via RT wrote: >> The client always starts timer for the retransmission of the >> ChangeCipherSpec and Finished, although that is only correct when >> performing a full handshake. With the abbreviated session resumption >> handshake, these messages are not followed by a response of the >> server, so the timer is never stopped and causes retransmissions until >> the connection is dropped. This patch adds the distinction between >> full and abbreviated handshakes and prevents the timer from being >> started in the latter case. > > Hm, I thought those packets were *supposed* to be periodically resent. > If they're lost the first time, doesn't that mean that *all* our > subsequent data packets are effectively lost too? And since we never > expect a response from the server anyway, we have no way of knowing. http://tools.ietf.org/html/draft-ietf-tls-rfc4347-bis-06 state in section 4.3.4: In addition, for at least twice the default MSL defined for [TCP], when in the FINISHED state, the node which transmits the last flight (the server in an ordinary handshake or the client in a resumed handshake) MUST respond to a retransmit of the peer's last flight with a retransmit of the last flight. So if the last flight is lost, the peer will retransmit its last flight and will trigger a retransmission of the last flight. Therefore you don't have a timer running on the last flight of the handshake. Best regards Michael > > -- > dwmw2 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
