Re: [openssl.org #147] [PATCH] The function print_name in apps/apps.c truncates X509_NAM Es that are longer than 255 characters
> > Another problem with my code: the buffer I allocated wasn't freed... > Thanks to Peter Sylvester for pointing this out. I also moved the > allocation of the buffer to where it's actually used. > Well, to be complete, the code should also test for the results of alloc and realloc. On the other hand, if this really happens, there is probably already some other problem in the application or the system. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PKCS7_decrypt behavior
>
> i'm refering to this post i think it's better to write here
> there might be a memory leak in ./crypto/pkcs7/pk7_smime.c
> at the beginning i thought i was a fool, but i've seen that the same error was
> elsewhere in the code (thanks to Changes between 0.9.6h and 0.9.7).
>
> Geoff says :
>
> *) Fix a memory leak in 'sk_dup()' in the case reallocation fails. (Also
> tidy up some unnecessarily weird code in 'sk_new()').
> [Geoff, reported by Diego Tartara <[EMAIL PROTECTED]>]
Doesn't the same error occurs in other places, too, example:
KCS7_SIGNER_INFO *PKCS7_add_signature(PKCS7 *p7, X509 *x509, EVP_PKEY *pkey,
const EVP_MD *dgst)
{
PKCS7_SIGNER_INFO *si;
if ((si=PKCS7_SIGNER_INFO_new()) == NULL) goto err;
if (!PKCS7_SIGNER_INFO_set(si,x509,pkey,dgst)) goto err;
if (!PKCS7_add_signer(p7,si)) goto err;
return(si);
err:
/* si can still have a value ??? */
return(NULL);
}
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
XXX_DESCRYPT / ENCRYPT
Hi, is there a particular reason why in crypto/aes/aes.h the symbols AES8DESCRYPT and AES_ENCRYPT are defined as static const int AES_DECRYPT = 0; static const int AES_ENCRYPT = 1; and not simply as in des as #define DES_ENCRYPT 1 #define DES_DECRYPT 0 regards __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
-fPIC flag missing for asm/des_enc-sparc.
it seems that in the current snapshots the shared option for solaris does not work correctly. Compilation in crypto/des of gcc -c -o asm/des_enc-sparc.o asm/des_enc-sparc.S should probably be gcc -fPIC -c -o asm/des_enc-sparc.o asm/des_enc-sparc.S in order not to provoke a linker error. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: -fPIC flag missing for asm/des_enc-sparc.
Well, sorry for the message below. The result is the destest crashes. So, on solaris, trying the "no-asm shared", somehow now I get problems conpiling engines, ok trying no-engine since I don't have any. Why does engines insist to compile the engines with no-engine. evp/c_all_c.c does not compile, the program seems useless anyway, it just includes engine.h unconditionally. in store/str_lib.c also include engine.h and some "ec" routines also have that problem. So, let's try with no-ec in order to avoid changing too much. apps/ec.c tests OPENSSL_NO_EC which is not defined, only OPENSSL_NO_ECDSA and OPENSSL_NO_ECDH are defined. and then the OPENSSL_NO_ENGINE is also missing for apps. or in fact an #include in test/ecdhtest.c the include/ec.h needs to be inside an #ifndef OPENSSL_NO_ECDH test/enginetest.c should include opensslconf.h test/ssltest.c should include opensslconf.h besides that, it seems that one really needs to say make twice because some objects seems to be build in the wrong order. make install also wants to install the engines. doing make install a second time sh: /usr/local/ssl/man/man3/EVP_BytesToKey.3: cannot create hm a link to itself ? /usr/local/ssl/man/man3/EVP_BytesToKey.3 -> EVP_BytesToKey.3 enough for today. > > it seems that in the current snapshots the shared > option for solaris does not work correctly. > > Compilation in crypto/des of > >gcc -c -o asm/des_enc-sparc.o asm/des_enc-sparc.S > > should probably be > >gcc -fPIC -c -o asm/des_enc-sparc.o asm/des_enc-sparc.S > > in order not to provoke a linker error. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: -fPIC flag missing for asm/des_enc-sparc.
hi Ben, > > > > Why does engines insist to compile the engines with no-engine. > > We generally do this because we don't have a mechanism for conditionals > in Makefiles. > hm, pushing a model makefile through a C preprocessor? > > evp/c_all_c.c does not compile, the program > > seems useless anyway, it just includes engine.h unconditionally. > > All headers are included unconditionally - this is so we don't get > dependency flap between the developers. If engines are not defined, the engine.h does not like to be included since it has #ifdef OPENSSL_NO_ENGINE #error ENGINE is disabled. #endif is this intended? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #670] -fPIC flag missing for asm/des_enc-sparc.
> > Uhmm, which OpenSSL version are you talking about? I can't find > des_enc-sparc.S anywhere in my copy of the 0.9.7 branch... > > [EMAIL PROTECTED] - Tue Jul 29 17:06:13 2003]: > It is in the latest branch in crypto/des/asm (at least after make). It seems that my problem went away with an install of a newer gcc version or some other as... > > > > it seems that in the current snapshots the shared > > option for solaris does not work correctly. > > > > Compilation in crypto/des of > > > >gcc -c -o asm/des_enc-sparc.o asm/des_enc-sparc.S > > __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: X509v3 extensions (repost)
> > I've come across an issue with extensions. I have a S/MIME signed > message, where the signing cert has signing + encrypting Key Usage flags, > and SSL server Extended Key Usage flags. > > Because there is a Ext. Key Usage flags set, but not the S/MIME one then > the cert validation procedure fails, hence the signature verification fails. > > The Extended Key Usage flag is not marked as a critical extension, so in > theory it should pass OK. > > There are a number of reasons for this as far as I can tell. > > Firstly, within the function x509v3_cache_extensions() in > x509v3/v3_purp.c, the last bit of code checks for all extensions, looking > for any that are critical. Strangely it looks to me like only extensions > that are "critical and not supported" triggers the setting of the flags to > include EXFLAG_CRITICAL. Should that 'not' be in there? in X509 and RFC3280 "Critical" means that if you don't know how to handle an entension, you can ignore it. if you know how to handle it, you treat it independantly of critical or not. there was a defect report in X509 to have this interpretation changed, in older versions of 509 and PKIX there was indee a three state logic. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: X509v3 extensions
> > in X509 and RFC3280 "Critical" means that if you don't know how to handle an > entension, you can ignore it. if you know how to handle it, you treat it X > independantly of critical or not. I was mildly shaked to wake up : Obviously, I missed the half sentence at 'X': "if critical is not set". Or: - You know and extension ==> treat it - else, (you don't know it) and critical is NOT set, ignore it - else fail. In a previous version of X509 and of PKIX you had - If you don't know an extension and critical is not set, ignore - else if you don't know and crticila is set, fail; - else (you know) and critical ==> treatment A - else you know and non critical ==> treatmant B. - End Included Message - __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: X509v3 extensions (repost)
> > in X509 and RFC3280 "Critical" means that if you don't know how to handle an > entension, you can ignore it. if you know how to handle it, you treat it X > independantly of critical or not. I was mildly shaked to wake up : Obviously, I missed the half sentence at 'X': "if critical is not set". Or: - You know and extension ==> treat it - else, (you don't know it) and critical is NOT set, ignore it - else fail. In a previous version of X509 and of PKIX you had - If you don't know an extension and critical is not set, ignore - else if you don't know and crticila is set, fail; - else (you know) and critical ==> treatment A - else you know and non critical ==> treatmant B. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
progs.pl --> progs.h
hello,
it seems to me that the file progs.h in current versions (0.9.7d
and snapshot) had not been generated by progs.pl
The progs.h has an ifndef for OPENSSL_NO_ENGINE
which doesn't seem necessary to me if the two lines
elsif ( ($_ =~ /^ocsp$/))
{ print "#ifndef OPENSSL_NO_OCSP\n${str}#endif\n"; }
elsif ( ($_ =~ /^engine$/))
{ print "#ifndef OPENSSL_NO_ENGINE\n${str}#endif\n"; }
would be added in the second loop with @ARGV
Peter
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
new version for SRP-6/TLS available
Hi, ho: I just made available the second beta release of our patch for OpenSSL 0.9.7d implemeting the SRP6 TLS protocol. In addition, a first beta release of a patch for mod_ssl allowing to use the new protocol in an Apache Web Server is provided. More info and downloads are available here: http://www.edelweb.fr/EdelKey/ Regards. Peter Sylveter __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: new version for SRP-6/TLS available
-- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 56 > > I thought SRP6 was patented. Isn't SRP6 patented? Yes, here an excerpt from http://srp.stanford.edu/licence.txt SRP is royalty-free worldwide for commercial and non-commercial use. The SRP library has been carefully written not to depend on any encumbered algorithms, and it is distributed under a standard BSD-style Open Source license which is shown below. This license covers implementations based on the SRP library as well as independent implementations based on RFC 2945. The last sentence seems the key, > > Also, as pointed out by Steiner et al. [1] implementing SRP6 requires > modifying the hello messages and therefore compatibility with already > deployed openssl libraries is lost, isn't it? > > [1] Secure Password-Based Cipher Suite for TLS, M. Steiner, P. Buhler, > T. Eirich, and M. Waidner, ACM Transactions on Information and System > Security (TISSEC). > This text is from 2000 as far as I know, it may therefore be a little bit outdated in some respects, in particular, cannot cover the changes from SRP-3 to SRP-6. This article also says: "For compatibility reasons we should not alter messages which are sent before agreement on a cipher suite has been reached. This means in particular that we should refrain from modifying Clienthello." Excerpt from rfc2246 (jan 1999) Forward compatibility note: In the interests of forward compatibility, it is permitted for a client hello message to include extra data after the compression methods. This data must be included in the handshake hashes, but must otherwise be ignored. This is the only handshake message for which this is legal; for all other messages, the amount of data in the message must match the description of the message precisely. The modifications for SRP-6 are done using the proposed extensions technique for TLS 1.1. As far as I have tested, I can safely connect to any existing openssl library, and if I propose other ciphers than the SRP ones, they are selected. See also the GNU-TLS implementation which also includes SRP6. It's always good to have at least two independant implementations. If I am misusing this list, sorry. Peter -- X-Sun-Data-Type: html X-Sun-Encoding-Info: 7bit X-Sun-Charset: us-ascii X-Sun-Content-Lines: 44 Hi, I thought SRP6 was patented. Isn't SRP6 patented? Also, as pointed out by Steiner et al. [1] implementing SRP6 requires modifying the hello messages and therefore compatibility with already deployed openssl libraries is lost, isn't it? [1] Secure Password-Based Cipher Suite for TLS, M. Steiner, P. Buhler, T. Eirich, and M. Waidner, ACM Transactions on Information and System Security (TISSEC). Thanks, Olivier. I just made available the second beta release of our patch for OpenSSL 0.9.7d implemeting the SRP6 TLS protocol. In addition, a first beta release of a patch for mod_ssl allowing to use the new protocol in an Apache Web Server is provided. More info and downloads are available here: http://www.edelweb.fr/EdelKey/";>http://www.edelweb.fr/EdelKey/ Regards. Peter Sylveter __ OpenSSL Project http://www.openssl.org";>http://www.openssl.org Development Mailing List mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED] Automated List Manager mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: new version for SRP-6/TLS available
> > one problem seems to be a vague patent claim from Phoenix Technologies > see http://www.ietf.org/ietf/IPR/PHOENIX-SRP-RFC2945.txt > (or the same discussion on openssh-unix-dev > http://marc.theaimsgroup.com/?t=10914494173&r=1&w=2 ) > Right. There are two different issues: - what does Stanford allow according their patent - that seems sufficiently clear to me, they provide even a free implementation etc. - what someone else claim against them or someone else. - The religious debate among the entities about two years ago is fun. One may be tempted to regard this as an US-centric oligarchistic approach to keep control on technology. Everybody except the patent holders are afraid to do anything? Nice approach. (i.e. a conspiration among the three parties). - Some patent holders have already waited more than 10% of the lifetime of their patent in 'investigations', let them continue the other 90%. OpenSSL contained and contains patented algorithms, you may or may not enable it. Anyway, the next version of our mods will contain some more detailed information about the patent issue. Peter __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: X509_verify_cert(): verify with time and CRL
The following point is unclear to me: >>a) CRL is valid (regarding issuance time) >> if thisUpdate >= checkTime and thisUpdate <= now. As far as I understand; The X509 and 3280 validation algorithm only have ONE point in time, which is consider either as 'now' or 'time to check' according you personal taste. Either the machine implmenting the algo has a local clock, so it initializes the time to check to it, or you give it to the algo from some other source. Thus, using the current time, as well as the check time cannot correspond to anything defined, or X509_cmp_time(X509_CRL_get_lastUpdate(crl), NULL) looks problematic to me. I don't understand: thisUpdate >= checkTime Isn't this the other way around? A CRL is valid when the time to check is between thisupdate and nextupdate? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: win32 installation issue...
Did you 'perform' ...\Bin/Vcvars32.bat ? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: HTTP POST with SSL
> > Karl, > > I written following code for HTTP POST with SSL, but it is not working can > you tell me why? > I am not getting any response from web server. > > POST /cgi-bin/cs_intf/validate.exe HTTP/1.1 > Content-type: text/html > Content-length: 31 > agentname=tiw&pin=9443243 > > where validate.exe is cgi script. > > Thanks. > Brajesh > You might want to try this: (each line ended by \r\n) note the empty line POST /cgi-bin/cs_intf/validate.exe HTTP/1.0 Content-type: text/html Content-length: 25 agentname=tiw&pin=9443243 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Timestamping service
> > Hi, > > We have developed an experimental Timestamping service based entirely on SMIME. > It includes a timestamping service of web objects, that perhaps someone will find >useful. > > Main URL: http://ca.nisu.org/ > Timestamp URL: http://ca.nisu.org/TE/ > I had mentioned in a small presentation at the Adelaide IETF PKIX meeting, EdelWeb has developped a demonstrator time stamping service for the French postal service La Poste. We have not use the timestamping draft as a protocol but dvcs for several reasons: - It was desirable to have the possibility of a staged service with value adding services that are beyond a 'pure' time stamping, in order to study possible business cases, e.g., adding the identity of a requester and/or an URL pointing to a document which results in a single certificate indicating who has published what and when. - it was desirable to have a feature where the requester can sign the request in order to handle a client/provider contract, i.e. a SIMPLE way to keep long term traces of requests. - Though not implemented in the win32 client, it was desirabale to have a common protocol that not only allows to obtain a time stamp, but also to verify its validity on line, i.e. doing more than just verifying the signature of the token. - The time to produce a working solution was short, a client and server has been specified, developed, and tested within less than 5 weeks. The latest version of the time stamping protocol had important syntactical changes. Besides a object id conflict this was not the case for dvcs. Anyway, using whatever token/certificate/request format (below SignedData) is not exactly an important problem. - It didn't seem a nice idea to already define extensions to a protocol in order to implement the value adding features. The development is based on the openssl crypto library, we used a slightly enhanced version of the valicert asn1 compiler to produce the dvcs coding and encoding rules. The coder/decoder, some simple server, as well as a line mode client will be made available as public domain contribution to openssl. Peter Sylvester http://clepsydre.edelweb.fr/attestation.html __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: A "-dn xxx" flag for the req command?
> > [EMAIL PROTECTED] wrote: > > > > Has anyone added a "-dn" flag to the req command? This would make it much > > easier to write scripts that generate lots of requests. (Okay, maybe > > not a lot easier, since I could set up a config file that pointed to the > > environment, and then set env-vars, but that's a little roundabout...) > > The alternative if to write out a 'template' config file for each > request, using the right options this will create a request without > prompting for anything. There is an example of how to do this in the > 'req' manual page. > And you can add environment variable names in that 'template', for example: extensions = x509v3 [ req ] default_bits= 1024 distinguished_name = req_DN [ req_DN ] countryName = "Country Name" countryName_value = $ENV::CERT_COUNTRY localityName= "Locality Name" localityName_value = $ENV::CERT_LOCALITY organizationName= "Organisation" organizationName_value = $ENV::CERT_ORG commonName = "Common Name" commonName_value= $ENV::CERT_CN [ x509v3 ] subjectAltName=$ENV::CERT_EMAIL __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Several issues concerning ASN1 in OpenSSL
> > In 1, if i2d_ASN1_OBJECT's second argument is 0 (or NULL), ASN1_object_size > returns the complete length of the object identifier including: > > identifier octets > length octets > content octets > > This is good. > > If i2d_ASN1_OBJECT's second argument is not 0, only the length of the > content octets is returned. This is bad. In most cases the difference will > be two, but not necessarily. > > Unfortunately, I do not have a fix, yet. What is bad here? The pointer is updated to the end of the buffer. If you want to get access to the content, subtract the result of the put, if you want to access the whole element, make a pointer before calling put. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Several issues concerning ASN1 in OpenSSL
> > It is my understanding that an i2d function should return the length of the > identifier, length and content octets, and that in the case described below > i2d_ASN1_OBJECT did not. That's all. > > Based on Steve's message (which I read after sending my message), this has > been fixed. > Right, it seems that the other functions behave like that. Anyway this reminds me to some functionality that I have seen some tern years ago other asn1 implementations: The equivalent of the length function actually does not get the correct encoding but just make an estimation, giving 5 length octets or other hints for integers for example. This allows for a faster code especially when lot's of structures are involved. Note that the actual put routines do the length stuff twice. The implemenation was beating xdr encoders by a factor of almost 2. I also remember another encoder that encoding in an inverted way from the end of the buffer after estimation of the length. No performance figures here. Well, just some thoughts. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Several issues concerning ASN1 in OpenSSL
> Yes thats something I'm considering for the ASN1 revision. Something > like saving the lengths when the length is calculated and then using > them when the stuff is written out. Maybe one could cache the length in the ASN1 object. As long as any object is only used once, this might work. > > However that's currently tricky because you'd have to add something like > a 'ASN1_CTX' parameter with the cached lengths somewhere. Painful with > the current spaghetti ASN1. Much easier when it all goes through a > common routine. Yes, openssl was probably not thought as a general asn1 tool anyway, but it isn't that bad. If one decides the object structure, it might be useful to add a flag to whether the data should be freed when free is called, this would also avoid copying larger string buffers in some cases, especially when they could be static somewhere. > > > I also remember another encoder that encoding in an inverted way > > from the end of the buffer after estimation of the length. No > > performance figures here. > > > > Yes I believe SNACC does that? The only difficulty with that is it makes > in much harder to write the encoded ASN1 to a stream if you use > indefinite length encoding. If you write BER, you don't have exactly the same problems as with DER. btw: That wasn't snacc, that was some code written in pascal about 15 years ago. Not one that was publicly available as far as I know unless Manfred corrects me. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Several issues concerning ASN1 in OpenSSL
> > I'm thinking more in terms of a CTX parameter passed to a different API. > The problem with many caching ideas and the current ASN1 library is that > things could be modified and the cache have no way of determining that > it is now invalid. Some parts are modified using a structured API > whereas others by directly accessing structures. Right, if one assumes that one can create structures i2d them, and then add/remove parts of them, i2d them, etc, then all this may get difficult. > > Oh believe me it is bad. The deeper you look into it the worse it > gets... Ok, I propose historically grown and fortunately not functionally stabilized. :-) > > > If one decides the object structure, it might be useful to add a flag to > > whether the data should be freed when free is called, this would also > > avoid copying larger string buffers in some cases, especially > > when they could be static somewhere. > > > > Yes something like that exists with ASN1_OBJECT. It could be added to > ASN1_STRING as well. As much elements as possible. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
pkcs7 content type
I would like to suggest a change in the handling of pkcs7 content types in asn1/p7_lib.c and in pkcs7/pk7_lib.c There are a few occurences of lines: case NID_pkcs7_data: It would be nice to have added here the smime content-type Nids, too, or, to just change the default case to do the same as the data case. A possible solution would be to replace the four lines by a macro defined in pkcs7.h in order to simplify maintenance. Thanks in advance for considering this. PS. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: pkcs7 content type (bis)
Sorry for my last message, I haven't looked in the latest snapshot. The code in asn1/p7_lib.c seems fine to me. It seems that a similar code in pkcs7/pk7_lib.c in the pkcs7_set_content is not absolutely necessary, one can always start with data, and set it later, although this is somewhat a hack. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Convert ASN1_UTCTIME to time_t ?
> Are there any OpenSSL function to convert an ASN1_UTCTIME to a time_t (or a
> string for that matter)?
Somewhere in the following you'll find what you want :
time_t TSPX_GENERALIZEDTIME_print(BIO *bp, ASN1_GENERALIZEDTIME *tm,int gmt) {
unsigned char strtime[30] ;
time_t test = (time_t) 0; int i ;
if (tm->length != 15) return (time_t)-1;
for (i = ( sizeof(time_t)*8-2) ; i>=0; i--) {
test += (time_t)(1 << i) ;
strftime(strtime, 16, "%Y%m%d%H%M%SZ",gmtime(&test));
if (strncmp(tm->data,strtime,15) < 0)
test -= (time_t)(1 << i) ;
}
if (bp) {
strftime(strtime, 30, "%d-%b-%Y %H:%M:%S",localtime(&test));
BIO_printf(bp,"%s",strtime) ;
if (gmt) {
BIO_puts(bp," (");
i = ASN1_GENERALIZEDTIME_print(bp, tm) ;
BIO_puts(bp,")");
}
}
return test;
}
>
> Also... what about converting an ASN1_INTEGER to a standard 'int'?
>
what about
long ASN1_INTEGER_get(ASN1_INTEGER *a)
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Convert ASN1_UTCTIME to time_t ?
> > time_t TSPX_GENERALIZEDTIME_print(BIO *bp, ASN1_GENERALIZEDTIME *tm,int gmt) {
> ...
> > if (strncmp(tm->data,strtime,15) < 0)
> > test -= (time_t)(1 << i) ;
>
> This is curious code. It is trying to treat the TIME datatype as
> opaque, but then it looks directly at the data field. :) Why not just
> look at the data field, understand the decoding, and crack it open
> directly? I.e., look at ASN1_GENERALIZEDTIME_set() and
> ASN1_UTCTIME_set().
The code isn't quite correct if tm->data has subseconds, or time zones,
this should be normalized before making the tests.
But why should one bother to understand the correct details of strftime
to calculate the inverse function. Just making a binary search through
the possible values avoids some errors.
>
> it would be nicer if Dr. Henson wrote ASN1_TIME_to_time_t, tho. :)
> But see below.
>
> >long ASN1_INTEGER_get(ASN1_INTEGER *a)
>
> The problem is that this fails if the number can't fit into a long. (For
> example, a CA which puts a 128bit UUID/GUID as the certificate serial
> number.) And there's no clean way to tell (a bit ugly, indeed:). The
> ASN_TIME_get function could have the same problem, since a four-digit
> year could easily exceed the common 32bit implementation of time_t ...
There is always this conflict, these routines are too be
used when the range of the integer is small, for things like serialnumbers,
one would just use the octet representation anyway.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
a patch to cache some additional key usages
Hello, Would it be possible to add the following modification to x509v3. it adds two definitions of stacks used in some areas of pkix modules and it caches three extended key usages. Thanks in advance to the friendly maintainers. Peter Sylvester diff -c openssl-SNAP-2829/crypto/x509v3/x509v3.h openssl/crypto/x509v3/x509v3.h *** openssl-SNAP-2829/crypto/x509v3/x509v3.hSat Jun 17 02:01:30 2000 --- openssl/crypto/x509v3/x509v3.h Mon Aug 28 14:55:54 2000 *** *** 257,262 --- 257,265 DECLARE_STACK_OF(POLICYINFO) DECLARE_ASN1_SET_OF(POLICYINFO) + #define GENERAL_NAMES STACK_OF(GENERAL_NAME) + #define CERTIFICATEPOLICIES STACK_OF(POLICYINFO) + #define X509V3_conf_err(val) ERR_add_error_data(6, "section:", val->section, \ ",name:", val->name, ",value:", val->value); *** *** 326,331 --- 329,337 #define XKU_SMIME 0x4 #define XKU_CODE_SIGN 0x8 #define XKU_SGC 0x10 + #define XKU_OCSP_SIGN 0x20 + #define XKU_TSP_SIGN 0x40 + #define XKU_DVCS_SIGN 0x80 #define X509_PURPOSE_DYNAMIC 0x1 #define X509_PURPOSE_DYNAMIC_NAME 0x2 diff -c openssl-SNAP-2829/crypto/x509v3/v3_purp.c openssl/crypto/x509v3/v3_purp.c *** openssl-SNAP-2829/crypto/x509v3/v3_purp.c Fri Jun 2 01:01:00 2000 --- openssl/crypto/x509v3/v3_purp.c Mon Aug 28 14:48:13 2000 *** *** 317,322 --- 317,334 case NID_ms_sgc: case NID_ns_sgc: x->ex_xkusage |= XKU_SGC; + break ; + + case NID_OCSP_sign: + x->ex_xkusage |= XKU_OCSP_SIGN; + break ; + + case NID_time_stamp: + x->ex_xkusage |= XKU_TSP_SIGN; + break ; + + case NID_dvcs: + x->ex_xkusage |= XKU_DVCS_SIGN; } } sk_ASN1_OBJECT_pop_free(extusage, ASN1_OBJECT_free); __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
a_enum.c
For those who wonder why ENUMERATED are not encoded correctly
since a week or so: The put_object should use len as a parameter.
diff -c openssl-SNAP-2829/crypto/asn1/a_enum.c openssl/crypto/asn1/a_enum.c
*** openssl-SNAP-2829/crypto/asn1/a_enum.c Tue Aug 22 19:00:14 2000
--- openssl/crypto/asn1/a_enum.cMon Aug 28 19:04:48 2000
***
*** 79,85
len = i2c_ASN1_INTEGER(a, NULL);
ret=ASN1_object_size(0,len,V_ASN1_ENUMERATED);
if(pp) {
! ASN1_put_object(pp,0,ret,V_ASN1_ENUMERATED,V_ASN1_UNIVERSAL);
i2c_ASN1_INTEGER(a, pp);
}
return ret;
--- 79,85
len = i2c_ASN1_INTEGER(a, NULL);
ret=ASN1_object_size(0,len,V_ASN1_ENUMERATED);
if(pp) {
! ASN1_put_object(pp,0,len,V_ASN1_ENUMERATED,V_ASN1_UNIVERSAL);
i2c_ASN1_INTEGER(a, pp);
}
return ret;
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
bug report
In crypto/bio/b_print.c there is MS_STATIC char hugebuf[1024*2]; /* 10k in one chunk is the limit */ 2024*2 is not exactly close to 10k. Some months ago I reported some bug in the BIO_write vs BIO_puts processing. Most implementions of BIO_puts just call the internal _write routines with a strlen as additional parameter. Exceptions are bf_buff.c and b_dump.c where instead the BIO_write routines are called. This creates an inconsistent behaviour concerning the number of octets written, since the BIO_puts doesn't update the data in the same way as BIO_write. PS __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1181] [PATCH] adds RFC 3280 compatible mail attribute
One of the reasons that I see that some "USERS", i.e. relying parties want that, is that it is a bit difficult to get the subject altname email in a CGI under apache, whilst the DN attribute is simply in an environment variable. What happens when you add multiple emails, is either as subject altname or multiple occurence of the email attribute, .well, that's anoher story Michael Bell via RT wrote: Stephen Henson via RT wrote: That isn't what RFC3280 says: Conforming implementations generating new certificates with electronic mail addresses MUST use the rfc822Name in the subject alternative name field (section 4.2.1.7) to describe such identities. This isn't a DN component at all but part of an extension. This functionality is already supported in OpenSSL. Ups, you are correct. Nevertheless get_email should also scan for normal mail and not only for emailAddress. Additionally inetOrgPerson includes rfc822Mailbox and does not use emailAddress. So more generally should mail or emailAddress be used in the subject (I know this is deprected by RFC 3280 but many users want it)? Should I modify my patch with another comment? I still think that NID_rfc822Mailbox should be searched in X509_NAME. Michael -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. smime.p7s Description: S/MIME Cryptographic Signature
s_server 0.9.8
It seems to me that the behaviour of the s_server has changed in 0.9.8
concerning the interpretation of the nocert parameter.
When nocert is specified or when no appropriate alga was
compiled with, the variables for the key/cert file names were set to
NULL loading the files before any attempt was made to load them.
In 0.9.8 there is ney code to initialize the primary and secondary key
files which is added before the nocert treatment, thus it is
impossible to run with the -nocert option.
IMO the code to initialize the files should be replaced BEHIND the
nocert treatment and modified along the following lines:
current is like:
s_key = load_key( ...)
if (!skey) {
error ..
}
and should be IMO
if (!nocert && !(skey = load( ..))) {
error
}
similar for the s-cert file.
I can provide a patch if my analysis is correct.
regards
Peter
--
To verify the signature, see http://edelpki.edelweb.fr/
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
smime.p7s
Description: S/MIME Cryptographic Signature
s23_srvr.c
In s23_srvr.c there is a length test
if ((csl+sil+cl+11) != s->packet_length)
{
SSLerr(SSL_F_GET_CLIENT_HELLO,SSL_R_RECORD_LENGTH_MISMATCH)
in case that the record contains a SSLV3 or TLSv1 header.
IMO the != should be a > since tls allows additional
data in extensions.
Peter
smime.p7s
Description: S/MIME Cryptographic Signature
question concerning SSL_ctrl and SSL_CTX_ctrl etc
Dear core developpers, In ssl/ssl_lib.c there is a lot of functionality of get/set implemented through a SSL_ctrl or SSL_CTX_ctrl, but some are implemented directly as functions. There may be some logic behind that but I am not sure which one. One thing seems to be that the get function which need a pointer are implemented directly whilst some functions that return integers are in a ctrl. There is for example the GET/SET READ_AHEAD in a ctrl returning an int, but all all set/get_verify_mode etc are all as independant functions, and, well, there is an void SSL_set_read_ahead which duplicates the functionality. It seems that there had been an effort to move accessors to the SSL_ctrl and SSL_CTX_ctrl, since in older versions the SSL_ctrl was basically empty and just an interface to the method dependant code. There is also the GET_SESSION_REUSED which is common to the v2 and v3, thus could be moved to ssl_lib.c It may be that some stuff is left there to maintain compatibility, i.e., the explicit functions like SSL_set_read_ahead It would be nice to have a kind roadmap somewhere (which may already exist) to indicate whether the xxx_ctrl are 'the future' or not, and if yes, how to provide the 'get' functions for structures like (SSL_get_ctx). The reason why I ask this is that in some provided patches (like ours for tls extensions and SRP) or the PSK from Nokia), there are some more or less strange ways to add new functionality. Thanks in advance for any illuminating remark. Peter -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. smime.p7s Description: S/MIME Cryptographic Signature
Re: TLS Extension support - Server Name Indication
Dear OpenSSL developpers, I have put a version of openssl that supports the TLS servername extension into our web server. It is based on a openssl development snapshot of last week. We have split of and simplified the code that was done together with SRP last year, an,d corrected known bugs. See http://www.edelweb.fr/EdelKey/files/openssl-0.9.8+SERVERNAME.tar.gz see also http://www.edelweb.fr/EdelKey/ The snapshot was one day before the 0.9.8a announcement, I think it contains the recent vulerability patch. I invite the core developers to take a look on it: basically s_client and s_server have been slighlty enhanced and in "ssl" there the modules that have OPENSSL_NO_TLSEXT contain the new functionality. In the s23_lib.c it is possible to have anounce a TLS extension and to "ignore it" on the server side as with s3_lib. There is one functionality which is not necessary to support the servername extension, but only to allow a renegotiation of a session using another servername, e;g. when a web server received a "Host: " This is not yet fully tested, and I am not sure whether the implemenation is good. The idea is to switch the ssl->ctx point to another context. The reference counting for the ctx is simple, but during an SSL_new there is some data "cached" down into the SSL, and, in particular the interesting one, the server's certificate. It may not be necessary to switch the actual CTX, but rather change the SSL to cache from the "other" CTX. regards and thanks for looking at it; sorry for the lengthly message. Peter Cesc wrote: Hi, While discussing the proper implementation for TLS support for (open)ser SIP proxy (currently using OpenSSL), we came up with somehow a showstopper: when the server serves multiple domains, we'd like to present a different certificate depending on which domain the incoming message is directed to. The option of using a different port per domain is an option, but not the best one. So, my question is, does openssl implement TLS extensions, as defined in RFC 3546, specially section "3.1 - server name identification"? This way, the tls client establishing the tls connection could announce the proxy it is connecting to, thus solving all the multi-domain problems. We heard that it is there in gnutls, what about openssl? And, now that i started, what TLS Extensions does openssl support? Regards, Cesc -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. smime.p7s Description: S/MIME Cryptographic Signature
Re: s23_srvr.c
Bodo Moeller wrote:
On Fri, Oct 07, 2005 at 11:17:47AM +0200, Peter Sylvester wrote:
In s23_srvr.c there is a length test
if ((csl+sil+cl+11) != s->packet_length)
{
SSLerr(SSL_F_GET_CLIENT_HELLO,SSL_R_RECORD_LENGTH_MISMATCH)
in case that the record contains a SSLV3 or TLSv1 header.
IMO the != should be a > since tls allows additional
data in extensions.
This length test occurs in the branch of ssl23_get_client_hello() that
is responsible for parsing a Client Hello sent in SSL 2.0 backwards
compatible format (where s23_srvr.c has to translate from SSL 2.0 into
SSL 3.0/TLS 1.0 format so that s3_srvr.c can continue processing the
handshake). Backwards compatible Client Hello messages can't include
additional data because this would confuse SSL 2.0 servers, they
strictly follow the format
char MSG-CLIENT-HELLO
char CLIENT-VERSION-MSB
char CLIENT-VERSION-LSB
char CIPHER-SPECS-LENGTH-MSB
char CIPHER-SPECS-LENGTH-LSB
char SESSION-ID-LENGTH-MSB
char SESSION-ID-LENGTH-LSB
char CHALLENGE-LENGTH-MSB
char CHALLENGE-LENGTH-LSB
char CIPHER-SPECS-DATA[(MSB<<8)|LSB]
char SESSION-ID-DATA[(MSB<<8)|LSB]
char CHALLENGE-DATA[(MSB<<8)|LSB]
after the two-byte record header. I.e., a client that connects to a
server can *either* support SSL 2.0 servers *or* use TLS extensions,
but not both.
The SSL 3.0 and TLS 1.0 specifications have the forward compatibility
note about extra data at the end of the Client Hello, so s23_srvr.c
should tolerate always extra data in a Client Hello that does not use
the SSL 2.0 format.
A client that fills extra data into the compatible data must indeed
be prepared that a strict v2 server rejects the client hello, and repeat
with a correct one. Here we are taling about the server mode.
Would it hurt Openssl to be a tolerant server, and ignore the additional
in v2 mode, because that doesn't hurt as far as I understand.
Anyway, a little bit later, i.e. after the handling of compression one
has to copy the
remaining data, i.e to add something like
p = p+csl+sil+c1;
while (p < s->packet+s->packet_length) {
*(d++) = * (p++);
}
just before setting the length of the emulated s3/t1 packet.
I
--
To verify the signature, see http://edelpki.edelweb.fr/
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: s23_srvr.c
Bodo Moeller wrote: On Mon, Oct 24, 2005 at 04:08:19PM +0200, Peter Sylvester wrote: [...] I.e., a client that connects to a server can *either* support SSL 2.0 servers *or* use TLS extensions, but not both. The SSL 3.0 and TLS 1.0 specifications have the forward compatibility note about extra data at the end of the Client Hello, so s23_srvr.c should tolerate always extra data in a Client Hello that does not use the SSL 2.0 format. A client that fills extra data into the compatible data must indeed be prepared that a strict v2 server rejects the client hello, and repeat with a correct one. Here we are taling about the server mode. Would it hurt Openssl to be a tolerant server, and ignore the additional in v2 mode, because that doesn't hurt as far as I understand. Hm. Probably being this liberal wouldn't actually hurt, but I don't see a good case for doing this -- it helps only with ill-behaving clients. I think its better to fix the latter (should they exist) and to generally encourage implementors to step away from 2.0-compatibility. Accepting this new extended 2.0 format might perpetuate a data format that is already obsolete. I agree, I'll leave this out for the servername patch. -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. smime.p7s Description: S/MIME Cryptographic Signature
time_t remarks
I saw in the lastest snapshots that in the ssl library the fundction time has been casted to an unsigned long. This seems to be some hack to cover the 2038 problem on 32 bit machines. I am not sure whether the attempted solution is good: As far as I see the only usage is to determine whether a timeout has occured. How much can a session last? More than 20 years? If not, I think one should define a notion of epoch which covers the problem that it seems to be undefined whether in 2038 the value goes to 0 or to a large negative value depending on the implementation. I.e. the time is also initialized with time(NULL)|x3fff and in ssl_sess.c if (ret->time+ter->timeout < (time(NULL) | x7fff) and similar in ssl_bio etc. Comments? Peter -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. smime.p7s Description: S/MIME Cryptographic Signature
__attribute__
in util/mkerr.pl there is a loop that replaces __attribute__. in crypto/bio/bio.h a recent change created an infinite loop there. replacing the __attribute_ by __bio_h_attr__ in mkerr.pl fixes it. -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. smime.p7s Description: S/MIME Cryptographic Signature
Re: Attribute order in name comparison
Some openssl does not necessarily display DNs in the same textual order as other tools or as other tools like it as input. try openssl x509 -in yourcert -text -noout -nameopt RFC2253 for example and another without the -nameopt parameter It has happened several times that people create certificates that have the order of the attributes reversed. The only remedy was to remake the PKI since we live with the historical accident of mixing a hierarchy together with typed attributes in x.500, specifying the order means that one attribute is a subordinate of the preceding one. I don't think that common name is a very good candidate for a top level attribute unless for CN=the universal authority or else Or; C=DE/O=Org/CN=Alice and the other way around is not a clear description of the data. what does openssl X509 show? Peter Lev Walkin wrote: Robert Eiglmaier wrote: Hi, I have troubles verifying a PKCS#7 signedMessage because the order of the DN attributes in the signerInfo is different from the order in the certificate. i. e. The cert contains: C=DE/O=Org/CN=Alice The signer info has: CN=Alice/O=Org/C=DE I found that the function int X509_NAME_cmp(const X509_NAME *a, const X509_NAME *b) will only find the names matching if the attribute order is identical. It wouldn't be a big deal to make X509_NAME_cmp() more tolerant, but since appearantly nobody has had such a problem yet I'd like to know if there is a specification somewhere that says something like "Thou shalt not turn around the order of thy name attributes". PKIX1 profile for X.509 certificates, as well as X.680 for ASN.1 SEQUENCE. All I found was a statement, that SEQUENCE OF is ordered. (distinguishedName is a SEQUENCE OF nameAttribute) But when I look at an example Certificate I can't see by what it is being ordered here: SEQUENCE ^^ this is a "SEQUENCE OF", not "SEQUENCE" SET SEQUENCE OBJECT :countryName 2.5.4.6 PRINTABLESTRING :DE SET SEQUENCE OBJECT :organizationName 2.5.4.10 PRINTABLESTRING :Company SET SEQUENCE OBJECT :commonName 2.5.4.3 PRINTABLESTRING :Demo CA Can anyone bring some light into the darkness? They are ordered sequence of unordered SET's of each element. The order inside "SET OF" is not important, but there is exactly one element in each SET OF. However, the order inside "SEQUENCE OF" is important. And the order is the order of display, i.e. DE/Company/Demo CA. -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. smime.p7s Description: S/MIME Cryptographic Signature
Re: ASN1_INTEGER <==> int
The reverse may not be true in real life. One way this comparison might
bite you is when the issue issues certificate with encoding violating
the DER requirements. For example, the ASN1_INTEGERs with octet
encodings "02" and "00 02" contain the same value 2, but these encodings
will in fact be different if you compare them with memcmp.
The latter ("00 02") is incorrect encoding, violating DER.
It violates even BER as far as I remember Since X.409 1984 the text says:
The value of the integer shall be encoded in the fewest possible octets
the first (most significant) 9 bits shall not all be ones or zeros.
You might as well disregard such certificate as non-compliant.
--
To verify the signature, see http://edelpki.edelweb.fr/
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [openssl.org #1276] [PATCH] TLS Extensions - RFC 3546 (Try 2)
Hello, Since I was pretty active in providing the current code, here are some of our thoughts which may or may not be compatible with the core team. In 2004, we had developped some extensions for the 0.9.7d version concerning servername and srp. We initially also had the idea and a logic where one could try to have a very generic extension mechanism. The problem is that extensions may require modification of the internal states of openssl, or at least have to interfere with it in some cases. Or, in other words, extension doesn't mean that either all extensions are logically equivalent because they are indicated with some number in the hellos, some are extensions of the protocol which may be done with almost no interaction with the application. Example, treating the maximum packet size. It would mean that an application would call a SSL_set_hello_extension to set the value of the extension. Well, ok, but then openssl has to check first, whether it needs additional logic to support the required extension in any way, but how can it know this? I also have the feeling that applications don't really want to understand how the ssl protocols happens, and neither how encodings are done, but rather just interfere as either providing parameters or being called at an appropriate instance. To me it seems too low level to allow applications to interfere with the protocol data, I'd prefer an API for some abstract service with set/get functions and callbacks, i.e., following exactly the same logic as with 'normal/standard' features. Thus, each "extension" is independant and needs support code. What has been attempted in the current snapshot is to concentrate the encoding/decoding stuff in one place where the appropriate encoding/decoding would be added for new extensions, and then, add the required logic where it has to be added. The global compile option of whether tls extensions are supported may not really be necessary unless one really has a small footprint problem. Well, this is my current state of thinking, the code in the devel snapshot is experimental, and the core team may change it at any time. Am I right that your current patch only provides a callback for ONE extension? Regards Peter Jouni Malinen wrote: On Tue, Jan 31, 2006 at 09:00:04PM +0100, Dr. Stephen Henson wrote: As has happened previously the functionality in the HEAD is not set in stone and may be subject to change. I'm aware of the 0.9.9 TLS extension efforts but I'm not currently actively involved with them. I have a shed load of other things to do. It looks like the current implementation is going more towards adding each TLS extension as a separate implementation whereas the patch that wpa_supplicant is using for EAP-FAST support has a more generic mechanism that allows arbitrary TLS extensions to be added to ClientHello without having to modify OpenSSL for each new type. Current CVS HEAD includes support for servername and host_name extensions. EAP-FAST is using PAC-Opaque extension, so it would need additional code to add that into the ClientHello. This would likely be something similar to the way setting host_name extension is done. Before starting to port the patch I've used with OpenSSL 0.9.8 to 0.9.9, I would like to get a better understanding on the desired design for TLS extensions and to find out whether someone else is working on implementing additional extensions at the moment. Is the current design of separate implementation without generic support for arbitrary extensions the preferred way of doing this (i.e., is it likely to remain in 0.9.9)? CHANGES file is marking most of the TLS extension code with "subject to change". If separate implementation is desired, it would probably be a combination of adding the PAC-Opaque extension (a.k.a. SessionTicket TLS extension) and taking care of a callback for fetching pre-shared secret for session resumption. -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. smime.p7s Description: S/MIME Cryptographic Signature
Re: [openssl.org #1276] [PATCH] TLS Extensions - RFC 3546 (Try 2)
Kyle Hamilton wrote: I'd like to see a generic callback mechanism in that I want to be able to write my own dispatcher for TLS extensions. You already have this, you can intercept all messages. -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. smime.p7s Description: S/MIME Cryptographic Signature
servername extension and apache 2.2.0
Hello, I just have put together the small patch for apache 2.2.0 which allows to use the sernername extension logic in the development snapshot in order to select a different ssl context, and also to renegotiate if the vhost indicated by Host: has a different SSL_ctx (e.g. certificate). The patch also includes a little "const" fix due the SSL_method change. See http://www.edelweb.fr/EdelKey/files/apache-2.2.0+0.9.9+servername.patch and http://www.edelweb.fr/EdelKey/ for the background story Have fun Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: servername extension and apache 2.2.0
The version of this patch is not one hour old. The development snapshot is related to openssl which is also only there since a few weeks. The patch was done to validate that the openssl servername extension code can be easily used in an application. Both development teams may have opinions about the API. Oden Eriksson wrote: måndagen den 6 februari 2006 18.13 skrev Peter Sylvester: Hello, I just have put together the small patch for apache 2.2.0 which allows to use the sernername extension logic in the development snapshot in order to select a different ssl context, and also to renegotiate if the vhost indicated by Host: has a different SSL_ctx (e.g. certificate). The patch also includes a little "const" fix due the SSL_method change. See http://www.edelweb.fr/EdelKey/files/apache-2.2.0+0.9.9+servername.patch and http://www.edelweb.fr/EdelKey/ for the background story It hasn't been accepted upstream? -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. smime.p7s Description: S/MIME Cryptographic Signature
Re: servername extension and apache 2.2.0
William A. Rowe, Jr. wrote: If you want to submit and have considered by the httpd project, perhaps you ment to submit it there? Not yet. Since the corresponding openssl code is still in the development branch, and not in a stable one. The apache2 patch was done to see whether the api is good, or, an attempt to motivate the openssl developpers to regard whether the openssl API is something that needs to be changed or not, whether it is missing some functionality or else whenever they have time. :-) Nice work b.t.w. Thanks. smime.p7s Description: S/MIME Cryptographic Signature
Re: pkcs12_parse problem
You ask for two things: - creation of a file: Just put all the certs together in pem format starting with the entity cert, and use this as -in parameter. - parsing: There can be multiple chains. You have to find one yourself in the CA list that goes up to a desired trust anchor and through intermediate certs, etc. One possibility is to load all acceptable ca certs from the ca list into a store and then verify the ee cert. This builds a chain. Jean-Marc Desperrier wrote: 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] -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. smime.p7s Description: S/MIME Cryptographic Signature
A little patch for ssl.h comments
A little bit of nit picking, but since a comment is supposed to be
correct. :-)
--
To verify the signature, see http://edelpki.edelweb.fr/
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
--- openssl-SNAP-20060312/ssl/ssl.h 2006-03-12 01:00:45.0 +0100
+++ openssl-SNAP-20060312+S/ssl/ssl.h 2006-03-12 17:54:54.422132000 +0100
@@ -430,18 +430,20 @@ typedef struct ssl_method_st
* SSL_SESSION_ID ::= SEQUENCE {
* version INTEGER, -- structure version number
* SSLversion INTEGER, -- SSL version number
- * Cipher OCTET_STRING, -- the 3 byte cipher ID
- * Session_ID OCTET_STRING, -- the Session ID
- * Master_key OCTET_STRING, -- the master key
- * KRB5_principal OCTET_STRING -- optional Kerberos principal
- * Key_Arg [ 0 ] IMPLICIT OCTET_STRING, -- the optional Key argument
+ * Cipher OCTET STRING, -- the 3 byte cipher ID
+ * Session_ID OCTET STRING, -- the Session ID
+ * Master_key OCTET STRING, -- the master key
+ * KRB5_principal OCTET STRING -- optional Kerberos principal
+ * Key_Arg [ 0 ] IMPLICIT OCTET STRING, -- the optional Key argument
* Time [ 1 ] EXPLICIT INTEGER, -- optional Start Time
* Timeout [ 2 ] EXPLICIT INTEGER, -- optional Timeout ins seconds
* Peer [ 3 ] EXPLICIT X509, -- optional Peer Certificate
- * Session_ID_context [ 4 ] EXPLICIT OCTET_STRING, -- the Session ID context
+ * Session_ID_context [ 4 ] EXPLICIT OCTET STRING, -- the Session ID context
* Verify_result [ 5 ] EXPLICIT INTEGER, -- X509_V_... code for `Peer'
- * PSK_identity_hint [ 6 ] EXPLICIT OCTET_STRING, -- PSK identity hint
- * PSK_identity [ 7 ] EXPLICIT OCTET_STRING -- PSK identity
+ * HostName [6] EXPLICY OCTET STRING, -- optional HostName from servername TLS extension
+ * ECPointFormatList [7] OCTET STRING, -- optional EC point format list from TLS extension
+ * PSK_identity_hint [ 8 ] EXPLICIT OCTET STRING, -- optional PSK identity hint
+ * PSK_identity [ 9 ] EXPLICIT OCTET STRING -- optional PSK identity
* }
* Look in ssl/ssl_asn1.c for more details
* I'm using EXPLICIT tags so I can read the damn things using asn1parse :-).
smime.p7s
Description: S/MIME Cryptographic Signature
T1_lib.c patch
if openssl has OPENSSL_NO_EC there is a small problem in t1_lib.c
Besides that I have the feeling that part of the point list code could
be simplified.
The lists supported are constant, so making an malloc etc and filling
this with
constant data looks a bit heavy.
regards
--
To verify the signature, see http://edelpki.edelweb.fr/
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
--- openssl-SNAP-20060313/ssl/t1_lib.c 2006-03-13 03:00:59.0 +0100
+++ openssl-SNAP-20060313+S/ssl/t1_lib.c2006-03-13 17:52:42.288071000
+0100
@@ -375,9 +375,9 @@ int ssl_parse_clienthello_tlsext(SSL *s,
fprintf(stderr,"\n");
#endif
}
+#endif /* OPENSSL_NO_EC */
data+=size;
}
-#endif /* OPENSSL_NO_EC */
*p = data;
return 1;
@@ -447,10 +447,10 @@ int ssl_parse_serverhello_tlsext(SSL *s,
fprintf(stderr,"\n");
#endif
}
+#endif /* OPENSSL_NO_EC */
data+=size;
}
-#endif /* OPENSSL_NO_EC */
if (data != d+n)
{
smime.p7s
Description: S/MIME Cryptographic Signature
ECX extensions.
I looked a bit in detail into the ecpoint format extension stuff. - Currently, as I said yesterday, one cannot compile openssl with OPENSSL_NO_EC. - I am not sure but it seems to me that the tlsext_ecpointformat_list in the SSL is not freed together with an SSL object, so you have a mem leak unless you disable the EC cipher suites. Well, besides that, I have the feeling that the extension code for the point formats is somewhat strange. - The ssl_prepare_client/serverhello_tlsext routines don't serve a real purpose IMO. They are just called before the corresponding ssl_add_client/server... At best, they could be called internally. My goal was to have a small footprint in s3_lib.c There would be some benefit it a prepare routine would ned to be called very early in the process and some heavy work would be avoided, but I don't think this is the case. - The tests in the prepare routine (are EC ciphers proposed) can be done in that add_client_hello_ext, and, if the extension is added, then just the constant octet string is set in the client hello. - It doesn't need to be remembered as such in the SSL object because it is a constant. At most, a flag bit string list for the supported values can be added to the SSL object (not containing the uncompressed) Thus, when receiving the server hello, one would match the bitstring with the received values, and make whatever decision later concerning certificats. - What is the purpose of keeping the pointformat list in a saved session? If a session is renegotiated, shouldn't all these information concerning ciphers go away? A renego could end with a totally different suite. This is not the same situation as with the hostname extension, where it may happen that the hostname changes, e.g. when a Host: directive occurs in the data stream, and this "state" should not be lost. Comments? -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. smime.p7s Description: S/MIME Cryptographic Signature
X509 certificate version settting problems
The opensslx509 and ca commands may create v3 certificates even if no extensions are present. The code in apps/x509.c and apps/ca.c that sets the version of a certificate is not quite correct. It is basically set when the code thinks that some extensions are going to be added and not after it; I think the version should be set just before signing a certificate and this should be done almost automatically. To do this inside the library function X509_sign may be a little be to far down although absolutely correct. A slightly weaker alternative is to add a value -1 to X509_set_version which can be called just before X509_sign, and which which set the correct version depending on the content. Doing it in this way, the set_version could also correctly set a v2 in case someone managed to put a subjectUID/issuerUID Note that in ca.c the code that is ifed'ed by X509_V3 is not active, the version is set later, and not even using X509_set_version. in the library there is also a routine X509_REQ_to_X509 which doesn't seem to be used anywhere and which produces a v3 certifictae although no extensions are created. I think this routine could be removed from the library. Since there are at least two options to code, I'd like to hear some comments before I send in one of the possible patches, which are pretty small either. in the demos/signcert, a version "3" is set, should be 2. smime.p7s Description: S/MIME Cryptographic Signature
Re: [openssl.org #1339] mkdef.pl
The problem is that a backslash may be followed by a \r
I have send a patch to openssl-users which I attach. Of course, instead
of \s* one
can use an optional \r.
Andy Polyakov via RT wrote:
my previous messaqge about mkdef.pl is wrong. Although the indicated code
can still loop, the read error seems to be this one
Could you elaborate on problem itself?
or
if (/\\\s*$/) {
chomp; # remove eol
chop; # remove ending backslash
$line = $_;
next;
}
As I fail to see why is it an issue. I mean any character following
backlash disqualifies the latter as line continuation and \\\s would
cause compiler syntax error... A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
--
To verify the signature, see http://edelpki.edelweb.fr/
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
diff -purN openssl-0.9.8b/util/mkdef.pl openssl-0.9.8b+S/util/mkdef.pl
--- openssl-0.9.8b/util/mkdef.pl 2006-01-02 15:08:22.0 +0100
+++ openssl-0.9.8b+S/util/mkdef.pl 2006-06-04 15:23:22.451088000 +0200
@@ -445,9 +445,9 @@ sub do_defs
$line = '';
}
- if (/\\$/) {
-chomp; # remove eol
-chop; # remove ending backslash
+ if (s/\\\s*$//) {
+#chomp; # remove eol
+#chop; # remove ending backslash
$line = $_;
next;
}
diff -purN openssl-0.9.8b/util/mkfiles.pl openssl-0.9.8b+S/util/mkfiles.pl
--- openssl-0.9.8b/util/mkfiles.pl 2005-04-27 18:27:14.0 +0200
+++ openssl-0.9.8b+S/util/mkfiles.pl 2006-06-04 15:19:19.251316000 +0200
@@ -88,9 +88,9 @@ while ()
($s,$b)=($1,$2);
for (;;)
{
- if ($b =~ /\\$/)
+ if ($b =~ s/\\\s*$//)
{
-chop($b);
+#chop($b);
$o.=$b." ";
$b=;
chop($b);
smime.p7s
Description: S/MIME Cryptographic Signature
patch for ca.c
The openssl ca command has a switch -create_serial. This switch allows the
creation of a serialnumber file for certificates. I think it is useful also
for the creation of a crl number file.
Furthemore, if crlnumbers are used then similar to certificates, it
seems useful
to me to have all crls in the crl directory (which can already been
configured).
enclosed find a patch for 0.9.8b
TIA for considering this.
Peter
--- openssl-0.9.8b/apps/ca.c 2005-09-30 18:47:15.0 +0200
+++ ps/ca.c 2006-06-14 11:58:44.541224000 +0200
@@ -824,14 +824,14 @@ bad:
/*/
/* lookup where to write new certificates */
- if ((outdir == NULL) && (req))
+ if ((outdir == NULL) && (req || gencrl))
{
struct stat sb;
- if ((outdir=NCONF_get_string(conf,section,ENV_NEW_CERTS_DIR))
+ if ((outdir=NCONF_get_string(conf,section,gencrl?ENV_CRL_DIR:ENV_NEW_CERTS_DIR))
== NULL)
{
- BIO_printf(bio_err,"there needs to be defined a directory for new certificate to be placed in\n");
+ BIO_printf(bio_err,"there needs to be defined a directory for new %s to be placed in\n",gencrl?"certificate":"CRL");
goto err;
}
#ifndef OPENSSL_SYS_VMS
@@ -1252,7 +1252,7 @@ bad:
fgets(buf[0],10,stdin);
if ((buf[0][0] != 'y') && (buf[0][0] != 'Y'))
{
- BIO_printf(bio_err,"CERTIFICATION CANCELED\n");
+ BIO_printf(bio_err,"CERTIFICATION CANCELLED\n");
ret=0;
goto err;
}
@@ -1360,7 +1360,7 @@ bad:
if ((crlnumberfile=NCONF_get_string(conf,section,ENV_CRLNUMBER))
!= NULL)
- if ((crlnumber=load_serial(crlnumberfile,0,NULL)) == NULL)
+ if ((crlnumber=load_serial(crlnumberfile,create_ser,NULL)) == NULL)
{
BIO_printf(bio_err,"error while loading CRL number\n");
goto err;
@@ -1448,7 +1448,7 @@ bad:
tmpser = BN_to_ASN1_INTEGER(crlnumber, NULL);
if (!tmpser) goto err;
X509_CRL_add1_ext_i2d(crl,NID_crl_number,tmpser,0,0);
-ASN1_INTEGER_free(tmpser);
+/* ASN1_INTEGER_free(tmpser); */
crl_v2 = 1;
if (!BN_add_word(crlnumber,1)) goto err;
}
@@ -1465,6 +1465,57 @@ bad:
if (!X509_CRL_sign(crl,pkey,dgst)) goto err;
+ if (tmpser) {
+ int k;
+ char *n;
+ j=tmpser->length;
+ p=(const char *)tmpser->data;
+ if(strlen(outdir) >= (size_t)(j ? BSIZE-j*2-6 : BSIZE-8))
+{
+BIO_printf(bio_err,"CRL file name too long\n");
+goto err;
+}
+
+ strcpy(buf[2],outdir);
+
+#ifndef OPENSSL_SYS_VMS
+ BUF_strlcat(buf[2],"/",sizeof(buf[2]));
+#endif
+
+ n=(char *)&(buf[2][strlen(buf[2])]);
+ if (j > 0)
+{
+for (k=0; k= &(buf[2][sizeof(buf[2])]))
+ break;
+ BIO_snprintf(n,
+ &buf[2][0] + sizeof(buf[2]) - n,
+ "%02X",(unsigned char)*(p++));
+ n+=2;
+ }
+}
+ else
+{
+*(n++)='0';
+*(n++)='0';
+}
+ *(n++)='.'; *(n++)='c'; *(n++)='r'; *(n++)='l';
+ *n='\0';
+ if (verbose)
+BIO_printf(bio_err,"writing %s\n",buf[2]);
+
+ if (BIO_write_filename(Cout,buf[2]) <= 0)
+{
+perror(buf[2]);
+goto err;
+}
+
+PEM_write_bio_X509_CRL(Cout,crl);
+
+ ASN1_INTEGER_free(tmpser);
+ }
+
PEM_write_bio_X509_CRL(Sout,crl);
if (crlnumberfile != NULL) /* Rename the crlnumber file */
smime.p7s
Description: S/MIME Cryptographic Signature
Re: SSL protocol state machine, IO layer, app layer regression testing framework
isn't ssl_test.c a sufficient starting point? smime.p7s Description: S/MIME Cryptographic Signature
Re: WG: [Openca-Users] After 100000 certificate issued...
[EMAIL PROTECTED] wrote: I found this in the OpenCA-Users mailinglist. Any ideas or suggestions? use the 'openssl ca' command with an empty index.txt file for each new certificate. and then manages the files differently, i.e. copy the content into a database. Or don't use the ca at all and use x509 and for revocation, just create an index.txt with the revoked certs. -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. smime.p7s Description: S/MIME Cryptographic Signature
adding a reference count to SSL_CTX
Hi, A call to SSL_new increments the reference count of the SSL_CTX object. In some application contexts one would like to pass around an SSL_CTX object and share it. If sharing occurs before an SSL_new is called and another instance does SSL_new and SSL_CTX_free, the SSL_CTX is freed. In order to avoid this free operation, currently one can create a fake SSL immediately after sharing the SSL_CTX pointer so so that the SSL_CTX remains alive. I find this a bit ugly to unncessarily go through the initialisation of an SSL object. All what would be needed IMO is a SSL_CTX_ctrl function that adds 1 to the reference count, the other function to dereference is already there, i.e. SSL_CTX_free. The crtl function basically would do: CRYPTO_add(&ctx->references,1,CRYPTO_LOCK_SSL_CTX) assuming that calling this directly in the application is not an external interface. I can provide a patch. Peter smime.p7s Description: S/MIME Cryptographic Signature
Re: adding a reference count to SSL_CTX
One can omit the SSL_CTX_free but in oder to be clean, someone must call it, and this may unfortunately not necessarily be the same instance who created it. I think you are kind of right, but there's another possibility. Does the other instance call SSL_free as well? Note that SSL_free also calls SSL_CTX_free, so I suspect your call to SSL_CTX_free is not needed (except in by whoever called SSL_CTX_new). Consider how you would make it work if you had three SSL objects sharing the same SSL_CTX. __Martin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
a small patch for crypto/asn1/asn1_gen.c
hi
When creating asn1 structure using the configuration file, it actually
necessary to encode conplicated sequences/sets using the configuration
syntax.
asn1_gen allows on the other hand to 'retag' any object using the IMP
directive. Even universal type can be changed,
but with universal 16/17 the constructed bit is not set.
asn1=FORMAT:HEX,IMP:16U,OCT:020100020101
The included patch fixes that?
TIA for considering this.
--
To verify the signature, see http://edelpki.edelweb.fr/
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
*** openssl-SNAP-20080309/crypto/asn1/asn1_gen.c 2007-10-13 18:00:11.0 +0200
--- openssl-mod/crypto/asn1/asn1_gen.c 2008-03-09 14:51:56.0 +0100
*** ASN1_TYPE *ASN1_generate_v3(char *str, X
*** 245,252
--- 245,258
/* If IMPLICIT, output tag */
if (asn1_tags.imp_tag != -1)
+ {
+ if (asn1_tags.imp_class == V_ASN1_UNIVERSAL
+ && (asn1_tags.imp_tag == V_ASN1_SEQUENCE || asn1_tags.imp_tag == V_ASN1_SET))
+ hdr_constructed = V_ASN1_CONSTRUCTED;
+
ASN1_put_object(&p, hdr_constructed, hdr_len,
asn1_tags.imp_tag, asn1_tags.imp_class);
+ }
/* Copy across original encoding */
memcpy(p, cpy_start, cpy_len);
smime.p7s
Description: S/MIME Cryptographic Signature
delta crl distribution point extension
enclosed pleas find a patch that adds support for the freshestCRL extension.
Have fun.
--
To verify the signature, see http://edelpki.edelweb.fr/
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
diff -rpc openssl-SNAP-20080309/crypto/objects/objects.txt openssl-mod/crypto/objects/objects.txt
*** openssl-SNAP-20080309/crypto/objects/objects.txt 2008-02-29 16:00:24.0 +0100
--- openssl-mod/crypto/objects/objects.txt 2008-03-09 15:33:41.0 +0100
*** id-smime-ct 5 : id-smime-ct-TDTInfo
*** 251,257
id-smime-ct 6 : id-smime-ct-contentInfo
id-smime-ct 7 : id-smime-ct-DVCSRequestData
id-smime-ct 8 : id-smime-ct-DVCSResponseData
- id-smime-ct 9 : id-smime-ct-compressedData
# S/MIME Attributes
id-smime-aa 1 : id-smime-aa-receiptRequest
--- 251,256
*** id-ce 35 : authorityKeyIdentifier : X50
*** 724,729
--- 723,730
id-ce 36 : policyConstraints : X509v3 Policy Constraints
!Cname ext-key-usage
id-ce 37 : extendedKeyUsage : X509v3 Extended Key Usage
+ !Cname delta-crldp
+ id-ce 46 : freshestCRL : X509v3 Delta CRL Distribution Point
!Cname inhibit-any-policy
id-ce 54 : inhibitAnyPolicy : X509v3 Inhibit Any Policy
!Cname target-information
*** mime-mhs-headings 2 : id-hex-multipart-m
*** 793,799
!Cname rle-compression
1 1 1 1 666 1 : RLE : run length compression
!Cname zlib-compression
! id-smime-alg 8 : ZLIB : zlib compression
# AES aka Rijndael
--- 794,800
!Cname rle-compression
1 1 1 1 666 1 : RLE : run length compression
!Cname zlib-compression
! 1 1 1 1 666 2 : ZLIB : zlib compression
# AES aka Rijndael
diff -rpc openssl-SNAP-20080309/crypto/x509v3/ext_dat.h openssl-mod/crypto/x509v3/ext_dat.h
*** openssl-SNAP-20080309/crypto/x509v3/ext_dat.h 2006-12-19 00:00:39.0 +0100
--- openssl-mod/crypto/x509v3/ext_dat.h 2008-03-09 17:07:06.0 +0100
*** extern X509V3_EXT_METHOD v3_bcons, v3_ns
*** 61,67
extern X509V3_EXT_METHOD v3_pkey_usage_period, v3_sxnet, v3_info, v3_sinfo;
extern X509V3_EXT_METHOD v3_ns_ia5_list[], v3_alt[], v3_skey_id, v3_akey_id;
extern X509V3_EXT_METHOD v3_crl_num, v3_crl_reason, v3_crl_invdate;
! extern X509V3_EXT_METHOD v3_delta_crl, v3_cpols, v3_crld;
extern X509V3_EXT_METHOD v3_ocsp_nonce, v3_ocsp_accresp, v3_ocsp_acutoff;
extern X509V3_EXT_METHOD v3_ocsp_crlid, v3_ocsp_nocheck, v3_ocsp_serviceloc;
extern X509V3_EXT_METHOD v3_crl_hold, v3_pci;
--- 61,67
extern X509V3_EXT_METHOD v3_pkey_usage_period, v3_sxnet, v3_info, v3_sinfo;
extern X509V3_EXT_METHOD v3_ns_ia5_list[], v3_alt[], v3_skey_id, v3_akey_id;
extern X509V3_EXT_METHOD v3_crl_num, v3_crl_reason, v3_crl_invdate;
! extern X509V3_EXT_METHOD v3_delta_crl, v3_cpols, v3_crld, v3_delta_crld;
extern X509V3_EXT_METHOD v3_ocsp_nonce, v3_ocsp_accresp, v3_ocsp_acutoff;
extern X509V3_EXT_METHOD v3_ocsp_crlid, v3_ocsp_nocheck, v3_ocsp_serviceloc;
extern X509V3_EXT_METHOD v3_crl_hold, v3_pci;
*** static X509V3_EXT_METHOD *standard_exts[
*** 121,127
&v3_name_constraints,
&v3_policy_mappings,
&v3_inhibit_anyp,
! &v3_idp
};
/* Number of standard extensions */
--- 121,128
&v3_name_constraints,
&v3_policy_mappings,
&v3_inhibit_anyp,
! &v3_idp,
! &v3_delta_crld
};
/* Number of standard extensions */
diff -rpc openssl-SNAP-20080309/crypto/x509v3/v3_crld.c openssl-mod/crypto/x509v3/v3_crld.c
*** openssl-SNAP-20080309/crypto/x509v3/v3_crld.c 2007-01-21 15:00:24.0 +0100
--- openssl-mod/crypto/x509v3/v3_crld.c 2008-03-09 16:13:23.0 +0100
*** const X509V3_EXT_METHOD v3_crld =
*** 79,84
--- 79,93
NULL
};
+ const X509V3_EXT_METHOD v3_delta_crld = {
+ NID_delta_crldp, 0, ASN1_ITEM_ref(CRL_DIST_POINTS),
+ 0,0,0,0,
+ 0,0,
+ 0,
+ v2i_crld,
+ i2r_crldp,0,
+ NULL};
+
static STACK_OF(GENERAL_NAME) *gnames_from_sectname(X509V3_CTX *ctx, char *sect)
{
STACK_OF(CONF_VALUE) *gnsect;
smime.p7s
Description: S/MIME Cryptographic Signature
asn1/x_attrib.c
It seems to me that
SMIMEEncryptionKeyPreference ::= CHOICE {
issuerAndSerialNumber [0] IssuerAndSerialNumber,
receipentKeyId [1] RecipientKeyIdentifier,
subjectAltKeyIdentifier [2] SubjectKeyIdentifier
}
is not supported since d2i_ASN1_TYPE doesn't support context tags.
I haven't tried whether the default processing in d2i_ASN1_TYPE
should simply do the same as for sets or sequences. That's for
tomorrow.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: rewriting the ASN1
Thanks, the current problem was not to set that attribute, but not to break in the pkcs7 or smime routines when you get a message having this attribute. > > If you are interested maybe you can use the IBM Jonah Implementation? > > This is an excerpt of a PKCS7 structure implemented in the Jonah ASN1 > Framework... > The 'fix/hack' is to change the default sections in d2i and i2d ASN1_TYPE to do the same as with sequence and set. At least pkcs7 can now copy the data, and the smime code starts complaining about the certificate chain, which is the expected behaviour. diff -c a_type.c ../../../openssl-0.9.6-beta1/crypto/asn1/a_type.c *** a_type.cWed Sep 20 10:46:20 2000 --- ../../../openssl-0.9.6-beta1/crypto/asn1/a_type.c Mon Sep 11 14:42:05 2000 *** *** 123,129 break; case V_ASN1_SET: case V_ASN1_SEQUENCE: - default: if (a->value.set == NULL) r=0; else --- 123,128 *** *** 246,252 break; case V_ASN1_SET: case V_ASN1_SEQUENCE: - default : /* Sets and sequences are left complete */ if ((ret->value.set=ASN1_STRING_new()) == NULL) goto err; ret->value.set->type=tag; --- 245,250 *** *** 254,262 if (!ASN1_STRING_set(ret->value.set,p,(int)len)) goto err; p+=len; break; ! /* default: ASN1err(ASN1_F_D2I_ASN1_TYPE,ASN1_R_BAD_TYPE); ! goto err; */ } ret->type=tag; --- 252,260 if (!ASN1_STRING_set(ret->value.set,p,(int)len)) goto err; p+=len; break; ! default: ASN1err(ASN1_F_D2I_ASN1_TYPE,ASN1_R_BAD_TYPE); ! goto err; } ret->type=tag; __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
sixth revision of the draft 4th edition of X.509 is on the server
For those who haven't see the following. Date: Thu, 21 Sep 2000 01:11:27 -0700 To: OSI Directory List <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED] From: "Hoyt L. Kesterson II" <[EMAIL PROTECTED]> Subject: sixth revision of the draft 4th edition of X.509 is on the server hello some of you observant readers out there have found a few more problems in the text. we have corrected them. a sixth revision of the draft 4th edition of x509 is on the directory server in both pdf and office 98 formats. the urls are: ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV6.doc ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV6.pdf this revision (v6) contains corrections in three areas: 1) Subject versus holder In the attribute certificate match matching rule (asn.1 and descriptive text), the terminology needs to be updated to reflect the technical agreement that attribute certificates are issued to holders, not to subjects. In clause 17.3.2, and in Annex A in the attribute certificate framework module, in the AttributeCertificateAssertion ASN.1 production: replace "subject" with "holder" and replace "subjectName" with "holderName" In clause 17.3.2 in the 2nd bullet following the ASN.1, replace "subjectName" with "holderName". 2) Optional authority key id The authority key identifier component in the certificate list assertion syntax, should be optional. In clause 11.3.6 and in the certificate extensions module of Annex A, in the CertificateListAssertion ASN.1 production; replace: authorityKeyIdentifier [3] AuthorityKeyIdentifier} with: authorityKeyIdentifier [3] AuthorityKeyIdentifier OPTIONAL } 3) Optional serial number The syntax of the attribute certificate exact matching rule should be aligned to that of the attribute certificate issuer. In clause 17.3.1 and in the attribute certificate framework module of Annex A, in the AttributeCertificateExactAssertion ASN.1 production: replace serialNumberCertificateSerialNumber, with serialNumberCertificateSerialNumber OPTIONAL, The ISO ballot on this text will close 28 November. The document will then be formally published and available for purchase shortly after that date. I will remove the copy of this document from the server at that time. keep those cards and letters coming hoyt - End Included Message - __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: TimeStamping
There are several ones, I have tested TSA implementations from my client and I have my own one based on OPENSSL and on the lastest draft of TSP. Look at http://www.edelweb.fr/tsa.html for details. > Hi, > is somebody have an implementation of the TimeStamping ? > __ > 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: Problems with SSL_write ..
> > sprintf(szBuf, > "POST %s HTTP/1.0\r\nContent-Type: %sContent-Length: %d\r\n", > m_szURL, "text/html\r\n\r\n", nBytesToWrite); Due to the "text/html\r\n\r\n" the Content-length is already outside the header > sprintf(szBuf, > "POST %s HTTP/1.0\r\nContent-Length: %d\r\nContent-Type: %s", > m_szURL, "text/html\r\n\r\n", nBytesToWrite); __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: openSSL and Visual basic
> Hi > > I wanted to know if anyone has gotten openSSL to work with visual basic. If > you have, can you please let me know. It would be greatly appreciated. > > Thanks Since it happened that last week I was trying to do that for a project, here the result of some rather q&d hack with a goal to touch just a minimal number of routines in 0.9.6a - The basic approach is to compile the whole stuff with the /Gz option in order not to modify the 3000 exported function prototypes. - All main routines need a __cdecl main The #define for MAIN, all the *test.c modules, and openssl.c - The pwd_read routine needs some __cdecl in the declaration of signal and a pointer array. - in apps/s_socket.c one call to signal needs an addition of __decl for socket_cleanup - mem.c needed some treatment with Malloc, Free, Realloc The macro CRYPTO_malloc_init needs some fix, easiest way was to call with all parms NULL and tests that in mem.c Goal: allow __stdcall type functions to be passed. - There are 5 modules that call qsort and 2 that call bsearch. Instead of finding all the routines that call them, I copied qsort and bsearch into the source from mfc and made them "__stdcall friendly". It seems possible to me to aviod that and replace all the _cmp functions of stack and set comparisions by __cdecl routines, it seems that are not suppoed to be called by applications anyway. - The asm routines : all declarations either need a __cdecl or the asm routines to be modified. With the first option some routines are not callable from VB, so be it for the moment. All ms\test routines passed. I wonder whether one of the friendly developpers would like to work on this for the 0.9.7 version in one way or another, at least to minimise the migration effort a bit. Peter Sylvester __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Timestamping server
For example: http://www.edelweb.fr/tsa.html > > Hello, > > I'm writing a simple timestamping client program to implement the new > timestamping draft (15). I'd like to know if there's any timestamping server > available for public to test. > > Would anyone please help? > __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
strsep
would it be possible to add something like the following
to evp/evp_test.c It is not a replacement for strsep but
a function that seems to work with the few calls in evp_test.c
static char * strsep(char **p,const char *sep) {
char * p1 = *p ;
while (**p != *sep) {
if (**p == '\0') return p1;
(*p)++;
}
**p = '\0'; (*p)++ ;
return p1 ;
}
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
subject Information access
Below please find a small mod of two files to allow the usage of a
Subject Information Access extension.
Since the actual trament is almost identical with the
Authority Information Access, the routines use the same v2i and i2v
routines.
It may be better taste to remove the 'AUTHORITY_' part of the names.
I leave this to the maintainers :-)
Thanks to Richard for having added the OID into objects.txt yesterday.
*** x509v3/ext_dat.hFri Feb 16 03:01:12 2001
--- ../../openssl-new/crypto/x509v3/ext_dat.h Tue Oct 9 14:01:48 2001
***
*** 58,64
/* This file contains a table of "standard" extensions */
extern X509V3_EXT_METHOD v3_bcons, v3_nscert, v3_key_usage, v3_ext_ku;
! extern X509V3_EXT_METHOD v3_pkey_usage_period, v3_sxnet, v3_info;
extern X509V3_EXT_METHOD v3_ns_ia5_list[], v3_alt[], v3_skey_id, v3_akey_id;
extern X509V3_EXT_METHOD v3_crl_num, v3_crl_reason, v3_crl_invdate, v3_cpols,
v3_crld;
extern X509V3_EXT_METHOD v3_ocsp_nonce, v3_ocsp_accresp, v3_ocsp_acutoff;
--- 58,64
/* This file contains a table of "standard" extensions */
extern X509V3_EXT_METHOD v3_bcons, v3_nscert, v3_key_usage, v3_ext_ku;
! extern X509V3_EXT_METHOD v3_pkey_usage_period, v3_sxnet, v3_info, v3_sinfo;
extern X509V3_EXT_METHOD v3_ns_ia5_list[], v3_alt[], v3_skey_id, v3_akey_id;
extern X509V3_EXT_METHOD v3_crl_num, v3_crl_reason, v3_crl_invdate, v3_cpols,
v3_crld;
extern X509V3_EXT_METHOD v3_ocsp_nonce, v3_ocsp_accresp, v3_ocsp_acutoff;
***
*** 93,98
--- 93,99
&v3_crl_invdate,
&v3_sxnet,
&v3_info,
+ &v3_sinfo,
&v3_ocsp_nonce,
&v3_ocsp_crlid,
&v3_ocsp_accresp,
*** x509v3/v3_info.cFri Feb 23 14:01:13 2001
--- ../../openssl-new/crypto/x509v3/v3_info.c Tue Oct 9 15:53:33 2001
***
*** 78,83
--- 78,92
0,0,
NULL};
+ X509V3_EXT_METHOD v3_sinfo =
+ { NID_sinfo_access, X509V3_EXT_MULTILINE, ASN1_ITEM_ref(AUTHORITY_INFO_ACCESS),
+ 0,0,0,0,
+ 0,0,
+ (X509V3_EXT_I2V)i2v_AUTHORITY_INFO_ACCESS,
+ (X509V3_EXT_V2I)v2i_AUTHORITY_INFO_ACCESS,
+ 0,0,
+ NULL};
+
ASN1_SEQUENCE(ACCESS_DESCRIPTION) = {
ASN1_SIMPLE(ACCESS_DESCRIPTION, method, ASN1_OBJECT),
ASN1_SIMPLE(ACCESS_DESCRIPTION, location, GENERAL_NAME)
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL and ASP
here a resume some points last april that I found while trying to compile the library. - The basic approach is to compile the whole stuff with the /Gz option in order not to modify the 3000 exported function prototypes. - All main routines need a __cdecl main The #define for MAIN, all the *test.c modules, and openssl.c - The pwd_read routine needs some __cdecl in the declaration of signal and a pointer array. - in apps/s_socket.c one call to signal needs an addition of __decl for socket_cleanup - mem.c needed some treatment with Malloc, Free, Realloc The macro CRYPTO_malloc_init needs some fix, easiest way was to call with all parms NULL and tests that in mem.c Goal: allow __stdcall type functions to be passed. - There are 5 modules that call qsort and 2 that call bsearch. Instead of finding all the routines that call them, I copied qsort and bsearch into the source from mfc and made them "__stdcall friendly". It seems possible to me to aviod that and replace all the _cmp functions of stack and set comparisions by __cdecl routines, it seems that are not suppoed to be called by applications anyway. - The asm routines : all declarations either need a __cdecl or the asm routines to be modified. With the first option some routines are not callable from VB, so be it for the moment. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: About OpenSSL 0.9.7 release
It seems to me that the ASN1 decoder of integers is not signaling encoding errors and tries to silently repair parts of them. There are three cases: A integer with length 0 is silently converted to a 0. If the encoded value has a leading 0 octet, this is simply removed without validation that the first bit of the following octet is 1. Similar with negative fields, a leadind FF gets removed with testing whether the next bit is 0. I think that the decoder should signal asn1 coding errors instead of silently repairing them maybe with an option STRICT_ASN1 I can provide a fix if the developpers think that it takes more than 5 minutes for one of them do change. peter __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
ASN1 decoder problem was: Re: About OpenSSL 0.9.7 release
Sorry, my last message had a wrong subject: It seems to me that the ASN1 decoder of integers is not signaling encoding errors and tries to silently repair parts of them. There are three cases: A integer with length 0 is silently converted to a 0. If the encoded value has a leading 0 octet, this is simply removed without validation that the first bit of the following octet is 1. Similar with negative fields, a leadind FF gets removed with testing whether the next bit is 0. I think that the decoder should signal asn1 coding errors instead of silently repairing them maybe with an option STRICT_ASN1 I can provide a fix if the developpers think that it takes more than 5 minutes for one of them do change. peter __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
extdat.h
It seems that in the latest snapshots in crypto/x509v3/ext_dat.h, the table standard_exts ist not sorted correctly. crl_hold should be after sinfo. &v3_crl_hold : #define NID_hold_instruction_code430 &v3_sinfo : #define NID_sinfo_access 398 I haven't checked other values. As a consequence SubjectInfoAccess no longer works as a standard extension. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL 1.0.0 beta 1 released
OpenSSL wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.0 Beta 1 Please download and test them as soon as possible. This new OpenSSL version incorporates 107 documented changes and bugfixes to the toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES). Would it be possible to review the 517 "NEW" problems in the rt database. some of the non-assigned ones are already 6 years old. I think that many of the remarks are probably now obsolete and only pollute the database. some real problems and, in particular, proposed patches are totally hidden. Personally I have a few reports, and some are in reality "treated/fixed" TIA for consideration. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
policy checking in openssl
The apps/s_server.c does not call the routines as cms/verify/.. to interprete policy parameters. Well, easy to change. There is a little bug in s_cb.c when the verify_callback is called without a certificate, i.e. err_cert == NULL, it segfaults. Also, easy to fix. Someone willing to apply a patch for both? I wonder whether a flag to get the policy parameters differently than from options would be a nice feature. Since the trust anchor self signed cert is ignored in this process, it has been suggested elsewhere to use the extension values to fill the initialisation value for path validation, i.e. require explicit policy, inhibitmapping, no mapping for anypolicy and the initial policy set. As a side effect this would allow to have different settings for different trustanchors. Any thoughts? Peter Sylvester /PS :§I"Ï®ÞrØm¶ÿà (¥éì²Z+7¯zZ)éí1¨¥x Ëh¥éì²W^¾^Ë%¢¸ ºÚ&j×.+-1©Úêæj:+v¨¢§²Éh®
Re: server authentication
Hi;
- verifying a self signed cert is strange. How would you trust it.
the standard way is to have your own CA, and then issuev a cert
for your server, and then use the CA cert as trust anchor in your
client.
Anyway your code for is false for at
least three reasons:
- The get by nid return the highest common name, not the
lowest (you can have more in theory).
- You don't treat the character type.
- You don't check whether the common name contains
for example hostname\0some.other.domain (\0 is
a binary 0.
It is incomplete because you don't check the subjectaltnames
and wild cards.
Bill Schoolfield wrote:
Hello,
I have a legacy app that I converted to use ssl encryption. I have
everything working, except server authentication.
I'm trying to test the host name in the server's cert post
handshake. Using:
void check_cert(SSL *ssl, char *host)
{
X509 *peer;
char peer_CN[256];
if(SSL_get_verify_result(ssl)!=X509_V_OK)
berr_exit("Certificate doesn't verify");
/*Check the cert chain. The chain length
is automatically checked by OpenSSL when
we set the verify depth in the ctx */
/*Check the common name*/
peer=SSL_get_peer_certificate(ssl);
if(peer) {
X509_NAME_get_text_by_NID
(X509_get_subject_name(peer),
NID_commonName, peer_CN, 256);
if(strcasecmp(peer_CN,host))
err_exit("Common name doesn't match host name");
}
}
This routine is being called after the handshake. What happens is
SSL_get_peer_certificate returns null.
I tried adding a call to SSL_CTX_set_verify() thinking this would
make the server's cert available, but all this did was generate the
following error on the server:
SSL accept error
23956:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert
unknown ca:s3_pkt.c:1053:SSL alert number 48
The server's certificate was self signed. What am I
missing?
Bill
__
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
Re: possible NULL ptr bug of openssl 1.0.0 stable 20091026
Zhongxing Xu wrote:
openssl-1.0.0-stable-SNAP-20091026/ssl/t1_lib.c:657
case TLSEXT_NAMETYPE_host_name:
if (s->session->tlsext_hostname == NULL)
{
if (len >
TLSEXT_MAXLEN_host_name ||
((s->session->tlsext_hostname = OPENSSL_malloc(len+1)) == NULL))
{
*al =
TLS1_AD_UNRECOGNIZED_NAME;
return 0;
}
memcpy(s->session->tlsext_hostname, sdata, len);
s->session->tlsext_hostname might be NULL. memcpy() cannot take NULL
as dest pointer.
The malloc above is tested? Did I overlook something?
-Zhongxing Xu
__
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
Re: how to create an already revoked certificate?
Creating a CRL using openssl does nothing else than reading the certificate"database" and creating an entry for all serialnumbers that have a R. You can create such a file by hand. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #411] #define or static, is that the question?
Some days ago, I had send a message to the dev list asking why in crypto/aaes/aes.h the symbols AES_DECRYPT and AES_ENCRYPT are defined as static const int. If one compiles a program with gcc -Wunused and -Werror one cannot use evp.h since it includes aes.h and these symbols are most likely not used in the program. Regards Peter Sylvester __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #670] -fPIC flag missing for asm/des_enc-sparc.
it seems that in the current snapshots the shared option for solaris does not work correctly. Compilation in crypto/des of gcc -c -o asm/des_enc-sparc.o asm/des_enc-sparc.S should probably be gcc -fPIC -c -o asm/des_enc-sparc.o asm/des_enc-sparc.S in order not to provoke a linker error. __ 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 #738] enhancement request
Following a hint from Steve, here a request fro an enhancement: an additional escaping mechanism for the print_ex routines simplifying xml. e.g. the characters < and & would be escaped. Thanks for consideration __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #739] enhancement request
Following a hint from Steve, here a request fro an enhancement: an additional escaping mechanism for the print_ex routines simplifying xml. e.g. the characters < and & would be escaped. Thanks for consideration __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #750] crld
Hi: In crypto/asn1/v3_crld.c there is: ASN1_ITEM_TEMPLATE(CRL_DIST_POINTS) = ASN1_EX_TEMPLATE_TYPE(ASN1_TFLG_SEQUENCE_OF, 0, DIST_POINT, DIST_POINT) ASN1_ITEM_TEMPLATE_END(CRL_DIST_POINTS) Shouldn't this be ASN1_ITEM_TEMPLATE(CRL_DIST_POINTS) = ASN1_EX_TEMPLATE_TYPE(ASN1_TFLG_SEQUENCE_OF, 0, CRLDistributionPoints, DIST_POINT) ASN1_ITEM_TEMPLATE_END(CRL_DIST_POINTS) indicating a litle bit closer to the asn1 defs that CRLDistributionPoints ::= SEQUENCE OF DIST_POINT instead of DIST_POINT ::= SEQUENCE OF DIST_POINT /P __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #966] make test in no-shared enviroment doesn't work
The current snapshot contains a test/Makefile
with an unconditional LD_PRELOAD which doesn't
seem to work when there is no ib{crypto|ssl}.so
e.g. for a no-shared build
environment is solaris 5.8 with gcc 3.2.3
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[openssl.org #1293] T1_lib.c code does not compile with NO_EC
__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1294] SSL_free memory leak
The new ecpointcurvelist is not freed in SSL_free as far as I see. -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1299] servername extension not encoded correctly
__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1302] dsa_ameth.c can free an unused value
__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1305] testtsa error
testtsa has a line test $? == 0 && error shouldn't this be test $? = 0 && error or test $? -eq 0 && error -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1306] apps/apps.c does not define strcasecmp
The #define _POSIX_C_SOURCE 2 at the beginning of apps/apps.c causes string.h on Solaris not to declare strcascmp. Shouldn't #define be protexct by an #ifdef for VMS? -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1339] mkdef.pl loops
In the 0.9.8b version
mkdef.pl loops in th following while.
# Reduce argument lists to empty ()
# fold round brackets recursively: (t(*v)(t),t) -> (t{}{},t)
-> {}
while(/\(.*\)/s) {
s/\([^\(\)]+\)/\{\}/gs;
s/\(\s*\*\s*(\w+)\s*\{\}\s*\)/$1/gs;#(*f{}) -> f
}
shouldn't it be replaced by
# Reduce argument lists to empty ()
# fold round brackets recursively: (t(*v)(t),t) -> (t{}{},t)
-> {}
while(/\(.*\)/s) {
s/\([^\(\)]*\)/\{\}/gs;
s/\(\s*\*\s*(\w+)\s*\{\}\s*\)/$1/gs;#(*f{}) -> f
}
--
To verify the signature, see http://edelpki.edelweb.fr/
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
[openssl.org #1339] mkdef.pl
my previous messaqge about mkdef.pl is wrong. Although the indicated code
can still loop, the read error seems to be this one
while() {
if (/\/\* Error codes for the \w+ functions\. \*\//)
{
undef @tag;
last;
}
if ($line ne '') {
$_ = $line . $_;
$line = '';
}
if (/\\\$/) {
chomp; # remove eol
chop; # remove ending backslash
$line = $_;
next;
}
where either the chomp should be called immediatley after reading,
or one could tolerate trailing white spaces.
while() {
chomp;
...
or
if (/\\\s*$/) {
chomp; # remove eol
chop; # remove ending backslash
$line = $_;
next;
}
--
To verify the signature, see http://edelpki.edelweb.fr/
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
[openssl.org #1341] util/mkfiles.pl
The mkfiles.pl tools seems to need the chop replaced by chomp in order to correctly find the \ at the end of a line. -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1557] error in ssl/ssl_lib.c
in ssl/ssl_lib.c in line 1371 there is a #ifndef OPENSSL_TLSEXT this should be #ifndef OPENSSL_NO_TLSEXT smime.p7s Description: S/MIME cryptographic signature
[openssl.org #1558] PSK session bug
While reading the code in sess_asn.c it seems that the PSK values are encoded and decoded using different tags. smime.p7s Description: S/MIME cryptographic signature
[openssl.org #1652] a small patch for crypto/asn1/asn1_gen.c
hi
When creating asn1 structure using the configuration file, it actually
necessary to encode conplicated sequences/sets using the configuration
syntax.
asn1_gen allows on the other hand to 'retag' any object using the IMP
directive. Even universal type can be changed,
but with universal 16/17 the constructed bit is not set.
asn1=FORMAT:HEX,IMP:16U,OCT:020100020101
The included patch fixes that?
TIA for considering this.
--
To verify the signature, see http://edelpki.edelweb.fr/
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
*** openssl-SNAP-20080309/crypto/asn1/asn1_gen.c 2007-10-13 18:00:11.0 +0200
--- openssl-mod/crypto/asn1/asn1_gen.c 2008-03-09 14:51:56.0 +0100
*** ASN1_TYPE *ASN1_generate_v3(char *str, X
*** 245,252
--- 245,258
/* If IMPLICIT, output tag */
if (asn1_tags.imp_tag != -1)
+ {
+ if (asn1_tags.imp_class == V_ASN1_UNIVERSAL
+ && (asn1_tags.imp_tag == V_ASN1_SEQUENCE || asn1_tags.imp_tag == V_ASN1_SET))
+ hdr_constructed = V_ASN1_CONSTRUCTED;
+
ASN1_put_object(&p, hdr_constructed, hdr_len,
asn1_tags.imp_tag, asn1_tags.imp_class);
+ }
/* Copy across original encoding */
memcpy(p, cpy_start, cpy_len);
smime.p7s
Description: S/MIME cryptographic signature
[openssl.org #1653] delta crl distribution point extension
enclosed pleas find a patch that adds support for the freshestCRL extension.
Have fun.
--
To verify the signature, see http://edelpki.edelweb.fr/
Cela vous permet de charger le certificat de l'autorité;
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
diff -rpc openssl-SNAP-20080309/crypto/objects/objects.txt openssl-mod/crypto/objects/objects.txt
*** openssl-SNAP-20080309/crypto/objects/objects.txt 2008-02-29 16:00:24.0 +0100
--- openssl-mod/crypto/objects/objects.txt 2008-03-09 15:33:41.0 +0100
*** id-smime-ct 5 : id-smime-ct-TDTInfo
*** 251,257
id-smime-ct 6 : id-smime-ct-contentInfo
id-smime-ct 7 : id-smime-ct-DVCSRequestData
id-smime-ct 8 : id-smime-ct-DVCSResponseData
- id-smime-ct 9 : id-smime-ct-compressedData
# S/MIME Attributes
id-smime-aa 1 : id-smime-aa-receiptRequest
--- 251,256
*** id-ce 35 : authorityKeyIdentifier : X50
*** 724,729
--- 723,730
id-ce 36 : policyConstraints : X509v3 Policy Constraints
!Cname ext-key-usage
id-ce 37 : extendedKeyUsage : X509v3 Extended Key Usage
+ !Cname delta-crldp
+ id-ce 46 : freshestCRL : X509v3 Delta CRL Distribution Point
!Cname inhibit-any-policy
id-ce 54 : inhibitAnyPolicy : X509v3 Inhibit Any Policy
!Cname target-information
*** mime-mhs-headings 2 : id-hex-multipart-m
*** 793,799
!Cname rle-compression
1 1 1 1 666 1 : RLE : run length compression
!Cname zlib-compression
! id-smime-alg 8 : ZLIB : zlib compression
# AES aka Rijndael
--- 794,800
!Cname rle-compression
1 1 1 1 666 1 : RLE : run length compression
!Cname zlib-compression
! 1 1 1 1 666 2 : ZLIB : zlib compression
# AES aka Rijndael
diff -rpc openssl-SNAP-20080309/crypto/x509v3/ext_dat.h openssl-mod/crypto/x509v3/ext_dat.h
*** openssl-SNAP-20080309/crypto/x509v3/ext_dat.h 2006-12-19 00:00:39.0 +0100
--- openssl-mod/crypto/x509v3/ext_dat.h 2008-03-09 17:07:06.0 +0100
*** extern X509V3_EXT_METHOD v3_bcons, v3_ns
*** 61,67
extern X509V3_EXT_METHOD v3_pkey_usage_period, v3_sxnet, v3_info, v3_sinfo;
extern X509V3_EXT_METHOD v3_ns_ia5_list[], v3_alt[], v3_skey_id, v3_akey_id;
extern X509V3_EXT_METHOD v3_crl_num, v3_crl_reason, v3_crl_invdate;
! extern X509V3_EXT_METHOD v3_delta_crl, v3_cpols, v3_crld;
extern X509V3_EXT_METHOD v3_ocsp_nonce, v3_ocsp_accresp, v3_ocsp_acutoff;
extern X509V3_EXT_METHOD v3_ocsp_crlid, v3_ocsp_nocheck, v3_ocsp_serviceloc;
extern X509V3_EXT_METHOD v3_crl_hold, v3_pci;
--- 61,67
extern X509V3_EXT_METHOD v3_pkey_usage_period, v3_sxnet, v3_info, v3_sinfo;
extern X509V3_EXT_METHOD v3_ns_ia5_list[], v3_alt[], v3_skey_id, v3_akey_id;
extern X509V3_EXT_METHOD v3_crl_num, v3_crl_reason, v3_crl_invdate;
! extern X509V3_EXT_METHOD v3_delta_crl, v3_cpols, v3_crld, v3_delta_crld;
extern X509V3_EXT_METHOD v3_ocsp_nonce, v3_ocsp_accresp, v3_ocsp_acutoff;
extern X509V3_EXT_METHOD v3_ocsp_crlid, v3_ocsp_nocheck, v3_ocsp_serviceloc;
extern X509V3_EXT_METHOD v3_crl_hold, v3_pci;
*** static X509V3_EXT_METHOD *standard_exts[
*** 121,127
&v3_name_constraints,
&v3_policy_mappings,
&v3_inhibit_anyp,
! &v3_idp
};
/* Number of standard extensions */
--- 121,128
&v3_name_constraints,
&v3_policy_mappings,
&v3_inhibit_anyp,
! &v3_idp,
! &v3_delta_crld
};
/* Number of standard extensions */
diff -rpc openssl-SNAP-20080309/crypto/x509v3/v3_crld.c openssl-mod/crypto/x509v3/v3_crld.c
*** openssl-SNAP-20080309/crypto/x509v3/v3_crld.c 2007-01-21 15:00:24.0 +0100
--- openssl-mod/crypto/x509v3/v3_crld.c 2008-03-09 16:13:23.0 +0100
*** const X509V3_EXT_METHOD v3_crld =
*** 79,84
--- 79,93
NULL
};
+ const X509V3_EXT_METHOD v3_delta_crld = {
+ NID_delta_crldp, 0, ASN1_ITEM_ref(CRL_DIST_POINTS),
+ 0,0,0,0,
+ 0,0,
+ 0,
+ v2i_crld,
+ i2r_crldp,0,
+ NULL};
+
static STACK_OF(GENERAL_NAME) *gnames_from_sectname(X509V3_CTX *ctx, char *sect)
{
STACK_OF(CONF_VALUE) *gnsect;
smime.p7s
Description: S/MIME cryptographic signature
[openssl.org #91] extdat.h
It seems that in the latest snapshots in crypto/x509v3/ext_dat.h, the table standard_exts ist not sorted correctly. crl_hold should be after sinfo. &v3_crl_hold : #define NID_hold_instruction_code430 &v3_sinfo : #define NID_sinfo_access 398 I haven't checked other values. As a consequence SubjectInfoAccess no longer works as a standard extension. __ 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 #2004] asn 1/t_x509.c ASN1_GENERALIZEDTIME_print does not handle fractions of seconds
In routine ASN1_GENERALIZEDTIME_print the line /* Check for fractions of seconds. */ if (i >= 15 && v[14] == '.') uses the variable i which no longer has the value of tm->length but 12. Shouldn't the code be: /* Check for fractions of seconds. */ if (i >= tm->length && v[14] == '.') All recent versions of openssl affected. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2019] [PATCH] Optimize handling of TLS SNI extension when resuming a session (server side)
/There seems to be a bug here indeed. One must be careful to make a desirable behaviour without breaking mod_ssl. / __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2021] sni bug
hi, the implementation of sni in openssl probaly does not correspond to the rfc. The rfc seems to allow to change the servername at any time in a client hello, and the servernamehello extension is wrong when the client has changed the servername (the name is not acknoledged but no client actually cares) the code in t1_lib.c prohibits this. I am working on a fix according the following outline: The tests in parsing routine testing the previous values of ssl->session->tlsext_hostname and servername_done are removed. an existing host in ssl->session->tlsext_hostname needs to be replaced by the new value (if necessary). server_name done is in a correct way, i.e, signaling the non-presence of a callback back, or the call back pretending it. the servernameindication in the serverhello is send correctly and also for resumed sessions. I am tempted to remove (or at least rename) the servername_done variable in ssl, since it is not really necessary, i.e. its presence, i.e. the presence of the bug can be tested at compile/configure time by an application. only t1_lib.c code is affected. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
