Re: OpenSSL FIPS Object Module 1.2.4 support for Apple iOS and OS X
Steve Marquess a écrit : The OpenSSL FIPS Object Module 1.2 has been extended to include support for the iOS and Mac OS X operating systems, as the newly released revision 1.2.4. This new support was made possible by a collaboration with Thursby Software Systems, Inc, (http://www.thursby.com/), a leading vendor of commercial Apple enterprise integration products. Do they (or anyone else) also intend to sponsor the same extension for the new v2.0 module ? I must say that in the rather extensive list of OS for the new module OS X and iOS are the two that are most obviously missing. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL FIPS Object Module 1.2.4 support for Apple iOS and OS X
Jean-Marc Desperrier a écrit : Do they (or anyone else) also intend to sponsor the same extension for the new v2.0 module ? I must say that in the rather extensive list of OS for the new module OS X and iOS are the two that are most obviously missing. Well :-) I've *just* seen the following text in paragraph 2.7 of the user guide of module v2.0 : [pending] Addition of Apple iOS 5.1 on ARM [pending] Addition of WinCE 5.0 on ARM [pending] Addition of Linux 2.6 on PowerPC32-e500 [pending] Addition of DSP Media Framework 1.4 on TI C64x+ So, on the other hand there's no Mac OS X pending ? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Static analysis?
On Tue, 17 Apr 2012, Lubomír Sedlář wrote: I would like to ask if any static analysis tool was ever used to detect possible problems in OpenSSL source code. Is some tool used regularly? I tried running Clang Static Analyzer [1] on the source of OpenSSL. Julia Lawall a écrit : A few years ago, we did some experiments on finding problems in error handling in OpenSSL using Coccinelle: Finding Error Handling Bugs in OpenSSL using Coccinelle http://coccinelle.lip6.fr/papers/edcc10.pdf It's a bit surprising if none of those tools could identify the badness of the code involved in the just published memory corruption vulnerability. I fail to see anything subtle in that vulnerability. Now, the trouble might be in the eye of the reviewer who'd assume way too easily that the downcasting of a long is OK. I think it would be really interesting to understand *why* this wasn't seen earlier, and check all the rest of the code for potentially similar problem. Or similar case of assuming that doing this is not very clean but won't hurt us instead of cleaning the code to do things properly. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1794] [PATCH] SRP ciphersuites in 1.0.1 and 1.1.0 (updated)
Jean-Marc Desperrier wrote: Tom Wu via RT wrote: This patch adds full RFC 5054 support in OpenSSL 1.0.1 and 1.1.0, and has been updated to apply cleanly to the 20101229 dev snapshot. This version of the patch supercedes the earlier patches submitted under this ticket. Please let me know what the next steps are for the integration of this patch into OpenSSL 1.0.1 and 1.1.0. Tom, where is there a reference clearly explaining *why* they are no more patent concern on SRP ? (for example the Phoenix Technologies Ltd. one https://datatracker.ietf.org/ipr/63 ). After some researches : Stanford U. owns US patent 6,539,479 on SRP and makes it available free of any fee and of any restriction on usage. Patent 6,539,479 references patent US 5241599 and US 5440635, held by Lucent [EKE patents]. However the text, including the prior art description, doesn't clearly describe what the relation with those two EKE patents is, and so in my opinion doesn't clearly state if implementing it requires to use elements of US 5241599 and US 5440635 (and so require a licence on those two patents) or not. I'm tempted to think that if US 5241599 and US 5440635 were actually required for an implementation it would be described, but without further info, the situation still sounds somewhat uncertain to me. Patent 6,539,479 does not seem to reference the claims of patent 6,226,383 by Phoenix [SPEKE patent] that was not yet delivered when the patent application for patent 6,539 was submitted. In my understanding, this should mean an implementation of patent 6,539,479 doesn't infringe on patent 6,226,383, because : - two patents can't be delivered on the same thing (except when the patent office makes a big mistake), it's the duty of the patent office to check concurrent applications to avoid that - so the existing art research done by the examiner should have digged up this existing application, even if still under examination. If it were truly relevant I'd really expect it to be at least be referenced by the patent. But my researches also show that concerns about the IPR status are indeed the origin of RFC 5054 (TLS/SRP) being informational instead of standard track. I didn't search every message on the TLS group, so I'm unable to say if those concerns were later recused but that for some reason the TLS group was still unwilling to go with standard track. Trivia : - On Dec. 16, 1996, Tom Wu posted a message to the sci.crypt newsgroup named Remote Authentication Protocol With Diffie-Hellman - On March 25, 1997 Jablon, David P. filed a patent application, leading to the delivery of patent 6,226,383 (SPEKE/Phoenix patent) that includes a reference to this newsgroup message (so acknowledges it as prior art) - On July 15, 1997, Tom Wu filed a provisional patent application, leading to the delivery of patent 6,539,479 System and method for securely logging onto a remotely located computer This helps explain that patents 6,539,479 and 6,226,383 can be very close to each other, without 6,226,383 being relevant for 6,539,479 because the shared elements were already public at the time the application for 6,226,383 was made. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1794] [PATCH] SRP ciphersuites in 1.0.1 and 1.1.0 (updated)
Tom Wu via RT wrote: This patch adds full RFC 5054 support in OpenSSL 1.0.1 and 1.1.0, and has been updated to apply cleanly to the 20101229 dev snapshot. This version of the patch supercedes the earlier patches submitted under this ticket. Please let me know what the next steps are for the integration of this patch into OpenSSL 1.0.1 and 1.1.0. Tom, where is there a reference clearly explaining *why* they are no more patent concern on SRP ? (for example the Phoenix Technologies Ltd. one https://datatracker.ietf.org/ipr/63 ). I've seen a number of people say it's not a concern anymore, but I did not find yet a real explanation, and there are some people who like to see something clearer than just hearsay. RFC 5054 by itself isn't a definitive proof, since it's only informational and not standard track. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL security advisory
OpenSSL wrote: OpenSSL Ciphersuite Downgrade Attack = A flaw has been found in the OpenSSL SSL/TLS server code where an old bug workaround allows malicous clients to modify the stored session cache ciphersuite. In some cases the ciphersuite can be downgraded to a weaker one on subsequent connections. The OpenSSL security team would like to thank Martin Rex for reporting this issue. This vulnerability is tracked as CVE-2010-4180 I understand that RedHat had already identified this issue five years ago : https://bugzilla.redhat.com/show_bug.cgi?id=175779 You should have a better channel of communication with RedHat so that when they find something like that, they communicate it to you, even when it's about something that they see as a minor issue. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2045] [PATCH] Use Intel AES-NI automatically where available.
On 26/03/2010 18:31, Andy Polyakov wrote: My patch (unapplied for 6 months now) would at least fix the problem of the AESNI engine not being used automatically, The reason for low priority is that the code is in development, lack of hardware... Hum ? Maybe the openssl team doesn't have the hardware to test the code yet, but there's now a good number of Arrandale and Clarkdale out now. Asus is selling notebooks with Arrandale since January. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
Bodo Moeller wrote: it's code elsewhere that no longer tolerates the coarse logic we are changing in the patch, which has been around forever. In fact, I already suspected that, thanks for the confirmation. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory
OpenSSL wrote: Record of death vulnerability in OpenSSL 0.9.8f through 0.9.8m How comes the vulnerability doesn't touch 0.9.8e though the patched file wasn't modified between 0.9.8e and 0.9.8f ? But that code was modified between 0.9.8d and 0.9.8e, see this patch : http://cvs.openssl.org/filediff?f=openssl/ssl/s3_pkt.cv1=1.60v2=1.61 Could it be a reference mistake and that this vulnerability is from 0.9.8e through 0.9.8m ? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Fwd: Renegotiation denied wrong?
Thor Lancelot Simon wrote: I think it's a mistake to send a fatal alert. In the past week as I've been experimenting with this, I've encountered a number of embedded client devices (cellphones -- I suspect I know which stack they're using but I'm not certain, so I won't identify the vendor here) which do periodic renegotiations and can't be configured not to. I hacked up no-renegotiation alert for a somewhat simpler TLS implementation since I kept tripping over myself trying to do it with OpenSSL. The result was that these clients could maintain connections -- they ignore the failed renegotiation. With OpenSSL, these clients simply lose their connection and don't display pages. I think this is wrong. I support wholly this description of the situation. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: SHA-2 support in openssl?
smitha daggubati wrote: Does openssl have support for SHA-2. ? I know that SHA-2 is part of the crypto library but looking at the way the context is setup in ssl_ctx_new we are setiing up ret-sha1=EVP_get_digestbyname(ssl3-sha1)) So is there a way to establish an openssl connection using SHA-2 currently? Yes openssl has support for SHA-2, but what it doesn't have is support for a SSL cipher suite using SHA-2. It's a bit late in being updated to support the SHA-2 suites from RFC5289. I suppose this not the main priority of the development team, since sha1 inside tls is not actually endangered at the moment. Any help in implementing it, and rearchitecturing the code where use of SHA-1 is hardcoded, would certainly be welcomed. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: TLS renegotiation attack, mod_ssl and OpenSSL
Joe Orton wrote: On Fri, Nov 06, 2009 at 12:00:06AM +, Joe Orton wrote: On Thu, Nov 05, 2009 at 09:31:00PM +, Joe Orton wrote: * we can detect in mod_ssl when the client is renegotiating by using the callback installed using SSL_CTX_set_info_callback(), in conjunction with suitable flags in the SSLConnRec to detect the cases where this is either a server-initiated renegotiation or the initial handshake on the connection. Here is a very rough first hack (for discussion/testing purposes only!): A second hack, slightly less rough hack: Joe, instead of hard coding this, a very nice solution would be to have a new directive SSLServerRenegociation Allow or even more flexible SSLRenegociation disabled/serveronly/enabled with disabled as default value. This would allow sites that need server renegotiation to make it quite more secure, by using a strategy similar to what is suggested here : https://issues.apache.org/bugzilla/show_bug.cgi?id=39243#c7 The obvious answer for an 'upload' style operation is to ensure they never hit your upload page without going through a simpler front page which first enforces the renegotation. This can be your upload form page. So the server would first direct the user to a SSLRenegociation serveronly page that is conceived so that request to it can not be abused, and use SSLRenegociation enabled for all unsafe locations, the user accessing them only when his connection has already been upgraded to use client certs (this is similar to what Peter suggested already). The only weak point in that solution is that Apache seems to require renegotiation in quite a few case where it should not be really necessary. But as any case of Apache requiring renegotiation will break anyone using the more radical option of fully disabling renegotiation I'll open a separate message for this. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
TLS renegotiation disabling : mod_ssl and OpenSSL 0.9.8l
Hi, So when Apache is compiled with openssl 0.9.8l, TLS renegotiation will be fully disabled. But the problem with that if that some comments of the discussion inside https://issues.apache.org/bugzilla/show_bug.cgi?id=39243 are true, this change will unexpectedly break very badly a *lot* of sites. Those comments suggest Apache currently requests TLS renegotiation in quite a few cases where it should not be needed, and where it won't be expected. First there's the short SSLSessionCacheTimeout problem : https://issues.apache.org/bugzilla/show_bug.cgi?id=39243#c23 In my understanding, SSLSessionCacheTimeout should never cause renegociation. If the client tries to do a SSL session resume, and the server does not have the SSL info for that SSL id anymore, the result is a brand new SSL Session, *not* a SSL renegotiation. If they actually are resumes caused by SSLSessionCacheTimeout, then it seems SSLSessionCacheTimeout times out sessions that are currently active at the TCP level, and where the user is just trying to send more data. Or there's a bug in the resume code that first says yes, then finds the session id should have been timed out, so forces a renegotiation. Anyway, this means this was already broken in some way before, but it used to be of little consequences and will now be a huge problem. Second there's the SSLVerifyClient optional problem : https://issues.apache.org/bugzilla/show_bug.cgi?id=39243#c21 When SSLVerifyClient optional is actually used to allow various authentication level, it's expected that the change will break the site. But what this comment report is that simply having SSLVerifyClient optional set, not having any different value anywhere, not even *using* client certificates, will cause renegotiation to happen and therefore sites to break when TLS renegotiation is disabled. And Peter Gutmann just reported on oss-sec that they are many servers configured like this (see http://seclists.org/oss-sec/2009/q4/138 ) with their admin not even knowing that they require client certificates. According to the following comment, it might be that a very simple patch would correct this problems : https://issues.apache.org/bugzilla/show_bug.cgi?id=39243#c16 (I've checked the svn code for apache 2.2.x, that piece of code is still exactly the same, but I don't understand enough to be sure that just handling the optional case in addition to the none case would really be enough to solve the problem) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1915] Bug Report : Abort when race condition occurs in ERR_get_state
In ERR_get_state (err_def.c:613), there's the following code :
/* If a race occured in this function and we came second, tmpp
* is the first one that we just replaced. */
if (tmpp)
ERR_STATE_free(tmpp);
As already suggested in 2006 in this message
http://www.mail-archive.com/openssl-dev@openssl.org/msg21037.html ,
this race question can occur only if one of the following is true :
- CRYPTO_set_id_callback is broken and is not unique amongst threads
- CRYPTO_set_locking_callback is broken and does not lock
- CRYPTO_set_locking_callback is not been set
All are situation that the OpenSSL should *not* try to recover from.
What's more, the race condition *cannot* be recovered.
The call to ERR_STATE_free(tmpp) will cause the other thread that owns a
pointer to tmpp to write inside a buffer that has already been
desallocated and to double-free it or to overwrite the buffer when it
has already been reallocated to someone else.
I suggest the following code instead :
/* If a race occurred in this function, either multi-thread
* locking is broken/disabled or CRYPTO_set_id_callback is not
* returning an identifier that's unique for each thread. */
if (tmpp) {
fprintf(stderr,ERR_get_state, fatal locking or id error\n);
abort(); /* ok */
}
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Reenabling mdc-2 in openssl by default
Hi, I notice MDC-2 is not enabled by default on openssl 0.9.8. This has no reason to be, the IBM patent on MDC-2 has expired in march 2002 because IBM did not renew it. (the wikipedia MDC-2 page has the link proving it. Go to : https://ramps.uspto.gov/eram/getMaintFeesInfo.do?patentNum=4908861applicationNum=07090633 click on get bibliographic data, and you'll see : 03/13/2002 Patent Expired for Failure to Pay Maintenance Fees. Even if IBM had paid, more than 20 years have elapsed since filing date, so it would be expired all the same. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Bilinear pairings
Diego de Freitas Aranha wrote: During my Msc, I developed an implementation of bilinear pairings over elliptic curves using OpenSSL. In particular, an implementation of the Tate pairing over curves defined on prime fields. I am writing to ask you guys if the OpenSSL team has any interest on merging this implementation in the main tree, considering that bilinear pairings are a novel cryptographic primitive and that a lot of new applications such as Identity-Based Cryptography and Certicateless Cryptography could be developed using exclusively the OpenSSL library. I think openssl is stronly oriented toward ssl and pki cryptography, and today there is no standard scheme defined to integrate ID-based cryptography within any of those. As long as it is so, it doesn't make much sense to integrate support for this inside openssl. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
OCSP_basic_verify and a NULL X509_STORE argument
Hi, I have some code that calls OCSP_basic_verify with a NULL st argument, and I have just found it will crash if the ocsp cert is self-signed. What happens is that OCSP_basic_verify doesn't check the argument is non NULL, but calls X509_verify_cert(ctx) and we end up in X509_STORE_get_by_subject that assumes vs-ctx is not NULL. I think a test is needed in X509_STORE_get_by_subject, but should OCSP_basic_verify also never be called with a NULL store argument ? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
ts.h using NO_* instead of OPENSSL_NO_*
Hi, I'm trying to build a version of openssl with a very strongly reduced set of cryptographic primitives. I've already hit a number of quirks (it might be it mostly impacts Windows builds) that I'll try to detail when I have time, but here is one that's easy to fix : ts.h doesn't use the standard OPENSSL_NO_* defines for excluded stuff but instead NO_BUFFER, NO_EVP, etc. This just impacts of few line at top of ts.h __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] fix I/O buffer size handling for enc application (repost)
Klaus Weidner wrote:
[...] - please let me know if you have issues with the
bugfix, [...]
The following patch uses the ANSI C setvbuf(3) function [...]
+ {
+ if (bufsize != NULL)
+ setvbuf(stdin, (char *)NULL, _IONBF, 0);
BIO_set_fp(in,stdin,BIO_NOCLOSE);
+ }
[...]
There's at least clearly an issue about testing the availability of the
setvbuf call before trying to compile it in.
It's not because it's ANSI that it will be available on every system
openssl runs on.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: How to extract certificate from PKCS#7 message?
camino (sent by Nabble.com) wrote: i have a signed letter, how can i extract the certificate from it ? [...] but i wonder how to achieve it in program The openssl documentation is somewhat lacking on this subject. Still http://www.openssl.org/docs/crypto/PKCS7_verify.html# gives you a starting point on what to look for, and then you can check in the application and example code how it is used. http://www.koders.com point to some interesting example of use of PKCS7_verify inside cryptonit http://www.koders.com/info.aspx?c=ProjectInfopid=2ZS8UD4SZWU8FM4812TTAHRFGF and The OSP client Toolkit http://www.koders.com/info.aspx?c=ProjectInfopid=86UW22T2KU8XWL89Q61WNN2KLH that also demonstrate what you want to do. Or you go the easy way and buy the book. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: pkcs12_parse problem
Dr. Stephen Henson wrote: PKCS12_parse() in its current form will only handle well formed PKCS#12 files which contain a private key, its corresponding certificate and zero or more CA certificates. The PKCS#12 standard doesn't seem to require that a PKCS#12 files contains all of this, I've seen some with only private keys, and also with only certificates. Is there a way openssl can handle the format so a whole certificat chain is associated to the private not just its corresponding certificate ? Sorry I don't know what exactly it corresponds to technically but usually PKCS#12 loaded from java appear as you describe 1 key entry, together with a certificate, n ca cert entry, but it's possible to create a pkcs#12 that appears to java as 1 key entry, together with a certificate chain, n ca cert entry. Until now I have been able to create such p12 only with java tools, never with openssl. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1276] [PATCH] TLS Extensions - RFC 3546 (Try 2)
Brian Long wrote: On Fri, 2006-01-27 at 15:23 +0100, Stephen Henson via RT wrote: Note that some TLS extension code has recently been committed to the HEAD (0.9.9-dev). So if this is to be included into OpenSSL it would have to work with that. Is it true that openssl-0.9.7 and 0.9.8 are frozen with regards to features like TLS extensions? The message above means that there's no way a patch that's different and incompatible with the one in 0.9.9 will be included. Not more than that. This will never get inside 0.9.7, that's certain. But I think the door is not completely closed on it getting inside an evolution of 0.9.8. 0.9.8 is really recent as far as openssl development goes, 0.9.9 is a really far perspective, so I think we *could* get in a situation where a convincing case could be presented to the openssl team that this feature is important enough to deserve to be back-ported and integrated in the stable release. But only if the code gets really stable and the change does not impact too much of 0.9.8. For example, Red Hat Enterprise Linux 4 was released almost 1 year ago and includes 0.9.7a plus all the security patches issue over the last year. If I need the TLS extension patch officially supported by Red Hat, it would have to come from upstream -- your group -- or they would have to support it as a one-off patch. I was hoping your group would accept it, but it appears your efforts are concentrated on 0.9.9- dev. Please check how your patch compares to the one that's in 0.9.9, if it brings something useful to it and in that case submit the enhancements to the 0.9.9 version. Then see how to create a patch based on the 0.9.9 version (and on any enhancement you could find), but that applies to 0.9.8. Then there's a chance in the future, RHEL 5 with 0.9.8 will some day include it. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PEM_read_bio_X509:BIO_gets:unsupported method
David Taylor wrote: I only just joined this list today to past this patch. So in one word : - for technical reasons, fd bio are preferable to file bio on Solaris - but as fd bio don't implement gets, they are not usable as a direct replacement for file bio - your attached patch implements gets for fd bio to align them functionally with file bio and solve that problem Note that this gets is implemented in a way that can become very bad performance-wise (there's no easy solution for that, I'm mostly saying implementers shoud beware of it). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Missing const-ification for s2i_ASN1_INTEGER
Hi, I just noticed that ASN1_INTEGER * s2i_ASN1_INTEGER(X509V3_EXT_METHOD *meth, char *value); should be ASN1_INTEGER * s2i_ASN1_INTEGER(X509V3_EXT_METHOD *meth, const char *value); BTW the v3_sxnet.c code is missing a *lot* of const-ification. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1212] chil engine no longer works with static locks in 0.9.8
john via RT wrote: Why is it that the static locks have not been removed completely for 0.9.8? If it is to keep some backward compatibility with older apps, or ones that see no reason to change, would it not be preferable if the whole of openssl was compatible in this way, including the engines? At least a good first step would be to update mttest.c so that it shows how to use dynamic locks. Maybe the sample code for that from gSoap would be adequate, but we'd need to ask the author of gSoap : http://www.cs.fsu.edu/~engelen/soapdoc2.html#tth_sEc19.19 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: othername in subjectAltName
Michael Bell wrote:
Rich Salz schrieb:
OtherName ::= SEQUENCE {
type-idOBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id }
It means that the type-id OID defines the datatype of the value. Think
of it as a union.
So the software must now the datatypes of all used OIDs if it wants to
decode this sequence?
Yes.
It can only decode the sequence for OIDs it knows in advance, but this
leaves people free to use their own OID with totally arbitrary content.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
0.9.7-b1 openssl ocsp core dump on invalid -CAfile parameter
In 0.9.7-b1, an invalid value for the CAfile parameter in a call to openssl ocsp generates a core dump when verifying OCSP requests. When the setup_verify function fails because it can not open the CAfile parameters, it returns NULL. The function OCSP_basic_verify that is called just after that does not support a value of NULL for it's store parameters and core dumps. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #93] 0.9.7-b1 openssl ocsp core dump on invalid -CAfile parameter
In 0.9.7-b1, an invalid value for the CAfile parameter in a call to openssl ocsp generates a core dump when verifying OCSP requests. When the setup_verify function fails because it can not open the CAfile parameters, it returns NULL. The function OCSP_basic_verify that is called just after that does not support a value of NULL for it's store parameters and core dumps. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #84] small problem with openssl 0.9.7.b1 and the ocsp function
The doc says : Create an OCSP request and write it to a file: openssl ocsp -issuer issuer.pem -cert c1.pem -cert c2.pem -reqout req.der In my test, I try to do exactly that with : openssl ocsp -issuer ocsp_ca.pem -cert ocsp_valide.cer -cert ocsp_revoque.cer -reqout req.der But no req.der file is created. openssl ocsp -issuer ocsp_ca.pem -cert ocsp_valide.cer -cert ocsp_revoque.cer -text gives me this : OCSP Request Data: Version: 1 (0x0) Requestor List: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: F2891129F54C9DDEAA3E936DBFB870560335231F Issuer Key Hash: 6BFA75BDCDF62581B3A4265BB4462F11D3321B78 Serial Number: 56C745365CDD8F771ED95A323267765F Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: F2891129F54C9DDEAA3E936DBFB870560335231F Issuer Key Hash: 6BFA75BDCDF62581B3A4265BB4462F11D3321B78 Serial Number: 01CA788D7569634FDF4BF6B4029CE1A9 Request Extensions: OCSP Nonce: 955CF8ECF789D6B68443206F4BAE2163 openssl ocsp -issuer ocsp_ca.pem -cert ocsp_valide.cer -cert ocsp_revoque.cer -text -reqout req.der gives only the text output and does not create the file. Are you in the process of writing the programming side documentation for the ocsp functionnality ? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #82] `NID_uniqueIdentifier' undeclared (first usein this function)
Mike Pechkin via RT wrote: On Wed, Jun 05, 2002 at 03:10:58PM +0200, Lutz Jaenicke via RT wrote: The problem is caused by inconsistent definitions for the OID values. According to RFC2256, the OID 2.5.4.45 is assigned to X500UniqueIdentifier. UniqueIdentifier was assigned to pilotAttributeType.44 in RFC1274. Let's discuss how to fix it!? Well, the situation is in fact even a little bit worst than that. In order to do something that makes sense, the good question to ask is : Why do people want to deal with an identifier called uniqueid, or something similar ?. In most case, the answer is because they have an LDAP environment, where there is an identifier called uid, and they want to use that one. And this uid from LDAP is neither 2.5.4.45, nor pilotAttributeType.44 from RFC1274. It's pilotAttributeType.1 from RFC1274, whose true name is Userid, but that is wrongly called uniqueID in many LDAP documents . See for the exact reference this : http://ldap.akbkhome.com/attribute/uid.html and as an example of the name confusion, this (the OID itself shown is the correct one) : http://developer.novell.com/ndk/doc/ndslib/schm_enu/data/sdk5430.html The older version of the dumpasn1.cfg file of the dumpasn1 tool I had on my hard drive has it wrong too, but the current version on http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.cfg does display it as Userid, not uniqueID. The situation is a little simplified when one knows that nobody uses pilotAttributeType.44 from RFC1274. For instance, mod_ssl 2.8.8-1.3.24 use workaround: Also, markus@ created this temp patch: Comments ? Send the authors a description of the problem, and tell them that they can not solve the problem in automatic mode, they need to check what they truly want here and if this is the uid attribute from LDAP, then they should use the long string name userId to get the OID 0.9.2342.19200300.100.1.1 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #82] `NID_uniqueIdentifier' undeclared (first usein this function)
Lutz Jaenicke via RT wrote: I would like to see more discussions about this issue. I have looked around some more and still find referrals like http://www.alvestrand.no/objectid/2.5.4.45.html with the UniqueIdentifier term instead of X500UniqueIdentifier. This is the original name of this OID. The X500 has been added by the LDAP people to avoid the name collision with pilotAttributeType.44 from RFC1274 and make things a _little_ simpler. Well, when people say they want UniqueIdentifier, it should be likely they want 2.5.4.45 more than pilotAttributeType.44 from RFC1274, because this one is not used for anything. But in many cases, they truly want userId, pilotAttributeType.1 from RFC1274 and got the name wrong. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
small problem with openssl 0.9.7.b1 and the ocsp function
The doc says : Create an OCSP request and write it to a file: openssl ocsp -issuer issuer.pem -cert c1.pem -cert c2.pem -reqout req.der In my test, I try to do exactly that with : openssl ocsp -issuer ocsp_ca.pem -cert ocsp_valide.cer -cert ocsp_revoque.cer -reqout req.der But no req.der file is created. openssl ocsp -issuer ocsp_ca.pem -cert ocsp_valide.cer -cert ocsp_revoque.cer -text gives me this : OCSP Request Data: Version: 1 (0x0) Requestor List: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: F2891129F54C9DDEAA3E936DBFB870560335231F Issuer Key Hash: 6BFA75BDCDF62581B3A4265BB4462F11D3321B78 Serial Number: 56C745365CDD8F771ED95A323267765F Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: F2891129F54C9DDEAA3E936DBFB870560335231F Issuer Key Hash: 6BFA75BDCDF62581B3A4265BB4462F11D3321B78 Serial Number: 01CA788D7569634FDF4BF6B4029CE1A9 Request Extensions: OCSP Nonce: 955CF8ECF789D6B68443206F4BAE2163 openssl ocsp -issuer ocsp_ca.pem -cert ocsp_valide.cer -cert ocsp_revoque.cer -text -reqout req.der gives only the text output and does not create the file. Are you in the process of writing the programming side documentation for the ocsp functionnality ? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
openssl 0.9.7 and debug
./config -d on a standard linux box (RedHat 7.1) gives : Operating system: i686-whatever-linux2 This system (debug-linux-pentium) is not supported. See file INSTALL for details I think that out of the box debug support for this kind of platform is needed. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: DC= fields (subject NID) in 9.7?
Bear Giles wrote: As for domainComponent in particular, the RFC clearly limits it to 64 octets Not _the_ RFC. Which RFC ? Not 2459, there's not a word about domainComponent. Not 1274, which first defined domainComponent, it did not fit a size limit. So that must be some LDAP related RFC, maybe 2377. You can't expect openssl to enforce respect of every LDAP RFC around, it's not a LDAP product basically, and in fact it does not respect quite a few things you could find in the newer PKIX RFC. If you need that size limit, do it in your application. Or provide a patch for that, and the OpenSSL development team will decide if it's useful to include it or not. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL libraries on Windows, reworked.
Richard Levitte - VMS Whacker wrote: I'd like your help to name the OpenSSL libraries. The idea I have right now is the following (base names are 'osslc' for 'libcrypto', 'ossls' for 'libssl', and one adds 's' for single-threaded or 'm' for multithreaded, as well as 'd' when it's a debug build): Single threaded Static, non-debug - osslcs.lib, osslss.lib Single threaded Static, debug - osslcsd.lib, osslssd.lib Multithreaded Static, non-debug - osslcm.lib, osslsm.lib Multithreaded Static, debug - osslcmd.lib, osslsmd.lib Multithreaded DLL (shared), non-debug - osslcm.dll, osslsm.dll Multithreaded DLL (shared), debug - osslcmd.dll, osslsmd.dll I'd be in favor of longer names, with the version number included when there are incompabilities between version number. And when the user modifies one of the options that will result in a library that is binary incompatible with other libraries of the same version number (for exemple suppressing an algorythm, that will result in a change of some of the openssl structures sizes), an even longer name that either shows the exact option used, or is based on a date value and will be unique for each compilation. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL libraries on Windows, reworked.
Richard Levitte - VMS Whacker wrote: From: Jean-Marc Desperrier [EMAIL PROTECTED] jean-marc.desperrier I'd be in favor of longer names, with the jean-marc.desperrier version number included when there are jean-marc.desperrier incompabilities between version number. I think there's still support for win16. Isn't long file names a problem there? Yes, it is. Well, if I'm the only one who favors long names, I won't insist. But if others were in favor of longer names, nothing restricts from having a different configuration for that in win16 and in win32. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
UID is usually RFC1274 user id, not X500 unique id
Hi, I have found out in a project that the use of the short name UID in openssl, for the Unique Identifier OID defined in X520, definitively causes confusion and potentials problems. There seem a very common use of this abreviation to designate instead the user id, defined in RFC1274. A little search on google with UID and rfc1274 shows that this what is used in LDAP products. I have been directly confronted with a confusion caused by the fact someone who wanted to insert the RFC1274 uid, just found uid in the short name handled by openssl, and inserted a X520 unique Identifier instead of what was truly intended. Unique Identifier is OID 2 5 4 45 and come from X520 User Identifier is OID 0 9 2342 19200300 100 1 1 and comes from RFC1274. 0 9 2342 19200300 100 1 34 in RFC1274 is also named unique Identifier, but seems little used. In order to avoid this name clash, the choice has been made in the LDAP world that the x500 UID would be named x500UniqueIdentifier. See for example : http://www.openldap.org/lists/ietf-ldapext/199812/msg7.html So it would be best if openssl avoids the confusing uid abreviation and switches to something similar to x500UniqueIdentifier. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: UID is usually RFC1274 user id, not X500 unique id
Richard Levitte - VMS Whacker wrote: From: Jean-Marc Desperrier [EMAIL PROTECTED] Note that since the short name UID exists in both camps and OpenSSL is somewhere in the middle, there's a definite conflict of interest here. However, most people I've talked with consider UID to be deprecated in the X.500 world, so perhaps it's not such a problem any more. Thoughts on this? The little research I've done not make me an expert on this at all, but gave me the feeling that not many people in the X500 world really use the UID abreviation for unique identifier, but that the UID abreviation for user identifier is definitively frequent. Deprecating the use of uid in openssl seems to me the best thing to do, changing it to designate user id instead of unique identifier should _not_ be done, because that would mean that recompiling applications with a newer version of openssl would have unexpected, transparent changes everywhere the string uid is used, in a call to OBJ_txt2nid for example. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: UID is usually RFC1274 user id, not X500 unique id
Oscar Jacobsson wrote: I don't think we could really go ahead and deprecate the use of UID, as RFC 2253 defines it as the proper string encoding of the userid attribute type, and the short names appear to be used when string encoding distinguished names. The UID of openssl is NOT the UID of RFC2253. When openssl displays the string UID in a name, it's a X500UniqueIdentifier, not a unserid. Right now openssl displays userid as 0.9.2342.19200300.100.1.1 in the string encoding of distinguished names. So deprecating the UID/X500UniqueIdentifier will not remove any functionnality with regard to the RFC you're quoting. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [ANNOUNCEMENT] OpenSSL 0.9.6a Beta 3 released
Richard Levitte - VMS Whacker wrote: mlist it's true you're welcome to do versioning anyway you want..but mlist noone i know has ever taken 'a' as a newer release on the same mlist version. Now you know one: me. :-) And I can give you another one: RMS (emacs 19.34 was followed by 19.34a which was followed by 19.34b) Richard, there is still one thing that is a bit confusing. Usually subversion with a a, b, c index are very minor version with very little change, and it's unusual to have a beta release for such a minor release. Most people would do 0.9.6a directly, and switch to 0.9.6b if anything needs to be changed, then 0.9.6c ... I think something similar to the linux kernel naming, like 0.9.6a-pre1, 0.9.6a-pre2, 0.9.6a-pre3 would be more explicit. (I just checked and found out the naming scheme for the pre-release was different for each of the 2.0, 2.2 and 2.4 pre-release :-) . It does not seem easy to find the ideal naming for pre-releases ...) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: What to do when there is no /dev/random ??
Insh_Allah wrote: I've had the same problem. What I did was feed the entropy pool with anything I could find that was at least a bit 'random'. I suggest the content of the stack on any architecture where there are asynchronous interrupts that will store content in your local stack. Easiest portable way to access it is to read the content of uninitialised variables. Easy to implement and not so bad if properly done (do not read a value that is set by the preceeding function call, do not read a value that is too far to be overwritten by asynchronous interrupts). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: What to do when there is no /dev/random ??
Insh_Allah wrote:
I suggest the content of the stack on any architecture where there are
asynchronous interrupts that will store content in your local stack.
They are architectures where a context switch is made after every interrupt, and
the local stack is not used.
They are architectures where there's no asynchronous interrupt.
Just as a warning.
Easy to implement and not so bad if properly done (do not read a value
that is
set by the preceeding function call, do not read a value that is too far
to be
overwritten by asynchronous interrupts).
Hm, have to think about 'properly doing' this, though.
I guess something like this should be a reasonable start:
static void RAND_collect_from_stack(void)
{
char buffer_to_catch_interrupt_data[256+1];
I hope I didn't open the Pandora box.
First, I suggest you do not rely _only_ on this.
Add it to all your other randomness sources, do not replace them.
Second, the actual way to test that is to compile your application, set a
breakpoint in that function, check if the values in
buffer_to_catch_interrupt_data are actually different every time the breakpoint
is hitten.
And _retest_ it if you modify your application.
Thirsd, I hope no one ever copies this function blindly, and calls
RAND_collect_from_stack() just after the call to
here_I_use_a_512_byte_table_allocated_in_the_stack_and_initialize_it_to_zero().
The randomness of this is _very_ dependant of what happens before in the
program, and change in it will change that randomness very easily.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Incorrect MIME headers separators in 0.9.5a
Emmanuel Gadaix wrote: When generating MIME mails, e.g. for signing an email, OpenSSL adds an extra white space before the semi-column sign that separates the headers. In doing so, it violates MIME syntax (see RFC 2045, 2046, 2047). Some mail clients will not be able to understand the MIME parts. For example, Lotus Notes client v5.06a (latest release). Note: in order to properly test all this, you need a recent version of Lotus Notes (= 5.04). We have tested with 5.06a (client and server). I suggest Emmanuel that you contact Lotus and tell them about this bug in _their_ software. It fails to handle messages that have a correct MIME syntax (see RFC 2045, 2046, 2047), and it should be corrected for better interoperability. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: smartcard / openssl integration?
Alexander 'Alfe' Fetke wrote: [...] The modulus and exponent are also retrieve from the smart card, and stored in the RSA structure at this time. does this mean that the secret information (the private key) is retrieved from the smart card to carry out the computation in the computer as in conventional ways? Alexander, this part of the information is _public_, and it's useful to know the size of the key pair you are handling and to be able to verify the signature by soft. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Key genration in IE
"Tridib, Mumbai" wrote: 3. If I have a crypto API which can generate a hash of a data and then sign it using the private key of the certificate, then is it possible to output a PKCS#7 signed-object?If yes, How it can be done. Technically talking, yes, but only pkcs#7 _without_ any signed attribute. You'd need to create a new pkcs#7 the standard way, and instead of calling the sign function, fill the signature inside signerinfo, with the data you got from the crypto API. Get the RFC2630, understand the inside format of PKCS#7, understand how this is represented inside openssl, do it. It's not going to be very easy. I wonder if including a function DoPkcs7FromPkcs1Signature would be an option in OpenSSL ? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cvs commit: openssl FAQ
Jeffrey Altman wrote: From the GNUTLS site: "You should view this as an alternative implementation of OpenSSL (actually GNUTLS is closer to Eric Young's SSLEAY rather than OpenSSL)." What does this mean? A great news for everyone for writes GPL code that needs crypto. When the FSF bugs you, you tell them that your code is intended to be used with GNUTLS :-) Unfortunately, it just won't work with the current version, but users have the choice to get the source code of GNUTLS and debug it or to get OpenSSL and get going. If you distribute pre-compiled code (a linux distribution ?), just distribute the pre-compiled GNUTLS in addition to OpenSSL, and have a choice at some point between using the GNUTLS or OpenSSL library for crypto, with a big warning that it just won't work if you choose GNUTLS, because it's only an alpha version. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CRLs and self-signed root certs.
Goetz Babin-Ebell wrote: Should a self-signed root certificate ever need to be revoked, shall it list itself in its usual CRL(s), as the last thing it does before it is thrown away, or is it sufficient (from its users' standpoint) that it simply ceases to issue more CRLs? Since the root certificate is at this time invalid, you can't use it to sign the CTL... Then sign a CRL with a revocation date in future with regard to the CRL signing date. I don't beliveve anything stop a CA from announcing it will revoque a certificate _before_ it does it. I don't know if the client will like it. Technically speaking the emitter of the root cert is the root cert itself, therefore it is entitled to revoke itself. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Bug in openssl 0.9.6 for certificate verification
Dr S N Henson wrote: Jean-Marc Desperrier wrote: I have some code that I could use to verify certificate, and that's not able to do it anymore when compiled with 0.9.6 I traced this to the following line (330) in the file by_dir.c - if(j != -1) tmp=sk_X509_OBJECT_value(xl-store_ctx-objs,i); + if(j != -1) tmp=sk_X509_OBJECT_value(xl-store_ctx-objs,j); Urgh, yes that is a bug. Maybe you could have something similar to the stable version of linux to incorporate only very simple bug corrections like this one. Something like : 0.9.6 = 0.9.6a only bugs corrections = 0.9.6b additional bugs corrections = dev 0.9.7 new features + bugs corrections I'm probably not the first to ask for that :-) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Bug in openssl 0.9.6 for certificate verification
Dr S N Henson wrote: I make the verification using a call to X509_verify_cert. When the call returns, they are some errors left in the error stack from a call to check_issued to check if the check is self-signed or not. Is this a normal behaviour ? That shouldn't happen unless you set the X509_V_FLAG_CB_ISSUER_CHECK flag. What specific error are you getting? I wasn't very clear. The return code is one, telling me that there is no error, but X509_STORE_CTX_get_error gives me an error value of 29 (subject issuer mismatch). I was afraid this error would be stored somewhere and be annoying later, but I've realised now it's freed when I call X509_STORE_CTX_free, therefore it's probably a non-issue. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Bug in openssl 0.9.6 for certificate verification
I have some code that I could use to verify certificate, and that's not able to do it anymore when compiled with 0.9.6 I traced this to the following line (330) in the file by_dir.c This line has been changed from 0.9.5 to 0.9.6. I think the last argument in the call to sk_X509_OBJECT_value should be j instead of I. The check works for me again with the following change. CRYPTO_r_lock(CRYPTO_LOCK_X509_STORE); j = sk_X509_OBJECT_find(xl-store_ctx-objs,stmp); - if(j != -1) tmp=sk_X509_OBJECT_value(xl-store_ctx-objs,i); + if(j != -1) tmp=sk_X509_OBJECT_value(xl-store_ctx-objs,j); else tmp = NULL; CRYPTO_r_unlock(CRYPTO_LOCK_X509_STORE); What I don't get is why this bug does not appear when using "opensssl -verify" or in the tests ? I make the verification using a call to X509_verify_cert. When the call returns, they are some errors left in the error stack from a call to check_issued to check if the check is self-signed or not. Is this a normal behaviour ? Are this two problems a sign that I should update my code and use another method for verification ? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
BER in pkcs7 encoding
Hi, pkcs#7 DER structures generated by openssl have two header in BER (infinite length) for the two sequence at the very start of the encoding. Is there a good reason for that ? I have a tool that 's annoyed by this BER encoding and I think it should not be too difficult to patch p7_lib.c so that DER encoding with a limited length is used instead, but I'd like to know if there is a reason for the choice of BER encoding here. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Object names
Michael Ströder wrote: Currently there is no such central document since everybody is free to define OIDs after getting a OID arc. Not even a central registry exists. No official central regitry, yes, but at least there is this non-official one : http://www.alvestrand.no/objectid/ It's quite complete, while sure not comprehensive. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Object names
Jean-Marc Desperrier wrote: Michael Ströder wrote: Currently there is no such central document since everybody is free to define OIDs after getting a OID arc. Not even a central registry exists. No official central regitry, yes, but at least there is this non-official one : http://www.alvestrand.no/objectid/ It's quite complete, while sure not comprehensive. Gulp, just read the messages before. Sorry about that. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Timestamping
Andrey Romanov wrote: I am looking for information about timestamping in general (Any standards existing?) and how to implement it using OpenSSL library. So far I am were not able to find anything, even about MS Authenticode implementation details. Read the TSP (http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-09.txt) and DVCS (http://www.ietf.org/internet-drafts/draft-ietf-pkix-dcs-05.txt) drafts from the IETF. You can find link to them on the PKIX page : http://www.ietf.org/html.charters/pkix-charter.html This site will be interesting, well it used to be, it seems to be dead. No idea where this is gone : http://www.ioc.ee/~helger/crypto/link/timestamp.html This function in MS authenticode is not AFAIK documented externally. It uses a service provided by Verisign. A search with time stamp will give some links to various crypto vendors. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Creating a certificate on windows 2000 and windows nt
simon wrote: I have the PEM file that they generated. How do I covert the data in that pem file into a certificate that can import to windows 2000/NT Your immediate help will be appreciated I think you should convert the PEM file to DER-encoded form first,then you can import it to windows 2000/NT.Microsoft's products use certificates in DER-encoded form.I think that the library you use should be able to do this covert. - Change the name of the file so that the extension is .cer instead of .pem - double-click on it and install it You don't need to convert anything. Make sure to also install the root self-signed certificate. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Outlook certs - bug in MS or OpenSSL?
Ben Laurie wrote: The bug is in MS - they are encoding a top-bit-set number without inserting a leading zero, so OpenSSL (correctly) sees it as negative. The output of openssl x509 is not very explicit. It probably should fail, instead of diplaying it as a 510 bits number without saying it's a *negative* 510 bits number. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Const in fonction arguments
I've found out three functions in OpenSSL aren't defined with const arguments, despites the fact they do not modify them. They are : ASN1_PRINTABLE_type (arg 1) and X509_NAME_ENTRY_create_by_* (arg 4) X509_NAME_add_entry_by_* (arg 4) which end up calling ASN1_STRING_set that has the const. X509_NAME_add_entry * (arg 2) I think the const value is also useful to prevent memory leaks in fonctions that "inserts" some data : The fonctions has the const, it makes a copy of the data I insert, I must not forget to free the original pointer. (like X509_NAME_add_entry) The fonctions hasn't the const, it does not make a copy of the data I insert, and if applicable, it will try to free it. (like ASN1_TYPE_set ). Maybe I'm just missing the fact this is the meaning of _add and _set ? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Keon
Oscar Jacobsson wrote: Richard Levitte - VMS Whacker wrote: * 105:d=2 hl=2 l= 19 cons: cont [ 0 ] 107:d=3 hl=2 l= 17 cons: SEQUENCE 109:d=4 hl=2 l= 15 cons: SEQUENCE * 111:d=5 hl=2 l= 3 prim: OBJECT:X509v3 Authority Key Identifier * 116:d=5 hl=2 l= 8 prim: OCTET STRING This sure looks like crlExtrensions to me (as in a RFC-2459 X509v2 CRL), which is EXPLICIT OPTIONAL, which I don't really know what that implies... This mean you don't have to include it, but if you do, you should add a tag [0] (offset 105) in front of it that must not overwrite the SEQUENCE tag of CRLExtensions (offset 107). Next SEQUENCE(offset 109) is CRLExtension. then the OID is the extnId (offset 111), we don't see the optionnal flag critical , but we have the extnValue(offset 116) : OCTET STRING This looks like a valid crlExtensions as in a RFC-2459, but I'm not sure if OpenSSL pretends to support RFC-2459 fully. No one has any comment on the fact OBJ_obj2nid is not able to retrieve objects that have been added with OBJ_create ? I have seen code in OBJ_obj2nid that seems to be intended to enable that, but it is flawed. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OBJ_create and OBJ_obj2nid
Dr Stephen Henson wrote: There are several possible reasons for this. I've done some things which use OBJ_create() fairly recently and I can't remember it being altered since then. I wrote a short test for this, and it works in it. I'll check my program until I find what can make the difference with the test. I really don't see the reason for the difference at first. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
OBJ_create and OBJ_obj2nid
Hi, Either I've got something wrong or there's a big problem here. I create new objects with OBJ_create, giving their OID as an argument and getting back an NID. Then I convert some data that is the DER encoding of an OID to an ASN1_OBJECT. I then call OBJ_obj2nid, expecting to get back the correct NID, if the OID of the object happens to be the one of the new object I created. Unfortunately I always get 0. I tried to understand why this happens. obj-dat.c : line 350+ OBJ_obj2nid searches the object with the call lh_retrieve(added,ad) where ad.obj is the pointer to my ASN1_OBJECT. As lh_retrieve considers ad as a void * pointer, it indexes on the content of the structures ad, not on what the pointer ad.obj inside this structure points to. This mean I have a chance to find my data back only if the value of the pointer ad.obj is the same as the one was used when OBJ_add_object was called to add this OID in the hash table. In this case, OBJ_add_object was called inside OBJ_create, and the pointer used was allocated during the call and freed just thereafter. So I don't stand a single chance the value is the same. Am I doing it wrong ? Should I call another function ? Do you consider this kind of behaviour as normal ? How much costs a pint of beer in australia ? ;-) Is the only way to get this right to create an ASN1_OBJECT from my OID string, instead of using OBJ_create and then do an obj_cmp between ASN1_OBJECT until I find the right one ? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Trying to compile gpkcs11
Richard Levitte - VMS Whacker wrote: sorribas Hi, I'm trying to compile the gpkcs11 module witch uses the sorribas openssl. The gpkcs11 try to find a file called evp_pkcs11.h sorribas and doesn't found it. Where can I find that file? As far as I know, evp_pkcs11.h is not part of OpenSSL. I suggest you ask on [EMAIL PROTECTED] or [EMAIL PROTECTED] evp_pkcs11.h is just a part of a patch created to solve a name conflict problem. I sent some explanations to sorribas on what he should do. When loading from Netscape on a Sun platform a dynamic library that uses OpenSSL functions, it somehow conflicts internally. This patch creates an alternative version of OpenSSL, with a header in front of the function names. This is a fast and dirty, but working solution to that problem. May be a better solution should be found. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [Eben Moglen moglen@columbia.edu] Re: US crypto export restrictionsand GNU (fwd)
Ben Laurie wrote: Eben Moglen wrote: In the worst case analysis, components exported now might subsequently become non-exportable in the event that Perhaps I'm failing to understand here ... you say "No code not originally developed in the US would be subject to..." but sure we're talking about code that _was_ developed inside the US. Indeed. If some code in open source project has been developed in the USA, then we must keep a trace of where it is to be able to remove it later in case the regulation in the US become more restrictive. So it does not propagate in the meaning that the european code never becomes unexportable, but in order to take advantage of that, we need to be able to "clean" it and remove all the american code in it at the moment we need to. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Typo in objects.h
Peter Onion wrote: s/OSCP/OCSP/ I think ??? Let's all dump english. From now, we speak vi !! Oh, year, here is an english translation for the slow to learn : Shouldn't we replace the substring OSCP in this line by the string OCSP ? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Compile Problems With .94 HERE IT IS AGAIN
But the log was explicit enough to guess his problem is truly that the assembler is not present. So install gas Schaefer. And check carefully all the pipes before turning on, you don't want your computer to explode and blow away the office, do you ? ;-) Hannes Reinecke wrote: Tom Schaefer wrote: HERE IT IS AGAIN: OK, what am I doing wrong. I've been successful on some systems, but it fails on others, and I really have no clue as to why. I run everything the way you show in the docs, but it fails. Now it seems to be failing more than not, and I don't know what's missing from my system, i.e. some sort of lib file or what in order to make your software compile properly. I invoked: fw:/usr/src/openssl-0.9.4 # make -I/usr/src/openssl-0.9.4/include/openssl It seems to make it all the way through, but towards the end, we this: Positively ? Unfortunately the make script does not necessarily stop on an error, so if the compiler gets an error on compiling a file that file will just be skipped and subsequently left out of the archive. This in turn will lead to several procedures not being found in the final link step, just as happened in your log file. Therefore check the log file whether indeed _all_ files have been compiled. HTH, Hannes -- Hannes Reinecke [EMAIL PROTECTED] Fluid Loading and Instrumentation Center Tel: (+44) 131 449 5111 x4430 Dept. of Civil Offshore Engineering Fax: (+44) 131 451 3154 Heriot Watt University, Edinburgh EH14 4AS __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Current state of PKCS#11 support in OpenSSL?
"Reddie, Steven" wrote: Greg, I'm not sure about the state of PKCS#11 support in relation to the latest snapshot, however I can give you some answers in relation to the latest release, OpenSSL 0.9.4. It seems everyone is duplicating this effort in fact. I supected that already. * [***HACK***] set RSA-p to the handle of the PKCS#11 key I did that a slightly different way. set RSA-meth-app_data to the handle of the PKCS#11 key But with this method, meth has to be dynamically allocated each time. Your method is a bit simpler, but you have to override the type of rsa-p. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: DECLARE_STACK_OF(ASN1_UTF8STRING) and 0.9.4 problem.
Dr Stephen Henson wrote: #define DECLARE_STACK_OF(type) \ #define IMPLEMENT_STACK_OF(type) \ There's a problem with this solution. If you need another ASN1_STRING equivalent STACK_OF such as ASN1_IA5STRING you get a conflict because the structure STACK_ASN1_STRING gets declared twice. If the STACK_OF macro is removed from the definitions and written in full as STACK_##type then it should expand to STACK_ASN1_UTF8STRING which avoids this. Yes, but then if somewhere inside my code, I expand the STACK_OF call, we could as well remove the STACK_OF macro, because modifying it in the futur will break the code. You probably mean expand inside asn1_mac.h As this problem does not appear only with STACK_OF, what you suggest here is in fact that the deepness of concatenations should always be one in asn1_mac.h. This means you can't use any macro that does concatenation inside asn1_mac.h anymore, you have to expand instead. I don't believe this is good. But still we need coherent behaviour for the macro of asn1_mac.h when the argument has been #defined. So I think instead the deepness of all the concatenations inside asn1_mac.h should be increased so that it's always at least 2. Here are some other macro they are problems with. Calls to M_ASN1_I2D_len_SEQUENCE_opt_type(ASN1_UTF8STRING,a-statusString, i2d_ASN1_UTF8STRING); M_ASN1_I2D_put_SEQUENCE_opt_type(ASN1_UTF8STRING,a-statusString, i2d_ASN1_UTF8STRING); M_ASN1_D2I_get_seq_opt_type(ASN1_UTF8STRING, ret-statusString, d2i_ASN1_UTF8STRING, ASN1_UTF8STRING_free); will with 0.9.4 expand to calls to functions names with either ASN1_UTF8STRING, or ASN1_STRING in a rather random way. If we do the modifications above to asn1_mac.h, we will only declare and implement the ASN1_STRING. IMPLEMENT_STACK_OF(ASN1_STRING) DECLARE_STACK_OF(ASN1_STRING) and all macro calls inside the user code will expand to ASN1_STRING when they are called with ASN1_UTF8STRING as an argument. If later ASN1_UTF8STRING becomes defined as an actual independent type, we only need to add IMPLEMENT_STACK_OF(ASN1_UTF8STRING) and DECLARE_STACK_OF(ASN1_UTF8STRING) and do not need to change anything in the rest of the code. If IMPLEMENT_STACK_OF(ASN1_STRING), DECLARE_STACK_OF(ASN1_STRING) is added inside the standard OpenSSL header, later changing ASN1_UTF8STRING, ASN1_IA5STRING, etc... to an actual type will only mean to add new IMPLEMENT_STACK_OF(), DECLARE_STACK_OF() inside the OpenSSL code and change nothing to user code. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
DECLARE_STACK_OF(ASN1_UTF8STRING) and 0.9.4 problem.
I'm trying to define an ASN1 type that has an element which is a stack
of UTF-8 string usins 0.9.4 and I have some problems.
I figured I had to define the type STACK_OF(ASN1_UTF8STRING) with
DECLARE_STACK_OF(ASN1_UTF8STRING), but this bring problems.
I suggest you give up this message now if you're not a guru of C
precompiler.
In non-debug version, we have :
#define ASN1_UTF8STRING ASN1_STRING
and
#define DECLARE_STACK_OF(type) \
typedef struct stack_st_##type \
{ \
STACK stack; \
} STACK_OF(type); \
STACK_OF(type) *sk_##type##_new(int (*cmp)(type **,type **)); \
STACK_OF(type) *sk_##type##_new_null(void); \
void sk_##type##_free(STACK_OF(type) *sk); \
and
#define IMPLEMENT_STACK_OF(type) \
STACK_OF(type) *sk_##type##_new(int (*cmp)(type **,type **)) \
{ return (STACK_OF(type) *)sk_new(cmp); } \
STACK_OF(type) *sk_##type##_new_null() \
{ return (STACK_OF(type) *)sk_new_null(); } \
void sk_##type##_free(STACK_OF(type) *sk) \
{ sk_free((STACK *)sk); } \
and
#define STACK_OF(type) STACK_##type
In DECLARE_STACK_OF, the precompiler makes concatenation first.
Then replaces ASN1_UTF8STRING with ASN1_STRING everywhere.
Then the sub-macros are handled.
This gives :
typedef struct stack_st_ASN1_UTF8STRING { STACK stack; }
STACK_ASN1_STRING;
STACK_ASN1_STRING *sk_ASN1_UTF8STRING_new(int (*cmp)( ASN1_STRING
**, ASN1_STRING **));
STACK_ASN1_STRING *sk_ASN1_UTF8STRING_new_null(void);
void sk_ASN1_UTF8STRING_free(STACK_ASN1_STRING *sk);
which sound like what we want.
The names have ASN1_UTF8STRING in them, but the type is actually
ASN1_STRING.
But now when I declare :
STACK_OF(ASN1_UTF8STRING) in my code, the deepness of the call is one so
I get STACK_ASN1_UTF8STRING instead of the STACK_ASN1_STRING I had in
DECLARE_STACK_OF.
Is this solved in 0.9.5 ?
I think the deepness of DECLARE_STACK_OF should be increased by one so
that the behaviour becomes constant:
#define STACK_OF(type) STACK_##type
#define INTERNAL_STACK_OF(type) STACK_##type
#define STACK_OF(type) INTERNAL_STACK_OF(type)
We also have :
#define ASN1_UTF8STRING_free(a) ASN1_STRING_free((ASN1_STRING *)a)
But when I call :
sk_ASN1_UTF8STRING_pop_free(a-extensions,ASN1_UTF8STRING_free);
I don't get the result I want because ASN1_UTF8STRING_free is not
replaced by ASN1_STRING_free as this is not a function call.
We should have :
#define ASN1_UTF8STRING_free ASN1_STRING_free
because anyway a is of type ASN1_STRING.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: MD4 anyone?
Denis Ducamp wrote: I'm developping a password cracker using libcrypto.a from openssl. The goal isn't to have a fast password cracker as John the Ripper, but to document the different algorithmes, their weaknesses and to show how easy it is to develop such a piece of software when good libraries (as openssl) exist. NTLM algorithm uses MD4 and I must have a md4 implementation in my sources. MD5 and other algorithmes in openssl have asm optimized implementation so if md4 could have such asm optimization it could be great because faster than the standard C implementation. I've seen recently MD4 has been broken to the point you can get any text to hash to a given MD4 hash value, if you have around 10 byte in the original text you can give free value to. You should try to document yourself on that and to implement this to break the password. Of course if the password is shorter than 10 byte, brute force might be faster to find the correct value. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Can't have SSL with multiple domain names on a single server...
Ben Laurie wrote: No - it is a limitation of the current usage of http over SSL, where the SSL negotiation happens before the Host: header. It is a general problem inherent in most simplistic SSL-ing of protocols, where the rush to SSL-ify meant that the protocol got broken, rather than integrating SSL into the protocol itself. See draft-ietf-tls-http-upgrade-05.txt to see how this can be fixed. This is, of course, true, but doesn't really get us anywhere, since no browser supports it. Get to work. Add support for it in Mozilla. Microsoft will follow. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Can't have SSL with multiple domain names on a single server...
Dr Stephen Henson wrote: Jean-Marc Desperrier wrote: Ben Laurie wrote: No - it is a limitation of the current usage of http over SSL, where the SSL negotiation happens before the Host: header. It is a general problem inherent in most simplistic SSL-ing of protocols, where the rush to SSL-ify meant that the protocol got broken, rather than integrating SSL into the protocol itself. See draft-ietf-tls-http-upgrade-05.txt to see how this can be fixed. This is, of course, true, but doesn't really get us anywhere, since no browser supports it. Get to work. Add support for it in Mozilla. Microsoft will follow. No possible currently. The Mozilla security library not only doesn't compile it also has some crucial configuration files and headers missing. Its currently there just to give people a sneak preview. It isn't usable. Anyway, I imagine it would take _quite_ some work and they are other priorities. I realised after posting I had forgotten the smiley. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Please add UTF8STRING to PRINTABLE
Michael Sierchio wrote: "Rene G. Eberhard (keyon)" wrote: ...Unicode for example is suppored by Universal and UTF8. I also meant to point out that UTF-8 supports ASCII, but not EBCDIC, for example (not that I imagine that anyone would want to use the latter...;-) Well, we're getting out of the subject of the list, but after all everyone should have some clear ideas about internationalization. 2) UTF-8 supports the small subset of Unicode encodings that have 8 bit characters No. Every unicode character can be represented in UTF-8. UTF-8 is a transformation format for 16-bits unicode. A normal programm will choke on 16-bit unicode strings. Therefore it is transformed into UTF-8, so that it looks like a quite normal string with 8 bit caracters, and retransformed at the other end into Unicode. This should be handled transparently for the programm in the middle who does not need to know exactly what the string represents. In fact you can even represent some of the characters of 32-bits unicode, unavailable in 16-bits unicode, in UTF-8 . UTF-8 is becoming the standardized way of transporting internationalized strings, instead of using many different encodings, each specific to one or some countries. I also meant to point out that UTF-8 supports ASCII, but not EBCDIC, for example (not that I imagine that anyone would want to use the latter...;-) The way you present things seems to me confusing. UTF-8 "supports" everything, but there is a "direct" conversion for ASCII. In UTF-8, the characters that don't have the 8th bit rised directly represent their ASCII equivalent. So if you have a pure ASCII string (no eight bit character), it is also a valid UTF-8 string that represents the same characters. If the 8th bit is raised, then several characters must be composed to form one unicode character. The "good" point about utf-8 is that there is a simple rule to know the number of characters that must be composed, when you have the value of the first one, and if you jump inside the text, you can resynchronize at the beginnning of the next character. If you need to transfer EBCDIC using UTF-8, you need to convert it to unicode, then convert the unicode to UTF-8. You will do the opposite at the arrival. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PERL Module Problem...
Peter Gutmann wrote: Dr Stephen Henson [EMAIL PROTECTED] writes: Is there any circumstances where the environment isn't safe? I believe extra privs are normally needed to read another users processes environment. Under DEC Unixen you can read anyone's environment without any extra privs (ps -wwae or a variant thereof, depending on which vintage of OS you're on). There's the same possibility on Linux and probably many other OS. The program should overwrites it's sensible environment variables as soon as it has read the content, therefore strongly reducing the problem. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
