Re: [openssl.org #8] EVP_SealFinal declared void while the docu states it returns int
On Thu, May 09, 2002, Richard Levitte via RT wrote: [[EMAIL PROTECTED] - Thu Apr 25 16:16:02 2002]: Is this the expected behaviour ? Either way one must be fixed :) Btw EVP_OpenFinal does exactly what EVP_SealFinal does and adds to this the return value... Hmm, I think Steve should answer this one. Personally, I think this shows a certain inconsistency in the EVP, I see quite a lot of variantion in return types depending on which EVP_*Init, EVP_*Update and EVP_*Final you look at... Its an omission. It should have been updated when various EVP_*Init functions were updated to return values. I'll have a look at it. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Subject Alternative Name : openssl and RFC 2459
On Wed, May 15, 2002, CAMUS Sylvie FTRD/DTL/ISS wrote:
Hi
I Have read RFC 2459 about Subject Alternative Name. This Subject
Alternative Name is defined in this way :
id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
SubjectAltName ::= GeneralNames
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralName ::= CHOICE {
otherName [0] OtherName,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName [4] Name,
ediPartyName[5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID[8] OBJECT IDENTIFIER}
OtherName ::= SEQUENCE {
type-idOBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id }
EDIPartyName ::= SEQUENCE {
nameAssigner[0] DirectoryString OPTIONAL,
partyName [1] DirectoryString }
But, openssl supports (only) the following GeneralName :
rfc822Name, dNSName, uniformResourceIdentifier, iPAddress, registeredID
Why theses restrictions?
OpenSSL will parse and encode any of these.
It will however only display or generate the ones you mention.
This is for several reasons.
EDIPartyName, no real reason other than no one has wanted it.
OtherName is general purpose and is hard to handler generally,
though future versions of OpenSSL may handle simple string and
allow application to provide support for other forms based on
the type-id OID.
ORAddress: here be dragons!
Anyone unsure of the reason for that comment should have a look
at the definition of ORAddress...
Steve.
--
Dr. Stephen Henson [EMAIL PROTECTED]
OpenSSL Project http://www.openssl.org/~steve/
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #46] buffer overflow in apps/ca.c apps/req.c 0.9.7 snap 20020516
On Sun, May 19, 2002, Doug VanLeuven via RT wrote: Hi, I'm aware of the restrictions on US citizens. So I'm not going to contribute a patch. And forgive me if I don't adhere to the normal bug report format. I would strongly advise you to check the code in apps/req.c, function build_subject apps/ca.c, function do_subject I wanted the snapshot of openCA 20020503 and discovered they want the -subj option on openssl req openssl ca. That's why I'm snooping around your 0.9.7 snapshot 20020514. It's still there in 20020516. My system is RH7.3 linux 2.4.18-3 (redhat build) My symptoms were segmentation faults. The free (buf) on line 1251(apps/req.c) and the free (buf) on line 3117(apps/ca.c) caused it. It's the funtions that handles the new -subj option. (There may be more, I don't know). I had been on this project for over 18 hours, so I just added some extra size to the buflen for malloc this cleared my segmentation faults allowed me to progress on openCA. This is definately not a fix. It is just a fudge factor. I've committed a patch to this which should solve the problem, assuming I haven't broken something else :-) Please check the next snapshot. Thanks for the report. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PEM_ASN1_write_bio: PKCS #5 compliance
On Fri, May 31, 2002, Frank Balluffi wrote: I should have added that modifying PEM_ASN1_write_bio to use the PKCS #5-generated IV, not the salt as the IV, would cause problems reading encrypted files written prior to this change. So I should have really asked, Is there any value in complying with PKCS #5? Frank The algorithm used is not comliant with PKCS#5 but we're stuck with it because its what was used since SSLeay. Full PKCS#5 (v1.5 and v2.0) compliant functions are available which use PKCS#8. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: crlDistributionPoints format
On Tue, Jun 25, 2002, Bernhard Reiter wrote: Some CA add a crlDistributionPoints attribute for ldap. I haven't found an obvious way to do this, because of the comma seperating multivalue feature. crlDistributionPoints=URI:ldap//some.server/cn=Test-ZS1,o=x x,c=de?certificateRevocationList fails: 26922:error:2207507C:X509 V3 routines:v2i_GENERAL_NAME:missing value:v3_alt.c:391: 26922:error:2206B080:X509 V3 routines:X509V3_EXT_conf:error in extension:v3_conf.c:92:name=crlDistributionPoints, value=URI:ldap//thetis.intevation.de/cn=Test-ZS1,o=x x?certificateRevocationList Is this a bug? Openssl version 0.9.8 cvs from a couple of days ago. Try using the @section syntax for this extension, for example: crlDistributionPoints=@crldp_section [crldp_section] URI=ldap//some.server/cn=Test-ZS1,o=x x,c=de?certificateRevocationList Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #168] Ticket Resolved
On Mon, Jul 29, 2002, Jim Beasley via RT wrote: Lutz, I read all the material you suggested and get the following error when I run verify with the -issuer_checks: error 29 at 0 depth lookup:subject issuer mismatch without the -issuer_checks, there is no error. -issuer_checks is a debugging option which will give all manner of messages why it rejects certain certificates during the verify process. It is quite normal to have one or more messages like that when -issuer_checks is set. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [Fwd: PKCS#11 engines revisited]
On Tue, Aug 20, 2002, Matthias Loepfe wrote: Hi I just want to give you some background information why AdNovum has choosen the let's call it the 'interceptor-way' of implementing the PKCS#11 functionality. We are working in an environment where the main purpose of the hardware security modules (HSM) is not crypto acceleration but secure storage of private keys and trust ankers. And in may situations we have more than one (different) device active. For example one for user authentication (removable chipcard) and the other one for server/sevice authentication. The problem with the ENGINE aproach is, that if you load and register an engine for let's say RSA, the ALL RSA operations are directed to this engine. That's not what we expect. We ONLY want the RSA operations bound to the objects (keys, certs) stored on the HSM, be executed on it. Under the cover we also create an ENGINE but we do not register it, but simply use it for the key objects. That only happens if the appropriate ENGINE calls state that that ENGINE provides the default implementation. It doesn't have to. Our second goal was to implement a solution which was a plug replacement for a 'normal' OpenSSL. That means there is NO need to modify any application to use PKCS#11 instead of file based keys and certs. We 'mangled' all the necessary parameters into one string (like an URL). There are some problems with that approach if a fully featured PKCS#11 ENGINE is to be written at some point and with some planned OpenSSL extensions. Such an ENGINE might be able to supply the default implementation for some algorithms. A pretty good match for an ENGINE in PKCS#11 terms is a library and slot combination. Then an application might be able to use (say) slot #0 of library foo-pkcs11 for default RSA. This can be handled with the ctrl mechanism of OpenSSL 0.9.7, which isn't in previous versions. The config file stuff can also be used to allow existing applications to work with little or no modification. In this context a PKCS#11 ENGINE would be a kind of 'virtual' enging which would behave like the 0.9.7 dynamic ENGINE. An application (possibly via the config file mechanism) would load the PKCS#11 ENGINE, send it some ctrls which would say which file and slot to use and its new name. So what it might say is 'use slot #0 or library foo-pkcs11 and call it bar'. Any references to 'bar' after that would be routed to the slot and library combination. Under this scheme the key name would just map to CKA_NAME. Support for file based keys can be handled by some minor modifcation to OpenSSLs PEM handler. This might involve a special key with appropriate header ENGINE KEY perhaps? This special key format would have various bits of info in it. Minimally this might just be an ENGINE and key name and possibly some ctrls. We'd also have a utility to create the files (options to 'engine' perhaps?). When OpenSSL encountered such a key it would load the ENGINE referenced, optionally perform the ctrls on it then call ENGINE_load_private_key returning the EVP_PKEY structure to the application. This would all go on under the hood and the application should largely be able to handle this kind of key in the same way as an ordinary key. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #251] PKCS12 memory leak?
On Mon, Aug 26, 2002, Shaheed Bacchus via RT wrote: hi all, i have a routine that reads a private key and cert from a bio containing a PKCS12 file, the relevant part of the code is: PK12 = d2i_PKCS12_bio(DataBio, NULL); PKCS12_parse(PK12, Phrase, Pkey, Cert, Ca); PKCS12_free(PK12); at the end of the routine i free all of the structures used and i also do EVP_cleanup(); the memory leak tool on my system (proprietary embedded system) reports that memory is being leaked by routines that are called by PKCS12_parse() some of the routines that it thinks are leaking include ASN1_STRING_set, ASN1_STRING_type_new, X509_CERT_AUX_new, etc (these are only a few, there are several more all called directly or indirectly by PKCS12_parse) so my question is, is there some kind of cleanup routine that i'm supposed to be running that will cleanup the mess left behind? thanks. That sounds like a certificate hasn't been freed up. Is there a call to X509_new() as well? Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #248] bad serial number length
On Mon, Aug 26, 2002, Olaf Zaplinski via RT wrote: OpenSSL self-test report: OpenSSL version: 0.9.6g Last change: [In 0.9.6g-engine release:]... Options: no-idea --prefix=/usr/local --openssldir=/usr/local/ssl no-threads shared OS (uname): Linux binky 2.4.19 #1 Fri Aug 9 10:17:44 CEST 2002 i586 unknown OS (config): i586-whatever-linux2 Target (default): linux-elf Target: linux-elf Compiler: gcc version 2.95.3 20010315 (release) Hi all, I always get bad serial number length when I want to sign the second request with my self-signed CA. I just followed the steps on Try posting the result of: cat -vte serial from wherever the 'serial' file is before and after you get the error mesage. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #249] 'openssl verify' broken
On Mon, Aug 26, 2002, Olaf Zaplinski via RT wrote: OpenSSL self-test report: OpenSSL version: 0.9.6g Last change: [In 0.9.6g-engine release:]... Options: no-idea --prefix=/usr/local --openssldir=/usr/local/ssl no-threads shared OS (uname): Linux binky 2.4.19 #1 Fri Aug 9 10:17:44 CEST 2002 i586 unknown OS (config): i586-whatever-linux2 Target (default): linux-elf Target: linux-elf Compiler: gcc version 2.95.3 20010315 (release) Hi all, openssl x509 -purpose -in /etc/certs/foo.pem says: Certificate purposes: SSL client : No SSL client CA : No SSL server : Yes SSL server CA : No Netscape SSL server : Yes Netscape SSL server CA : No S/MIME signing : No S/MIME signing CA : No S/MIME encryption : No S/MIME encryption CA : No CRL signing : Yes CRL signing CA : No Any Purpose : Yes Any Purpose CA : Yes But openssl verify -verbose -CAfile /etc/certs/ca.pem /etc/certs/foo.pem says: 'error 20 at 0 depth lookup:unable to get local issuer certificate' What that is saying is that the it can't find the CA certificate of foo.pem in ca.pem. This could be because it doesn't contain the certificate or it could be a bug. Why dont' you include the contents of files foo.pem and cacert.pem? You can also try the -issuer_checks option to see why it is rejecting any candidate CA certificates. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #260] OBJ_txt2nid not working after upgrading to 0.9.6g
On Fri, Aug 30, 2002, Reddie, Steven wrote: The bug is in OBJ_txt2obj at obj_dat.c:420. The 'i' in line: op=d2i_ASN1_OBJECT(NULL,p,i); should be replaced with 'j': op=d2i_ASN1_OBJECT(NULL,p,j); In the case of subject alt name (06 03 55 1D 11), i=3 and j=5. My guess is that the code in ASN1_get_object which had previously been indef'd out had been disabled due to this bug, ie. the symptom fixed rather than the cause. This has already been reported and fixed in the 0.9.6-stable branch but it is not currently in any release. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #243] OpenSSL 0.9.6g fail on IBM OS/390
) it will always work. Also I'd suggest a new function, X509V3_add_value_native() (or whatever) which does any conversion inside and this is always called where it might be needed. Then in the call to X509V3_add_value_native() we can either just call X509V3_add_value (on ASCII machines) or do the conversion (on EBCDIC). Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #248] bad serial number length
On Mon, Sep 02, 2002, Olaf Zaplinski via RT wrote: Stephen Henson via RT wrote: [[EMAIL PROTECTED] - Mon Aug 26 10:33:29 2002]: I found the solution: I just commented out the lines 675-676 in apps/ca.c - now everything works as expected. Since this just disables the check it isn't a good idea. It is not disabled - some other check then tells me what went wrong when I force an error by editing the serial file. This error message (which I don't remember) was far better than that simple 'bad serial number length' which does not mean more that 'ouch' to me. ;-) Its checking for errors in index.txt, not serial. The error message suggested that index.txt has somehow had an invalid serial number written to it. What does you index.txt and your serial file look like when you get this message? This is what I did after 'make install': cd /usr/local/ssl mkdir rootCA [edited openssl.cnf and adjusted the paths accordingly] cd rootCA touch index.txt [edited serial and inserted one line containing '00'] So index.txt was a zero byte file, serial contains '00'. Then I created the CA and the 1st server cert w/o problems. The 2nd cert signing fails then. Yes but what does index.txt and serial contain after the error? Can you send them to me, not just a description because it may be one stray character that is confusing 'ca'. BTW, it would be great if 'make install' would setup the demoCA directory with proper index.txt and serial (AFAIK this was the case for older versions). The command CA.pl -newca does that. Can you check if a demoCA created with CA.pl -newca also produces this error? Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #248] bad serial number length
On Mon, Sep 02, 2002, Olaf Zaplinski via RT wrote: This is what I did after 'make install': cd /usr/local/ssl mkdir rootCA [edited openssl.cnf and adjusted the paths accordingly] cd rootCA touch index.txt [edited serial and inserted one line containing '00'] So index.txt was a zero byte file, serial contains '00'. Then I created the CA and the 1st server cert w/o problems. The 2nd cert signing fails then. That is the problem. You should not create 00 in the serial file because the serial number 00 is used by default for the root CA. You should instead use 01. This is mentioned in the EXAMPLES section of the ca manual page and CA.pl does this. OpenSSL shouldn't corrupt index.txt though even if serial is 00. The issuer name and serial number has to be unique according to various standards and having duplicates can confuse certain software and cause had to trace problems later: such as bogus verify or signature failures. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: problem building openssl-0.9.7-stable-SNAP-20020831 under Win32
On Mon, Sep 02, 2002, Cory Albrecht wrote: Hello, I picked up openssl-0.9.7-stable-SNAP-20020831 last night so I could get the OCSP functions, and I found a slight problem in it. doing perl Configure VC-WIN32 works fine, but when doing nmake -f ms\ntdll.mak, when it gets down to the point to link everything to gther to create openssl.exe, it fails because X509_REQ_print_ex can't be found. A little digging revealed that ms\libeay32.def is the problem - X509_REQ_print_ex is not given a number so therefor it isn't being exported. Simply adding the line X509_REQ_print_ex @ under the EXPORTS will fix it (or any other number that isn't already in use). Occasionally someone forgets to do a 'make update' when a new function is added, in this case me :-) An automatic fix is mentioned in the INSTALL.W32 file, running: perl util\mkdef.pl crypto ssl update Instead of using *.def files when producing DLLs under Windows, I would like to suggest doing soemthing like this: #if defined(VC_WIN32) /* I doubt the is the real define */ # define WIN32DLLEXPORT _declspec(dllexport) #else # define WIN32DLLEXPORT #endif /* defined(VC_WIN32) */ And then adding WIN32DLLEXPORT to function definitions where necessary. Foexeamble in crypto\x509\x509.h lin 1019 instead of: I think there's a comment on one of the MS KBs that you still need DEF files to maintain binary compatibility among different versions of the DLLs, so that the ordinals are consistent. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #262] bug: init race in SSLv3_client_method
On Sun, Sep 01, 2002, Patrick McCormick via RT wrote:
In this method in ssl/s3_clnt.c, there's a race condition with the static
init variable that is causing a crash in my multithreaded program. init
gets set to 0 before the static structures have been set up. I believe a
lock is needed.
142 SSL_METHOD *SSLv3_client_method(void)
143 {
144 static int init=1;
145 static SSL_METHOD SSLv3_client_data;
146
147 if (init)
148 {
149 init=0;
150 memcpy((char *)SSLv3_client_data,(char
*)sslv3_base_method(),
151 sizeof(SSL_METHOD));
152 SSLv3_client_data.ssl_connect=ssl3_connect;
153 SSLv3_client_data.get_ssl_method=ssl3_get_client_method;
154 }
155 return(SSLv3_client_data);
156 }
Has anyone run into this before? What method does OpenSSL use to lock
access to data structures?
Normally application create a single SSL_CTX structure before starting
any threads and muliple SSL structure from that SSL_CTX so that problem
doesn't arise.
I suppose it should be locked though. A simple workaround is to make a
dummy SSL_v3_client_method() call before starting any threads.
Steve.
--
Dr. Stephen Henson [EMAIL PROTECTED]
OpenSSL Project http://www.openssl.org/~steve/
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #267] crash in make
On Wed, Sep 04, 2002, Benoit Christophe via RT wrote: Hello !! Can you help me to resolve this problem ? start of the report of make-- making all in crypto... make[1]: Entering directory `/home/CE Pays Lorrains/mesdocs/1.3.26/openssl- 0.9.6g/crypto' gcc -I. -I../include -DTHREADS -DDSO_WIN32 -DTERMIOS -DL_ENDIAN -fomit-frame- pointer -O2 -m486 -Wall -c -o cryptlib.o cryptlib.c cryptlib.c:105: #error Inconsistency between crypto.h and cryptlib.c make[1]: *** [cryptlib.o] Error 1 make[1]: Leaving directory `/home/CE Pays Lorrains/mesdocs/1.3.26/openssl- 0.9.6g/crypto' make: *** [sub_all] Error 1 Is there a crypto.h file somewhere on your system from an earlier version of OpenSSL that it might be seeing before the internal one? Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: steps for generating signed and encrypted SMIME
On Fri, Sep 06, 2002, Himanshu Soni wrote: Hi I need to generate a signed and encrypted SMIME message. I see in the openssld apps that there is a sample that can sign OR encrypt. If I was to write my own to do signing AND encryption, then would I follow the following steps: Step 1: Sign the message using PKCS7_sign(). Step 2: i2d the P7 returned from PKCS7_sign(). Step 3: Encrypt the DER encoding from step 2 and call PKCS7_encrypt() on it? Step 4: Write the resulting P7 using SMIME_write_PKCS7 and send that to my mail client for delivery? I am not too sure about step 2. Do I need to DER encode the P7 returned from step 1 or should I call SMIME_write_PKCS7 on the P generated from step 1 and then call encrypt on the result. Please advise if my approach is wrong or if you have any suggestions. Call SMIME_write_PKCS7 in step 2, save the result to a file or memory BIO and pass that to PKCS7_encrypt(). Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: certificate purpose verify
On Fri, Sep 06, 2002, Aonzo Emanuele wrote:
Hi,
I'm Emanuele Aonzo from Italy and I have a problem about signature
verification. The signed document is a pkcs#7 and I've tried to verify his
signature. The result was INVALID_PURPOSE because the signer certificate
doesn't have the S/MIME signing purpose. I need to sign with this kind of
certificates and I can't disable this control because if I set the
PKCS7_NOCHAIN falg the verification is OK but I can't verify the cert chain.
I'd like a separation of chain verification and purpose verification
this is the openssl code
if (!(flags PKCS7_NOVERIFY)) for (k = 0; k sk_X509_num(signers);
k++) {
signer = sk_X509_value (signers, k);
if (!(flags PKCS7_NOCHAIN)) {
if(!X509_STORE_CTX_init(cert_ctx, store, signer,
p7-d.sign-cert))
{
PKCS7err(PKCS7_F_PKCS7_VERIFY,ERR_R_X509_LIB);
sk_X509_free(signers);
return 0;
}
X509_STORE_CTX_set_purpose(cert_ctx,
X509_PURPOSE_SMIME_SIGN);
} else if(!X509_STORE_CTX_init (cert_ctx, store, signer,
NULL)) {
PKCS7err(PKCS7_F_PKCS7_VERIFY,ERR_R_X509_LIB);
sk_X509_free(signers);
return 0;
}
Why are the certificates failing the purpose check? Could
you send me a sample certificate chain that fails?
You could set PKCS7_NOVERIFY and verify the chain manually.
Alternatively you could set a verify callback and override
the invalid purpose error.
Steve.
--
Dr. Stephen Henson [EMAIL PROTECTED]
OpenSSL Project http://www.openssl.org/~steve/
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #270] API: certificate chain handling incomplete
On Thu, Sep 05, 2002, Lutz Jaenicke via RT wrote: On Thu, Sep 05, 2002 at 09:36:09AM +0200, Tom Wu via RT wrote: I noticed that that the functions SSL_CTX_use_certificate_file and SSL_CTX_use_certificate_chain_file are available for use with an SSL_CTX *, yet there is no chain version available to set with an SSL *, only SSL_use_certificate_file and friends. Any particular reason for this? Its a problem with the current API. It did not take this situation into account. It e.g. makes client side callbacks useless, which would need to set a complete certificate chain to satisfy a server's request. Doesn't OpenSSL do a kind of cheap and nasty certificate verify to build up the chain, or am I thinking of something else? If it does that would be a possible work around but I agree that the API should be extended. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PKCS#7 enveloped objects and ciphers
On Tue, Sep 17, 2002, TJ Saunders wrote: Hello, OpenSSL developers. I ran across an interesting thing while working with openssl-0.9.7beta2, and am wondering if it's a bug, or is intentional. I have signed some data, creating a PKCS7 signed object. I've then encrypted that signed object, creating an enveloped object. At each step in this process, I'm displaying the various attributes and structs members (in a way that unhealthily violates the opacity of objects, I admit). The interesting case is this: I write the enveloped object out via PEM_write_bio_PKCS7(), and then read it back in using PEM_read_bio_PKCS(). The enveloped object read back in seems to be same as that written out -- except that p7-d.enveloped-enc_data-cipher is NULL, where it was not NULL when being written out. I looked into the PKCS7_dataDecode() routine, to see how it decrypted an eveloped object's encrypted contents without using that cipher. It apparently does so by using p7-d.enveloped-enc_data-algorithm to get the matching(?) cipher by name. Is this use (and lack of) of that enc_data-cipher member intentional? Or perhaps this is a case specific to working with enveloped objects? Or, most likely, I am missing something. =) The field isn't one of OpenSSLs ASN1 types so it isn't written out or read in when the structure is encode/decoded. Its just used as a temporary location to store a cipher during processing by the S/MIME routines. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL-0.9.7 RSA keys
On Fri, Sep 20, 2002, Chris Brook wrote: I have found the problem and fixed it in my code, so please ignore. However, for general info, it seems that the i2d_ low-level functions modify the data pointer passed in (it is an unsigned char **), so I could not see the result. Copying the pointer to another and passing the address of that in solves the problem. I had come across this with decoding so I guess it's a global quirk in the code! Its intended behaviour and was needed to make the old ASN1 code work. Strictly speaking it isn't needed with the new ASN1 code but it is retained for compatibility. This issue crops up frequently so it was added to the FAQ... Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PBEParams
On Mon, Sep 23, 2002, Chris Brook wrote: I am converting some code from BSAFE to OpenSSL, using 0.9.7 beta 3, and have an issue with the PKCS#5 PBEParameters encoding/decoding. In BSAFE, the algorithm ObjId is included in the PBEParameters encoding with an outer SEQUENCE. In OpenSSL it is not. I can manually add strip off the algo ObjId and Seqence to get at the real PBE Params but this is a pain. Is there a d2i/id2 that will encode/decode the PBEParams Info Object with the algo in it? Yes X509_ALGOR: its equivalent to AlgorithmIdentifier. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Patch for Win2000 Smartcardlogin
On Tue, Oct 01, 2002, Michael Bell wrote: Hi, last two months we tested the patches for Win2000 smartcardlogin. I think they are now ready for publishing. Which version of OpenSSL should I use if I prepare some diffs (diff -u)? I used openssl-0.9.7-betas until now but I think it is better to build the diffs with openssl-SNAP-20020930 etc. because they are for the HEAD-branch. Should I send the patches to openssl-dev or rt? I've got some prototype code that allows arbitrary structures to be added to extensions, from the config file. It should allow the Win2000 smartcardlogin extensions to be added and just about anything else. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Unique DNs
On Tue, Oct 01, 2002, Michael Bell wrote: Hi, there are several problems with the uniqueness of DNs. Therefore I want to start programming an option to deactivate such checks. Before I start I want to be sure to have a complete overview about the sourcecode. So my question is, is there any code which depends on the uniqueness of DNs in the index.txt except of ca.c? The main problem AFAICS is the TXT db indexing which is only in ca.c Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Patch for Win2000 Smartcardlogin
On Wed, Oct 02, 2002, Michael Bell wrote: Dr. Stephen Henson wrote: I've got some prototype code that allows arbitrary structures to be added to extensions, from the config file. It should allow the Win2000 smartcardlogin extensions to be added and just about anything else. Where can I find this code to test it? On my hard disk :-) It has not been committed yet, I've got the basic code working. You can do simple things such as: something=UTF8STRING:some string value or more intricate stuff like: something=SEQUENCE:section [section] field1 = UTF8STRING:first value field2 = EXPLICIT:0, UTF8STRING:first value Its still under test. I'll need to integrate it with things like the extension code or the otherName part of GeneralName. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: openssl pkcs8 encryptionbug
On Mon, Oct 14, 2002, Michael Bell wrote: Hi, I received some messages that there are problems with the conversion from PKCS#8 to old SSLeay format and so I checked it. The result is the following: 1. the bug is only present if you convert a PKCS#8-key to the old format 2. set the option -passout (we use env:outpwd) 3. internally the following function is used in apps/pkcs8.c: PEM_write_bio_PrivateKey(out, pkey, NULL, NULL, 0, NULL, passout); I searched the sources and find the following comment in crypto/pem/pem_pk8.c -- As usual if 'enc' is NULL then it uses the unencrypted private key form. -- 'enc' is the third argument! This looks like a disaster because pkcs8 has no options -des, -des, -aes etc. and there is no default. The result is an unencrypted private key without any warning. The passphrase is simply ignored. Do I something wrong or is this a real security bug? If it is a bug then I strongly recommend a bugfix before 0.9.7-release even if it requires some new options. If the PKCS#8 key is in PEM format it can be handled directly without any conversion. I agree some more options should be added and this behaviour documented. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PKCS#7 problem
On Mon, Oct 14, 2002, Jan Mikosiñski wrote: Hi I try to implement simple message support in compatible with pkcs#7 standard. I use OpenSSL ver 0.9.6g. I encrypt data with PKCS7_encrypt and decrypt with PKCS7_decrypt functions and i've got a little problem. The length of the data to be encrypted is 2951B . I encrypt this data and next decrypt it , but the length of decrypted data is 2962B. The flags parameter i n both functions I pass 0 (zero). I dont know why do I get this length difrence. Does anybody have any suggestion to resolve my problem ? This function is documented in newer 0.9.7 snapshots. It looks like you need the PKCS7_BINARY flag. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: openssl pkcs8 encryptionbug
On Tue, Oct 15, 2002, Michael Bell wrote: Dr. Stephen Henson wrote: If the PKCS#8 key is in PEM format it can be handled directly without any conversion. This is perhaps correct for the OpenSSL-commandlinetools (I don't know it) but I think mod_ssl is a problem and perhaps other applications which only use the old OpenSSL-format. It should be transparent for any application that calls PEM_read_bio_PrivateKey() either directly or indirectly. I'm not sure what mod_ssl is doing if it can't handle PKCS#8 PEM. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Help
On Thu, Oct 24, 2002, Nicolas Chelebifski wrote: Now I also have to add a certificatePolicies extension and I can't make that work. How do add a certificatePolicies extension in my code (not using a config file), The easiest way is to add it via a config file in a C string, which you can put in a memory BIO. Alternatively you can populate the structure manually and add it using X509_add1_ext_i2d(). Check the x509v3.h header file and v3_cpols.c too. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [ENHANCEMENT] Support for Oracle Wallet Manager nonstandard private key format
On Fri, Oct 11, 2002, [EMAIL PROTECTED] wrote: Dear openssl hackers, Attached is a new applet for /usr/bin/openssl that we developped. It may be used to decode Oracle Wallet Manager 2.1's nonstandard private key exports. For the record, they mimick a PKCS#8 file, except the encrypted ASN.1 payload is not a proper PKCS#8 private key structure, but an unadorned RSA key (SEQUENCE OF INTEGER). Feel free to use this work as you see fit, including putting whatever copyright you want. Oh, and keep up the good work and kudos to all ! Can you send me an example of such a key? It might be best handled automagically in the PKCS#8 code: there's already loads of stuff for broken PKCS#8 formats. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #331] openssl-0.9.7beta3, ocsp_asn.c
On Thu, Nov 07, 2002, Á¤ ±æ·Ä via RT wrote: I think that ASN1_IMP(OCSP_RESPID, value.byKey, ASN1_OCTET_STRING, 2) is wrong. I think that ASN1_EXP(OCSP_RESPID, value.byKey, ASN1_OCTET_STRING, 2) is right. Yes you are correct, I hadn't noticed that the default tagging was EXPLICIT. I've checked in a fix. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #337] bug report (OpenSSL 0.9.6g, RC2 cipher)
On Tue, Nov 12, 2002, Developer via RT wrote: Hi, Situation: == 1.) Call: pCipher=EVP_get_cipherbyname(RC2-CBC) 2.) Call: EVP_CIPHER_CTX_init(ec_ctx) 3.) Call: EVP_CipherInit(ec_ctx,pCipher,byKey,byIV,1) byKey contains 16 octets (128bit RC2 key) 4.) Call: VP_CIPHER_CTX_ctrl(ec_ctx,EVP_CTRL_SET_RC2_KEY_BITS,40,0L); to set effective key length to 40bit Bug: Effective key length is updated in struct. but RC2 key data is NOT updated (bugfix seems to be impossible because VP_CIPHER_CTX_ctrl does not have access to raw key material !?). That's not how you call EVP when you want to change parameters. The correct sequence is: EVP_CipherInit(ctx, cipher, NULL, NULL, 1); /* Ctrls such as RC4 key length */ EVP_CipherInit(ctx, NULL, key, iv, 1); See the manual pages for more info. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Patch for Win2000 Smartcardlogin
On Wed, Oct 02, 2002, Michael Bell wrote: Dr. Stephen Henson wrote: I've got some prototype code that allows arbitrary structures to be added to extensions, from the config file. It should allow the Win2000 smartcardlogin extensions to be added and just about anything else. Where can I find this code to test it? An early version of the code in now in 0.9.8-dev. Check out the docs in ASN1_generate_nconf(3) and doc/openssl.txt . Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #20] patch for asn1_d2i_read_bio() to detect truncated data
On Tue, Dec 03, 2002, Vaclav Ovsik wrote: On Tue, Dec 03, 2002 at 03:10:26PM +0100, Stephen Henson via RT wrote: What do you mean buggy behaviour? OpenSSL ASN1 code expects a complete structure only and should produce an error if it is incomplete, at least at ^^^ exactly I mean that OpenSSL not produce any error! My colleague sent some easy example, that demonstrates this bug. (example is attached again) Thanks. The example illustrates the problem nicely, if you check the actual field z2-str in the example it still has the correct length but its contents aren't correct. This is caused by asn1_d2i_read_bio() assuming in BIO_read() that the amount of data supplied will always be that requested. Which wont be the case on EOF or error. I've checked in a fix which should be in the next snapshots. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: ASN.1 DER encoding of SEQUENCE components with DEFAULT values
On Fri, Dec 06, 2002, Stefan Kotes wrote: Openssl Team, I have one question regarding DER encoding of the SEQUENCE/SET components. According to the A Layman's Guide to a Subset of ASN.1, BER, and DER document, if the value of a SEQUENCE or SET component with DEFAULT qualifier is the default value, the encoding of that component in not supposed to be included in contents octets. Openssl does not seem to follow this rule with version member of structures like X509_CINF, OCSP_REQUEST, OCSP_RESPDATA. Is this ASN.1 encoding behavior in openssl library by design or is it something you plan to change ? DEFAULT is handled in OpenSSL by using OPTIONAL and then handling things appropriately in any friendly wrappers that access the field. IIRC the actual rules only enforce omission of the field for DER and it can still be included for BER. One reason for retaining this behaviour is that some broken encodings which are supposed to follow DER still include fields which have the default value. If OpenSSL always omitted the field then this would result in a different encoding, which would break signatures. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: ASN.1 DER encoding of SEQUENCE components with DEFAULT values
On Fri, Dec 06, 2002, Stefan Kotes wrote: Mr. Henson, I understand the reason for retaining this behavior, but there is one problem with this approach. The OpenSSL library also becomes generator of broken encoding, if these DEFAULT SEQUENCE components are populated with default values. It is kind of vicious cycle. The OpenSSL library is basically correctly DER encoding the SEQUENCE structures only if these DEFAULT SEQUENCE components with default values are missing (NULL). That's why the structures should be populated by wrapper functions which handle this case. For example X509_EXTENSION_set_critical(), though the set_version forms don't curently have this functionality. I suppose at some point in future an additional template 'interpreter' could be added to the new ASN1 code to handle field setting to default values automatically. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: problem:certificate from openssl to work with iplanet enterprise 5.5
On Mon, Dec 09, 2002, wen ding wrote: hi, I try to use openssl to issue and manage certificates for internal usage. I generated CA ROOT certificate with utility from openssl and issued server certificate signed by the CA ROOT. The server certificate and CA ROOT worked very well with iplanet fasttrack 4.1, a early version web server from sun. After that I tried to use it with iplanet enterprise 5.5, the server certificate can be installed sucessfully. But the CA ROOT certificate can be recognized by iplanet enterprise 5.5, but when I tried to add it, the system failed with the message: Incorrect Usage:Invalid certificate The server could not import one of the certificates. I found all ROOT CA from commerical CA can cooperate well with iplanet enterprise and in version field of all certificates from commericial CA 'V3' indicates that X509 version 3. In all certificates issued from openssl, the version field is filled with 'V1'. There are also other differences, such as fields issuing organization key id and subject key id do not exist in certificates from openssl. Besides the problem as stated above, the crl generated from openssl either can not work under iplanet enterprise and its version is also 'V1' while revocation list from commericial product is 'V3'. As i am a newbie in using openssl, i welcome anyone provide me with any advice. Thanks in advance. My email is [EMAIL PROTECTED] Great thanks! dingwen from China You haven't mentioned what technique you used to generate the certificates with OpenSSL. If you'd used CA.pl (see manual page) it would create V3 certificates and include the extensions you mention. OpenSSL by default creates V1 CRLs because some versions of Netscape chokes on them. By adding extensions it can create a V2 CRL. Not sure what you mean by a V3 CRL do you have an example you could post? Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #396] AES cipher?
On Wed, Dec 11, 2002, Lutz Jaenicke via RT wrote: On Tue, Dec 10, 2002 at 02:14:13PM -0800, Sunitha Kumar wrote: Or, a more consise list with only AES, /usr/local/ssl/bin/openssl ciphers -tls1 AES ADH-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA: AES256-SHA:ADH-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA: AES128-SHA and, I don't find RSA_WITH_AES_128_SHA. Anybody have any pointers? thanks much, It's there, you just didn't note: ljaenicke@lutz:~/newsoft/openssl-0.9.7-beta4/ssl$ grep RSA_WITH_AES_128 * s3_lib.c: TLS1_TXT_RSA_WITH_AES_128_SHA, s3_lib.c: TLS1_CK_RSA_WITH_AES_128_SHA, s3_lib.c: TLS1_TXT_DH_RSA_WITH_AES_128_SHA, s3_lib.c: TLS1_CK_DH_RSA_WITH_AES_128_SHA, s3_lib.c: TLS1_TXT_DHE_RSA_WITH_AES_128_SHA, s3_lib.c: TLS1_CK_DHE_RSA_WITH_AES_128_SHA, tls1.h:#define TLS1_CK_RSA_WITH_AES_128_SHA 0x032F tls1.h:#define TLS1_CK_DH_RSA_WITH_AES_128_SHA 0x0331 tls1.h:#define TLS1_CK_DHE_RSA_WITH_AES_128_SHA 0x0333 tls1.h:#define TLS1_TXT_RSA_WITH_AES_128_SHAAES128-SHA tls1.h:#define TLS1_TXT_DH_RSA_WITH_AES_128_SHA DH-RSA-AES128-SHA tls1.h:#define TLS1_TXT_DHE_RSA_WITH_AES_128_SHADHE-RSA-AES128-SHA So the textual representation is AES128-SHA, which does not state the RSA authentication. Which brings up the next question: is there any reason for this inconsistency? I will create a ticket... None of the static RSA ciphersuites include RSA in the textual representation. We should update ciphers manual page for the new AES stuff though. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Bug in smime -verify
On Fri, Dec 27, 2002, Tim Tassonis wrote: Hi all I think I've encountered a bug in openssl smime. I try to verify a mail signed with outlook using the option not to include the certificate in the signature. From what I can figure out, this should be possible with openssl using the options: openssl smime -verify -signer tim.crt -in message.txt -nointern -CAfile cas.crt or openssl smime -verify -noverify -signer tim.crt -in message.txt -nointern However, I always get the error: 2278:error:2107C080:PKCS7 routines:PKCS7_get0_signers:signer certificate not found:pk7_smime.c:317: It seems openssl always tries to retrieve the signers certificate, althought I explicitely override this with -nointern. Is this a known bug and/or even already fixed in the openssl 0.9.7 betas? As mentioned in the manual page the -signer when used with -verify is the file to write the signers certificate to. One ore more possible candidate signer certificates should be presented to the -certfile option. So if you do: openssl smime -verify -certfile tim.crt -in message.txt -CAfile cas.crt it should be OK. You don't need -nointern that just means that it always ignores certificates in the message, without -nointern it wil still look in those mentioned in -certfile if the signer's certificate can't be found in the message itself. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #425] Build error on Windows NT4?
On Tue, Dec 31, 2002, Wirta Ville via RT wrote: Hi! I took 0.9.7 from OpenSSL.org and tried compiling it on Windows NT4 sp6a with Visual Studio command line tools. I followed the instructions of install.w32 but got the following error with ms\do_nasm: What version of VC++ are you using? Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL with CRL check
On Wed, Jan 08, 2003, philippe BOUGERET wrote: Hi, I have made a client - server connexion using TLS with a server authentification and also client authentification I use SSL_CTX_load_verify_locations function in order to load the AC certificat I use SSL_CTX_use_certificate_file function in order to load the client certificat HOW CAN I LOAD THE CRL FILE (my crl is stored in a crl.pem file) and MADE THE CRL CHECK ? You need OpenSSL 0.9.7. The CRL can be either in the file or directory specified for SSL_CTX_load_verify_locations(), you need to call c_rehash as usual if its a directory. Then set the store flag X509_V_FLAG_CRL_CHECK. The s_client utility in 0.9.7 (and some other utilities too) has this functionality. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: ASN1_TIME inconsistent function behaviour / bug?
On Tue, Jan 14, 2003, Paul Koster wrote: Working on code to read/process and create x509 certificates I encountered the following. The following code results in an ASN1_TIME structure with internal length field of 14 (date1-length =14). date1 = ASN1_TIME_new(); ASN1_GENERALIZEDTIME_set_string(date1, 20020819093712); When extracting time out an existing certificate however with this date/time would result in a length field of 15 (date2-length = 15). ASN1_GENERALIZEDTIME *date2 = ASN1_TIME_to_generalizedtime (X509_get_notBefore(cert), NULL); Consequently ASN1_STRING_cmp(date1, date2) fails, although the strings are exactly the same, 14 characters that make up the date, followed by \0. Have I missed something or is there a bug somewhere? Was this existing certificate created using OpenSSL? What does the time in this existing certificate look like? That is what length is reported by asn1parse on it. In particular does the certificate encoding include the trailing \0? Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: ASN1_TIME inconsistent function behaviour / bug?
On Tue, Jan 14, 2003, Paul Koster wrote: The following code results in an ASN1_TIME structure with internal length field of 14 (date1-length =14). date1 = ASN1_TIME_new(); ASN1_GENERALIZEDTIME_set_string(date1, 20020819093712); When extracting time out an existing certificate however with this date/time would result in a length field of 15 (date2-length = 15). ASN1_GENERALIZEDTIME *date2 = ASN1_TIME_to_generalizedtime (X509_get_notBefore(cert), NULL); Consequently ASN1_STRING_cmp(date1, date2) fails, although the strings are exactly the same, 14 characters that make up the date, followed by \0. Have I missed something or is there a bug somewhere? Was this existing certificate created using OpenSSL? No. The certificate was created with a java library (from bouncycastle.com I think). What does the time in this existing certificate look like? That is what length is reported by asn1parse on it. In particular does the certificate encoding include the trailing \0? The output of openssl asn1parse -inform DER cert.cer is: 165:d=3 hl=2 l= 13 prim: UTCTIME :020819093712Z May I assume that the Z stands for \0? And l=13 stands for a length of 13 which gives a length of 15 when the year is written as 2002? No Z is the actual character 'Z'. Its a time zone but the various certificate standards say it should always be Z for GMT. This clears things up a bit, but then may question is how date/time should be handled using openssl code. I'd like to be able to perform a compare operation (==, , ) on certificate notBefore and notAfter fields. Are there any 'normalization' functions available for example? Both UTCTime and GeneralizedTime can be used to represent date/time, the Time type (with structure ASN1_TIME) is a combination of the two which uses whatever is appropriate. UTCTime can only represent years from 1950 to 2049 whereas GeneralizedTime can represent from to . So what you can do is check the type using ASN1_STRING_type(str) and interprete its contents accordingly. If however you just want to compare against a time_t value X509_cmp_time() will do the trick. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: ASK OPENSSL: CRL extensions
On Thu, Jan 16, 2003, Massimiliano Pala wrote:
Hi all,
I have one question for you. I want to check extensions added to a CRL
entry but I do not know how to access informations. Actually I use the
code:
rev = X509_CRL_get_REVOKED(crl);
for(i = 0; i sk_X509_REVOKED_num(rev); i++) {
r = sk_X509_REVOKED_value(rev, i);
for (i=0; isk_X509_EXTENSION_num(r-extensions); i++)
{
ASN1_OBJECT *obj;
ASN1_OBJECT *obj_tmp;
X509_EXTENSION *ex;
ex=sk_X509_EXTENSION_value(r-extensions, i);
obj=X509_EXTENSION_get_object(ex);
[ Missing Code ]
}
I would like in the [ Missing Code ] to check the object (that is of
the NID_crl_reason type) for its value, for example if it is a
certificateHold or RemoveFromCRL, etc...
What's the correct way to do it ?
Thanks to all of you...
Check out doc/openssl.txt what you want here is X509_REVOKED_get_ext_d2i()
on 'r' not that loop.
As a general pointer if you have code which acceses structure elements
directly it means that you've either missed a high level function that does
the job itself or we haven't got round to adding one yet :-)
The structure you get back from the function is an ASN1_ENUMERATED structure
which is treated in a similar way to ASN1_INTEGER.
You can for example then call ASN1_ENUMERATED_get() on it to get the result in
a long.
Steve.
--
Dr. Stephen Henson [EMAIL PROTECTED]
OpenSSL Project http://www.openssl.org/~steve/
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Problem decrypting a signed and then encrypted pkcs7 message on windows 98 using Crypto API
On Thu, Jan 16, 2003, Himanshu Soni wrote: Hi I apologize for this annoying win32 spam. I have google'd a lot but still couldn't find the exact reason why a windows 98 with IE 6.0 box would fail to decrypt a signed and then encrypted pkcs7 message that I generated using openssl 0.9.6g. When the message is EVP_des_ede3_cbc() encrypted, then on windows 98 with IE 6.0, Crypto API's CryptDecryptAndVerifyMessageSignature(...) call fails with NTE_BAD_FLAGS. When I EVP_des_cbc() encrypt the message, then its fine on windows 98 with IE 6.0. The same code works fine on windows me/xp/2000 for EVP_des_ede3_cbc() encrypted message. Has anyone seen this or similar behavior and if so, would you please help? Has Win98 had the 128 bit security patch applied? If not that could be the problem. IIRC the About box in Internet Explorer should give this info. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Apparent bug: OpenSSL 0.9.7 crypto/evp_enc.c EVP_DecryptInit()
On Thu, Jan 16, 2003, Larry West wrote: I've searched the archives, don't find a mention of this, and the Jan 15 snapshot has the same apparent bug. I'm not absolutely sure, and even if I'm right it's a one-line fix so I'm hoping one of the active members would be willing to patch it. [[By the way, the webpage form to submit to MajorDomo seems broken: though it reports success, no email ever arrives; when I sent the subscription request manually it worked immediately.]] The problem is that EVP_DecryptInit() calls EVP_CipherInit_ex() rather than EVP_CipherInit(). The reasons I believe this is a problem: (1) Paralellism: EVP_EncryptInit() calls EVP_CipherInit(), not the _ex() form. (2) In v0.9.6, both EVP_DecryptInit() and EVP_EncryptInit() called EVP_CipherInit(). [there was no _ex()]. In v0.9.7, there is no comment to indicate why these two now differ, so it may be a typo. (3) The PTPTL v0.2 code I'm building (Peer-to-peer Trusted Library from Intel, don't ask me why) was built to SSL v0.9.6, and it calls EVP_DecryptInit() immediately after declaring the EVP_CIPHER_CTX variable -- this worked fine with v0.9.6, because in that version, EVP_DecryptInit() calls EVP_CipherInit() which, in both 0.9.6 and 0.9.7, initializes the ctx (given that the cipher param is non-null). [This code crashes because of the lack of initialization of the ctx: at the testing of ctx-cipher-nid on line 99 of evp_enc.c -- ctx-cipher being initialized to 0x in the debugging version.] (4) It could be the case that users are now required to call EVP_CIPHER_CTX_init() manually for the decryption phase (only), but the lack of symmetry here strikes me as very unlikely. So, assuming I've got this right, my one line fix would be to change line 239 of crypto\evp\evp_enc.c (in EVP_DecryptInit()) from: return EVP_CipherInit_ex(ctx, cipher, NULL, key, iv, 0); to: return EVP_CipherInit(ctx, cipher, key, iv, 0); Needless to say, if I've misunderstood anything here, I'd appreciate a brief note to that effect. Thanks very much! Oh, not that it matters but: MSVC6 on Windows 2000. Also using on RedHat Linux, but not this function. Agreed, fix being checked in. Thanks for the report. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problem decrypting a signed and then encrypted pkcs7 message on windows 98 using Crypto API
On Thu, Jan 16, 2003, Himanshu Soni wrote: I am running IE 6.0 with cipher strength of 128 bit. Is there an additional security patch that I need to install even if the About Box says that its 128 bit? No you should be OK if it says 128 bit. Can you decrypt 128 bit RC2 encrypted messages and can OpenSSL decrypt 3DES messages from Win98? Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problem decrypting a signed and then encrypted pkcs7 message on windows 98 using Crypto API
On Fri, Jan 17, 2003, Himanshu Soni wrote: 128 Bit rc2 also fails on windows 98. Openssl can successfully decrypt the message on windows 98. Hmmm, strange. Have you tried an alternative certificate for the Win98 recipient? Also what does a signed message look like for that certificate, in particular what SMIMECapabilities do you get, if you aren't sure about that email me a signed message created using that certificate. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problem decrypting a signed and then encrypted pkcs7 message on windows 98 using Crypto API
On Fri, Jan 17, 2003, Himanshu Soni wrote: 128 Bit rc2 also fails on windows 98. Openssl can successfully decrypt the message on windows 98. The email you sent me includes the following: 0:d=0 hl=2 l= 118 cons: SEQUENCE 2:d=1 hl=2 l= 9 prim: OBJECT:S/MIME Capabilities 13:d=1 hl=2 l= 105 cons: SET 15:d=2 hl=2 l= 103 cons: SEQUENCE 17:d=3 hl=2 l= 10 cons: SEQUENCE 19:d=4 hl=2 l= 8 prim: OBJECT:des-ede3-cbc 29:d=3 hl=2 l= 14 cons: SEQUENCE 31:d=4 hl=2 l= 8 prim: OBJECT:rc2-cbc 41:d=4 hl=2 l= 2 prim: INTEGER :80 45:d=3 hl=2 l= 7 cons: SEQUENCE 47:d=4 hl=2 l= 5 prim: OBJECT:des-cbc 54:d=3 hl=2 l= 7 cons: SEQUENCE 56:d=4 hl=2 l= 5 prim: OBJECT:des-cbc 63:d=3 hl=2 l= 13 cons: SEQUENCE 65:d=4 hl=2 l= 8 prim: OBJECT:rc2-cbc 75:d=4 hl=2 l= 1 prim: INTEGER :28 78:d=3 hl=2 l= 7 cons: SEQUENCE 80:d=4 hl=2 l= 5 prim: OBJECT:sha1 87:d=3 hl=2 l= 7 cons: SEQUENCE 89:d=4 hl=2 l= 5 prim: OBJECT:sha1 96:d=3 hl=2 l= 10 cons: SEQUENCE 98:d=4 hl=2 l= 8 prim: OBJECT:md5 108:d=3 hl=2 l= 10 cons: SEQUENCE 110:d=4 hl=2 l= 8 prim: OBJECT:md5 which implies it supports 3DES 128-RC2, DES, 40-RC2. I don't know why its including some ciphers twice though could be the configuration has become confused somewhere. I know that I did try OpenSSL S/MIME messages with MS Outlook express some time ago and it had no problems under Win98. A few more questions. Can you use 128 bit SSL on that machine? Have you tried decrypting messages using Outlook express? Will it decrypt encrypted mesages (not encrypted and signed)? Can it handle encrypted and signed messages from other Windows machines? If it can handle them from other machines try extracting the signed message and using OpenSSL to encrypt it and see if it can handle that. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problem with signing X509 certificate.
On Wed, Jan 22, 2003, Jaco Kroon wrote:
Hallo all
I have a little problem atm where I have to sign certificates. I have both
the private key, and the ca certificate loaded as cacert and cakey
respectively. Here is the part of the code where I suspect
things break.
/*
* Variables to be used:
* X509 *cacert; // contains CA certificate.
* EVP_PKEY *cakey; // contains CA private key.
*/
X509 *usrcert = X509_new();
if(!usrcert)
{
log_ssl_errors(X509_new);
return ERROR_NULL;
}
if(!X509_set_version(usrcert,USRCERTVERSION))
{
log_ssl_errors(X509_set_version);
return ERROR_SSL;
}
if(!X509_set_issuer_name(usrcert,X509_get_subject_name(cacert)))
{
log_ssl_errors(X509_set_issuer_name/X509_get_subject_name);
return ERROR_SSL;
}
X509_gmtime_adj(X509_get_notBefore(usrcert),0);
X509_gmtime_adj(X509_get_notAfter(usrcert),(long)60*60*24*TRIALPERIOD);
X509_NAME *subject = X509_NAME_new();
if(!subject)
{
log_ssl_errors(X509_NAME_new);
return ERROR_NULL;
}
if(
!X509_NAME_add_entry_by_NID(subject,NID_pkcs9_emailAddress,MBSTRING_ASC,(uns
igned char*)email,-1,-1,0) ||
!X509_NAME_add_entry_by_NID(subject,NID_commonName,MBSTRING_ASC,(unsigned
char*)uname,-1,-1,0)
)
{
log_ssl_errors(X509_NAME_add_entry_by_NID);
return ERROR_SSL;
}
if(!X509_set_subject_name(usrcert,subject))
{
log_ssl_errors(X509_set_subject_name);
return ERROR_SSL;
}
X509_NAME_free(subject);
if(!X509_set_pubkey(usrcert,pkey))
{
log_ssl_errors(X509_set_pubkey);
return ERROR_SSL;
}
EVP_MD *dgst = USR_DGST();
res = X509_sign(usrcert,cakey,dgst);
/*
* res now equals 128 - the size of the private rsa key.
*/
I then go ahead and dump the certificate using X509_print and get
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 0 (0x0)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=ZA, ST=Gauteng, L=Pretoria, O=InterExcel, OU=BackupServer,
[EMAIL PROTECTED]
Validity
Not Before: Jan 22 19:20:46 2003 GMT
Not After : Feb 21 19:20:46 2003 GMT
Subject: [EMAIL PROTECTED], CN=6feffc9edd8be3e8
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b9:d5:be:8b:1e:f2:9e:6c:4b:88:5a:84:23:c5:
ec:3e:be:7c:97:1d:e4:c1:f8:c4:45:b5:a6:1e:45:
b9:57:d2:84:36:21:ec:53:35:94:65:18:c9:f8:f5:
ef:da:10:c1:25:14:04:fa:14:77:83:a7:8b:79:ac:
d2:c7:51:f2:6f:8e:83:19:ba:20:8d:ed:96:24:fd:
ad:e9:9c:68:78:92:76:64:c0:b9:54:08:2c:5c:6a:
d0:70:15:75:4c:57:b6:9e:f9:68:b1:44:8e:2a:16:
2e:90:85:73:63:30:43:21:28:f2:46:5d:f7:40:d5:
8a:a5:72:a2:00:0d:f9:7c:d7
Exponent: 65537 (0x10001)
Signature Algorithm: sha1WithRSAEncryption
4c:7b:eb:10:3b:70:7f:d6:96:67:96:2d:55:e6:ce:ab:48:ee:
cc:28:dc:81:9e:2a:b1:80:ac:e5:bf:84:e6:71:b7:56:dd:39:
41:2b:1d:fb:dc:8e:16:85:2a:f0:f7:96:6f:b1:c9:69:38:bc:
46:2e:13:cc:28:5e:95:72:81:81:f7:83:97:80:98:96:35:73:
c7:4e:3b:48:b9:99:60:ae:c8:8f:4f:57:74:73:fb:09:0c:19:
c5:00:37:71:40:1f:cb:2c:3e:11:c5:c8:88:a5:53:f7:d6:61:
e2:f6:76:e7:3b:d8:bb:35:9d:24:21:55:bd:fe:09:81:ee:6b:
70:bc
Which is what I want. Except that when I perform the command openssl
verify -CAfile cacert.pem gencert.pem I get the output:
error 7 at 0 depth lookup:certificate signature failure
And my own program gives more detail:
rsa routines::RSA_verify failed with error code 0x4077068 (bad signature).
asn1 encoding routines::ASN1_verify failed with error code 0xd079006 (bad
get asn1 object call).
Certificate failed.
I output the X509 certificate using PEM_write_X509(stdout,usrcert) which I
then pipe into a file.
One problem is probably that you aren't setting the certificate serial number.
You will get the default of zero which will clash with the CA certificate
serial number. The issuer_name and serial number combination should be unique.
Steve.
--
Dr. Stephen Henson [EMAIL PROTECTED]
OpenSSL Project http://www.openssl.org/~steve/
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: certification path validation suite
On Thu, Jan 23, 2003, Thomas Pornin wrote: Hello, 3. If there is no reference test suite available, should it be assumed that there exists no tested, and, therefore with high probability no correct, implementation of the certification path validation algorithm which handles the policy mappings and name constraints ? There was some debate about how some options in name constraints should be interpreted in the PKIX mailing lists not long ago. This suggests that correct may be subject to interpretation :-) I've never seen a certificate with either name or policy constraints in the field or indeed privately. Examples would be useful to check out any future OpenSSL support for them. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: certification path validation suite
On Mon, Jan 27, 2003, Michael Helm wrote: There are many certs in production use with policy extensions; the VeriSign end entity certs should provide many examples. Yes I know about those. Is there any documentation however on what the VeriSign policy extensions actually *mean*. The last time I looked it had a couple of OIDs in there and some noticeNumbers but I couldn't find any descriptions *anywhere* on what the OIDs or numbers meant. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA Methods based on cyptoAPI
On Fri, Jan 24, 2003, Aonzo Emanuele wrote: Hi, I'm trying to develop some RSA methods based on Microsoft CryptoAPI. I need to know if exists some open source code or example for the implementation of rsa_priv_enc and rsa_priv_dec unsing the private key on a smart card. I've some private code that does this but nothing released. CryptoAPI does not have an equivalent of rsa_priv_enc. It does however have an equivalent to rsa_sign which you can get to in a roundabout way by creating appopriate messages digest contexts and setting the digest value, then signing the context. This will give you enough for general message digest signing (e.g. S/MIME, certificate signing) and SSL client authentication. rsa_priv_dec in theory is provided by CryptDecrypt() and this does work for some CSPs: the enhanced CSP can handle this. However many smart card CSPs do not implement the necessary functionality. Workarounds exist if the CSP handles the conventional key exchange using CryptImportKey() provided you want a standard key size. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #494] 0.9.7 EVP_DecryptInit coredumps if ctx not initialized
On Fri, Feb 07, 2003, Stephen Henson via RT wrote: [[EMAIL PROTECTED] - Fri Feb 7 18:39:43 2003]: Contrary to the documentation EVP_DecryptInit requires the ctx to be initialized in OpenSSL 0.9.7 (RedHat openssl 0.9.7-3 i686) This was fixed a couple of weeks back. The fix is in any 0.9.7 stable snapshot and will appear in 0.9.7. Oops, that shouldof course say 0.9.7a. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problem verifying with SMIME
On Thu, Feb 13, 2003, openssl utilisateur wrote: hi i'm trying to make an application that sign and verify in SMime Format i can sign text file and then verify the signature but the problem is when i try to sign a binary file (*.doc per example) , i can sign this file but when i tried to verify the signature ,the function SMIME_read_PKCS7 could not extract the PKCS7 structure from the signed file i tried to set the flags to PKCS7_BINARY (like in smime.c source code) but i still could not resolve this problem if any one knows how to resolve that thanx The standard OpenSSL MIME generator and parser is a primitive thing that doesn't handle binary data properly. You could encode the binary file in MIME format base64 encoded or use the -nodetach option which will then include the data with the PKCS#7 structure and base64 encode the lot. Alternatively you could fix the parser :-) Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Inconsistent behavior of ECPublicKey_{set,get}_octet_string()?
On Wed, Feb 19, 2003, Eric Cronin wrote:
I am trying to find the analogue of the {i2d,d2i}_{DSA,RSA}PublicKey
functions for ECDSA EC_KEY's. As best I can tell,
i2dECPKParameters+ECPublicKey_get_octet_string and
d2iECPKParameters+ECPublicKey_set_octet_string are the way to do the
encoding/decoding of just the public portions of an EC_KEY. However,
unlike all the other encoding routines in OpenSSL,
ECPublicKey_{set,get}_octet_string() does not advance the supplied
buffer after copying the key to it.
Instead, if *in is non-NULL, it remains pointing to the start of the
copied key after the function returns (In every other encoding routine
I've used *in is advanced to point to the byte after the just encoded
data).
Although the key specific RSAPublicKey and RSAPrivateKey functions follow a
written standard (PKCS#1) the DSAPublicKey and DSAPrivateKey ones AFAIK do
not: they were made up for SSLeay and we're now stuck with them.
Rather than make up a new format that would be incompatible with everything
else I'd prefer it that we didn't have any equivalents at all for newer
algorithms.
The preferred technique for handling all types of public keys is the
{i2d,d2i}_PUBKEY functions and EVP_PKEY. These use the standard certificate
format for public keys. This isn't algorithm specific and there are various
standards that define the formats used.
There are key specific key types such as {i2d,d2i}_RSA_PUBKEY. These just call
the PUBKEY type and insert or extract the algorithm specific key, throwing an
error if the key isn't of the expected type.
The EC equivalents are d2i_EC_PUBKEY and i2d_EC_PUBKEY.
Similarly PKCS#8 is the preferred private key format.
Is there a reason these functions deviates from the normal OpenSSL
behavior? It was hard enough to figure out the unwritten rules of when
the input buffer does and does not get advanced to begin with, and now
if some functions adhere to it and some don't...
A lot more of that stuff is documented since 0.9.7 but not all the EC stuff:
its very new.
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.demon.co.uk/
Email: [EMAIL PROTECTED], PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Inconsistent behavior of ECPublicKey_{set,get}_octet_string()?
On Wed, Feb 19, 2003, Nils Larsch wrote: I guess the reason for this was to simplify the OpenSSL ASN1 macros/ functions (you can call the corresponding de- encode functions in a row, without taking care of the pointer). It was indeed for that purpose. When the old ASN1 code built encoders and decoders by stringing together d2i and i2d functions it avoided having to bloat the code even further by incrementing a pointer after every single call. It doesn't matter as much now because encoders and decoders aren't written like that with the new ASN1 code (though a couple of pathological cases remain) but I suppose were stuck with that behaviour in case anything relies on it. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: CMP (rfc2510)
On Fri, Mar 07, 2003, Frédéric Giudicelli wrote: Hi, I'm planning on developing a fully CMP-support code, should I go ahead or is there somone already working on it ? I can't recall anyone mentioning this. In the case where I should go ahead, shall I use all the available openssl structures, X509_PUBKEY for exemple, although CMP is not linked to X509 ? You should keep to the OpenSSL structure where appropriate. The trick is to work out what appropriate means. For example X509_PUBKEY (SubjectPublicKeyInfo equiv IIRC) has a whole load of support code which encodes and decodes public keys in standard ways. You could use your own but it would need to reimplement the public key logic and be updated for new algorithms. There are also quite a few equivalents to standard structures which at first sight appear to be missing. X509_ALGOR is AlgorithmIdentifier and X509_SIG is DigestInfo for example... By the way, I'ld like to honour the person that fully re-developed the ASN1 layer, I must say that compared to the old code, it's just amazing :). That'll be me then, thank you. All donations gratefully received :-) Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: creating certificate with enhanced key usage extension
On Tue, May 27, 2003, josephine suganthi wrote: Hi, Is it possible to create a certificate with enhanced key usage extension using openssl? What change I have to make on openssl.conf file? Please help me to create a certificate with this extension for my test purpose. Yes it is possible and as mentioned in the FAQ the documentation is in doc/openssl.txt Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RE : RE : Old mail currently unaccessible to me...
On Wed, May 28, 2003, p b wrote: I had made some test: in fact when I changed the iv, I only changed few bits, so the uncrypted file seams to be the same. (whatever the value of iv, only the first bloc change). It's ok. That's expected behaviour for CBC mode. phbgt In the man, when you write EVP_CipherInit always use the phbgt default cipher implementation, is that mean that even using phbgt EVP_get_cipherbyname(aes-256-cbc), the cipher is not set to phbgt aes-256-cbc? With this type of initialisation, EVP_CipherInit use aes-256-cbc. In fact, it seams that there's no default cipher in openssl. What it means is that it uses the default implementation *of that cipher*. This will normally be the builting software version. There can however be multiple implementations of a given cipher for example hardware implementations in ENGINEs. An ENGINE can replace the default implementation so that for example an accelerated hardware version is used by default instead of the software one. It is also possible for an application to specify non default implementations of ciphers if they wish to. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: EVP_SealInit
On Wed, May 28, 2003, p b wrote: In the EVP_SealInit() fonction, the secret key is generated by the random number generator. How can I use my own key ? There's no way to use your own key with that function. You could however use EVP_CipherInit() and call RSA_public_encrypt() manually to get the same effect. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problems with GENERAL_NAMES on IMPLICIT mode
On Thu, May 29, 2003, Fernando Moya wrote:
Hi, I am having problems with GENERAL_NAMES in the following sequence: :
-
DEFINITIONS IMPLICIT TAGS
Seq1 ::= SEQUENCE
{
field1 INTEGER,
field2 Seq2
}
Seq2 ::= SEQUENCE
{
sub_field1 [0] Sub_seq_000 OPTIONAL,
sub_field2 [1] GENERAL_NAMES OPTIONAL,
sub_field3 [2] Sub_seq_200 OPTIONAL
}
-
Implemented by:
ASN1_SEQUENCE(Seq2) = {
ASN1_IMP_OPT(Seq2, Sub_field1, Sub_seq_000,0),
ASN1_IMP_OPT(Seq2, Sub_field2, GENERAL_NAMES,1),
ASN1_IMP_OPT(Seq2, Sub_field3, Sub_seq_200,2),
} ASN1_SEQUENCE_END(Seq2)
IMPLEMENT_ASN1_FUNCTIONS(Seq2)
ASN1_SEQUENCE(Seq1) = {
ASN1_SIMPLE(Seq1, field1,INTEGER),
ASN1_SIMPLE(Seq1, field2, Seq2)
} ASN1_SEQUENCE_END(Seq1)
IMPLEMENT_ASN1_FUNCTIONS(Seq1)
Note: GENERAL_NAMES is defined at crypto/x509v3/x509_v3.h and
crypto/x509v3/v3_genn.c
The point is, I can't obtain [1] tag in GENERAL_NAMES. I have tried to put
GENERAL_NAMES in other situations (always in IMPLICIT mode) and it never
puts tags. En cambio, I have tried in EXPLICIT mode and it works fine, but I
need IMPLICIT tags.
How can I obtain this IMPLICIT tag in DER output?
This is a limitation in the ASN1 code in 0.9.7X. If you have an ASN1 ITEM
template which is something like an IMPLICIT and/or SEQUENCE/SET OF as an
ASN1_ITEM then additional modifiers don't get passed down.
GENERAL_NAMES is a SEQUENCE OF GeneralName which makes it an item template so
an IMPLICIT tag on it wont be processed.
This will be supported directly in 0.9.8 and later.
However in 0.9.7 its easy to work around this by instead using the base type,
with combined modifiers, in this case GENERAL_NAME using SEQUENCE OF and
IMPLICIT together. So instead of doing:
ASN1_IMP_OPT(Seq2, Sub_field2, GENERAL_NAMES,1),
do:
ASN1_IMP_SEQUENCE_OF_OPT(Seq2, Sub_field2, GENERAL_NAME,1),
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.demon.co.uk/
Email: [EMAIL PROTECTED], PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Problems with GENERAL_NAMES on IMPLICIT mode
On Fri, May 30, 2003, Steven Reddie wrote: I think I recall that since GeneralName is a CHOICE that using it with IMPLICIT tags requires the implicit tag to be declared explicitly to avoid ambiguity. I'm not an ASN.1 expert but I've come across this problem before and had to work around it by reversing the implicit tag of GeneralName. I've never been 100% sure of this although I never found a case that disobeyed this rule. If you find anymore out I'd appreciate hearing about it. While that's correct this case refers to GeneralNames not GeneralName. Since GeneralNames is a SEQUENCE OF GeneralName and has a SEQUENCE tag it can have an IMPLICIT tag itself because that would change the SEQUENCE tag which is not ambiguous. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Welcome to my hometown
As should be apparent from the headers, I didn't send that... irony Thank you to all the virus scanners which seem to thing otherwise. /irony Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: MS CAPI OpenSSL Engine?
On Tue, Jun 10, 2003, Bryce Howard wrote: I was afraid I was duplicating something else out there, seems that this is not so. I will clean up the code a bit this week and submit it with the method that Geoff suggested. I have also written a CAPI ENGINE but it had to do various evil things to support the necessary functionality (such as writing ctrl data to stdout) so I didn't want to release it lest such foul hacks should define a 'standard'. One problem was finding a generic way to return values from ctrls in an ENGINE without implementation specific ctrls. I wouldn't recommend use of X509_LOOKUP, it is fatally broken and due to be replaced in 0.9.8 and later. This could be a good test for the new store functionality. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: pkcs#12 creation with secret bags
On Mon, Jun 23, 2003, Claude CONVERT wrote: Hi all I try to create a pkcs#12 with several secret bags. I haven't found any sample which indicates how to do this and especially how to create a secret bag. I try the following code, but it doesn't work : PKCS12_SAFEBAG *safebag; ASN1_OCTET_STRING *os; ASN1_TYPE *at; char pData[]=secret data; int dataLen=sizeof(pData); int mySecretNid; os=ASN1_OCTET_STRING_new(); ASN1_OCTET_STRING_set(os, pData, dataLen); at=ASN1_TYPE_new(); ASN1_TYPE_set(at,os-type,(char *)os); mySecretNid=OBJ_create(1.2.3.4,OID_MY_SECRET_DATA,My secret data OID); safebag=PKCS12_item_pack_safebag(at, ASN1_ITEM_rptr(ASN1_OCTET_STRING), mySecretNid, NID_secretBag); I think that the problem is due to the ASN1_ITEM_rptr(ASN1_OCTET_STRING) parameter, but i don't know what to pass else ? ASN1_ITEM_rptr(ASN1_TYPE) is not implemented. Well I've never actually seen anyone use a secretBag or any kind of published standard for it. The PKCS#12 spec just leaves this type open with no OID definitions at all. With the caveat that this is totally untested... I'd say what you are doing is largely correct apart from the ASN1_TYPE stuff you mention. The itemt for ASN1_TYPE isn't names ASN1_TYPE but ASN1_ANY because its effectively the ASN1 ANY type. I suggest you try that. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: d2i and ASN1_CHOICE
On Thu, Jun 26, 2003, Fernando Moya wrote:
Hi, I am having problems with CHOICE in the following ASN.1 sequence:
-
DEFINITIONS IMPLICIT TAGS
Sub_seq200 ::= SEQUENCE
{
sub_field1 Sub_seq100 OPTIONAL,
sub_field2 [0] Sub_seq400 OPTIONAL
}
Seq1 ::= CHOICE
{
field1 Sub_seq100,
field2 [0] Sub_seq200
}
-
Implemented by:
typedef struct Sub_seq200_st
{
Sub_seq100 *sub_field1;
Sub_seq200 *sub_field2;
}Sub_seq200;
typedef struct Seq1_st
{
int type;
union {
char *ptr;
Sub_seq100 *field1;
Sub_seq200 *field2;
}value;
}Seq1;
ASN1_SEQUENCE(Sub_seq200) = {
ASN1_OPT(Sub_seq200,sub_field1, Sub_seq100),
ASN1_IMP_OPT(Sub_seq200,sub_field2, Sub_seq400,0),
} ASN1_SEQUENCE_END(Sub_seq200)
IMPLEMENT_ASN1_FUNCTIONS(Sub_seq200)
ASN1_CHOICE(Seq1) = {
ASN1_SIMPLE(Seq1, value.field1,Sub_seq100),
ASN1_IMP(Seq1, value.field2,Sub_seq200, 0)
} ASN1_CHOICE_END(Seq1)
IMPLEMENT_ASN1_FUNCTIONS(Seq1)
Well, Seq1_new, Seq1_free and i2d_Seq1 functions work correctly and DER
output is right, but when I call d2i_Seq1 with DER output from i2d_Seq1, it
returns NULL. I think it could be an incorrect definition of
ASN1_CHOICE(Seq1).
Does Anybody know what is wrong?
See what error message you get with ERR_print_errors_fp(srderr);
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.demon.co.uk/
Email: [EMAIL PROTECTED], PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: d2i and ASN1_CHOICE
On Thu, Jun 26, 2003, Frank Balluffi wrote: Fernando, I think all user-defined tags in a CHOICE (e.g., [0]) are EXPLICIT -- I could be wrong and don't have time to check right now (it's been a while ...). So I think you want: ASN1_EXP(Seq1, value.field2,Sub_seq200, 0) The default is EXPLICIT but the ASN1 module can change the default to IMPLICIT. IMPLIICT also must become EXPLICIT if its needed for disambiguiation, for example if the underlying type is a CHOICE. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Need Help in separating out DH from libcrypto.a
On Wed, Jul 30, 2003, Bala Pitchandi wrote: Hello All, I am a newbie to OpenSSL and I have been trying to separate just the DH algorithm from the whole package and build it in a different OS (RTEMS, a POSIX compliant, Linux-like OS) using GCC Cross Compiler. I have been trying to find out the dependencies of DH with the other libraries - and so far all I could find is that it uses bn. And I have copied all the files from DH (openssl-0.9.7b\crypto\dh) and BN (openssl-0.9.7b\crypto\bn). I have also copied all the header files over to this new directory so that it finds all the needed files right there. And I am using jam to build this new library. I have not defined any CFLAGS for the compiler. But for some reason, I could not get the code to compile. It gives syntactical errors like: In file included from ../../../../openssl/include/cryptlib.h:67, from ../../../../openssl/dh_asn1.c:60: ../../../../openssl/include/crypto.h:194: parse error before `STACK' ../../../../openssl/include/crypto.h:194: warning: no semicolon at end of struct or union Am I missing something obvious here? Any help would be greatly appreciated. If you need the DH ANS1 structures then you'll need the ASN1 library which will pull in crypto/asn1, crypto/objects, crypto/stack and lots of other stuff. If you don't want that then don't compile dh_asn1.c Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Going from 0.9.6 to 0.9.7
On Thu, Jul 31, 2003, Samuel Meder wrote: I'm currently working on updating our code to work with 0.9.7 and am hitting a few snags: * Handling of critical extensions has changed (no big deal, just needed to make our code tell openssl to ignore critical extensions) * I know get a core dump when trying to print a extension written against the ASN1 code in 0.9.6 (extension is described in http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-07.txt). The same code works fine with 0.9.6. A stack trace from the dump: #0 0x40131060 in ASN1_item_ex_d2i (pval=0xbfffefac, in=0xb008, len=14, it=0x40056aeb, tag=-1, aclass=0, opt=0 '\0', ctx=0xbfffefb0) at tasn_dec.c:148 148 if(aux aux-asn1_cb) asn1_cb = aux-asn1_cb; (gdb) where #0 0x40131060 in ASN1_item_ex_d2i (pval=0xbfffefac, in=0xb008, len=14, it=0x40056aeb, tag=-1, aclass=0, opt=0 '\0', ctx=0xbfffefb0) at tasn_dec.c:148 #1 0x40130fc8 in ASN1_item_d2i (pval=0xbfffefac, in=0xb008, len=14, it=0x40056aeb) at tasn_dec.c:115 #2 0x40149b2a in X509V3_EXT_print (out=0x805d368, ext=0x805c9e8, flag=0, indent=12) at v3_prn.c:119 #3 0x40149e07 in X509V3_extensions_print (bp=0x805d368, title=0x4018c08b X509v3 extensions, exts=0x805c4f8, flag=0, indent=12) at v3_prn.c:187 #4 0x4012cbb4 in X509_print_ex (bp=0x805d368, x=0x805b2f0, nmflags=0, cflag=0) at t_x509.c:238 #5 0x4012c53b in X509_print_ex_fp (fp=0x402ecc40, x=0x805b2f0, nmflag=0, cflag=0) at t_x509.c:90 #6 0x4012c4ba in X509_print_fp (fp=0x402ecc40, x=0x805b2f0) at t_x509.c:76 #7 0x08049f9f in main (argc=2, argv=0xba04) at grid_proxy_info.c:522 Any ideas? Hard to tell without seeing your code. What extension does it implement? 0.9.6 ASN1 code should work with 0.9.7 but that hasn't been extensively tested. The old ASN1 did some horrible things which was one reason why it was replaced. The X509V3_EXT structure has a new ASN1_ITEM field in it. Make sure that is set to NULL. You might try converting the ASN1 module to 0.9.7 standard, that should be fairly painless (see the examples all over the new code). Another question I have is whether there is a official end-of-life date for 0.9.6? Only bug fixes will be committed to 0.9.6 and then only fairly critical ones. It will still be supported (for some value of supported) for a while yet though but any new code is strongly advised to use 0.9.7. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Going from 0.9.6 to 0.9.7
On Thu, Jul 31, 2003, Samuel Meder wrote:
On Thu, 2003-07-31 at 15:25, Dr. Stephen Henson wrote:
ProxyCertInfoExtension ::= SEQUENCE {
pCPathLenConstraint ProxyCertPathLengthConstraint
OPTIONAL,
proxyPolicy ProxyPolicy }
ProxyCertPathLengthConstraint ::= INTEGER
ProxyPolicy ::= SEQUENCE {
policyLanguage OBJECT IDENTIFIER,
policy OCTET STRING OPTIONAL }
0.9.6 ASN1 code should work with 0.9.7 but that hasn't been extensively
tested. The old ASN1 did some horrible things which was one reason why it was
replaced.
The X509V3_EXT structure has a new ASN1_ITEM field in it. Make sure that is
set to NULL.
Ahh, that fixed it. Many thanks.
You might try converting the ASN1 module to 0.9.7 standard, that should be
fairly painless (see the examples all over the new code).
I will eventually. Just wanted to get things to work quickly.
It should be very easy to implement that once you get the hang of the new
code. For example:
ASN1_SEQUENCE(ProxyPolicy) = {
ASN1_SIMPLE(ProxyPolicy, policyLanguage, ASN1_OBJECT),
ASN1_OPT(ProxyPolicy, policy, ASN1_OCTET_STRING)
} ASN1_SEQUENCE_END(ProxyPolicy)
ASN1_SEQUENCE(ProxyCertInfoExtension) = {
ASN1_OPT(ProxyCertInfoExtension, pCPathlenContraint, ASN1_INTEGER),
ASN1_SIMPLE(ProxyCertInfoExtension, proxyPolicy, ProxyPolicy)
} ASN1_SEQUENCE_END(ProxyCertInfoExtension)
Then in the header:
DECLARE_ASN1_ITEM(ProxyCertInfoExtension)
Totally untested but that's not far from what should work.
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.demon.co.uk/
Email: [EMAIL PROTECTED], PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: BUG: CreateToolhelp32Snapshot
On Thu, Aug 07, 2003, Richard Levitte - VMS Whacker wrote: In message [EMAIL PROTECTED] on Thu, 07 Aug 2003 11:12:59 +0100, Martin Kochanski [EMAIL PROTECTED] said: [Toolhelp stuff] Haven't been following this thread too closely but I've a vague recollection that ages ago when I did an OpenSSL WinCE port (before toolhelp was dynamically linked) that the compilation choked because one of the function prototypes had changed between Win32 and WinCE (extra argument IIRC). I don't have any of the headers with me but it might be worth checking out. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Subject Attribute Email has no known NID, skipped
On Sun, Aug 31, 2003, Christian Barmala wrote: Hi Stephen, thank you for your fast reply. - Original Message - From: Dr. Stephen Henson [EMAIL PROTECTED] Sent: Sunday, August 31, 2003 3:30 PM When I use Email I get the Error Message: Subject Attribute Email has no known NID, skipped I think that is a bug... Good to know that I don't have to search for the error on my side any longer. Email has been deleted as a short name in objects.txt between 0.9.6 and 0.9.7, I'll checkthe logs to see the reason. When I use emailAddress the certificate request is for the subject C=DE, ST=Nordrheinwestfalen, L=Oberhausen, O=ABCGmbH, OU=Internet, CN=User/[EMAIL PROTECTED] (/emailAddress is considered part of the CN) It isn't part of the CN, that's just how its displayed: read the FAQ. http://www.openssl.org/support/faq.html doesn't contain the string email and only one instance of CN, which covers a different topic. http://www.openssl.org/support/faq.html#USER13 also covers a different topic. #13 is actually the right topic. That odd email display is a symptom of the old behaviour. Though it could be clearer. -nameopt oneline or -nameopt multiline produces a more sensible output. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Subject Attribute Email has no known NID, skipped
On Sun, Aug 31, 2003, Christian Barmala wrote: Hi, I try to create a certificate request with OpenSSL 0.9.7b openssl req -subj /C=DE/ST=Nordrheinwestfalen/L=Oberhausen/O=ABCGmbH/OU=Internet/CN=User /[EMAIL PROTECTED] or ... /[EMAIL PROTECTED] This should be correct, because objects.h define #define SN_pkcs9_emailAddress Email #define LN_pkcs9_emailAddress emailAddress When I use Email I get the Error Message: Subject Attribute Email has no known NID, skipped I think that is a bug... When I use emailAddress the certificate request is for the subject C=DE, ST=Nordrheinwestfalen, L=Oberhausen, O=ABCGmbH, OU=Internet, CN=User/[EMAIL PROTECTED] (/emailAddress is considered part of the CN) It isn't part of the CN, that's just how its displayed: read the FAQ. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSAUTL and PASSIN
On Mon, Sep 15, 2003, Andrew Stickland wrote: Hi, I've encountered a problem with openssl rsautl in that I need to use the sign function and submit the passphrase from another application. On Unix I could use an 'expect' but even that would be rather dirty and I'm not on Unix for this project. I could decrypt the private key to disk and use it but this has security implications. This has been raised before on this forum but I've not found a satisfactory answer. As a rusty C programmer I've had a look at the rsa.c code in \apps - couldn't the app_passwd(bio_err, passargin, passargout, passin, passout) functionality be added to rsautl and 'passin' handed to load_key()? As I said, I'm rusty so I may have overlooked obvious problems with this. I look forward to your responses. Yes it could be done (I may look into it if I ever get any time...) there's a minor complication in that you get an EVP_PKEY structure back from load_key() which you have to extract the RSA structure from (checking first that it really is and RSA key). Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSAUTL and PASSIN
On Tue, Sep 16, 2003, Andrew Stickland wrote: Steve, Thanks for the response. I think that rsautl already uses load_key() so the EVP_PKEY structure should already be handled. What's the policy on contributed source code from outside the core group - I'd be willing to have a stab at this if it's acceptable. We welcome external contributions, though those from the US have to comply with the export regulations (CCing contributions to tthe relevant address). I'd forgotten that it already used EVP_PKEY. That should make adding support for -passin trivial: just copy the code from the 'smime' utility which does the same thing. I'll look into that. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: PKCS7 Des key parity
On Fri, Sep 26, 2003, Robin Ehrlich wrote: I have an application using the OpenSSL S/MIME interface. When I generate an encryptred message using DES, the DES key generated does not have odd parity. The key is generated in pk7_doit.c:PKCS7_dataInit by calling RAND_bytes(). In testing interoperability with the NIST S/MIME test center, the message is rejected. I know that odd parity is not a DES requirement, but DES keys should have odd parity. What is the best way to fix this problem? Can some code be added to the next OpenSSL release to do this? Probably the best way is to add a flag to EVP_CIPHER which indicates that the key needs odd parity and then check the flag when a random key is generated and fix it up appropriately. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Adding additional S/MIME signed attributes
On Fri, Sep 26, 2003, Robin Ehrlich wrote: I would like to be able to add some of my own S/MIME signed attributes based on characteristics of the message. Could a callback procedure be added to pk7_smime.c:PKCS7_sign() to support such a feature? PKCS7_sign() is meant to be a simple PKCS#7 signer which just (hopefully) does all the right things. Things like adding custom signed attributes can be done using the low level API which the source to PKCS7_sign() uses. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Defect? regarding Session ID's
On Fri, Sep 26, 2003, Verdon Walker wrote: I noticed a small inconsistency in OpenSSL. According to the OpenSSL documentation, applications that want to resume sessions should call SSL_CTX_set_session_id_context() to provide a unique identifier to be stored with their session caches. However, observing the behavior of OpenSSL and looking at the following code (ssl_sess.c : ssl_get_prev_session): if((s-verify_modeSSL_VERIFY_PEER) (!s-sid_ctx_length || ret-sid_ctx_length != s-sid_ctx_length || memcmp(ret-sid_ctx,s-sid_ctx,ret-sid_ctx_length))) it appears that session id's are not always checked when resuming sessions. For a server implementation, they are only checked if mutual authentication is turned on. The code should really either check the session id anytime it is being reused or ignore it always if it is not set. I'm not sure which is better, but I am sure the code should be consistent. This is actually there to protect against a case where a malicious client could resume a session in an inappropriate context. This only affects sessions that enable client authentication so it is only checked in those cases. This was addressed way back in March 1999. For more details see: http://www.mail-archive.com/[EMAIL PROTECTED]/msg1.html Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSLv23 always makes a V2ClientHello, no matter what...
On Tue, Oct 07, 2003, Richard Levitte - VMS Whacker wrote: As has been seen in my last few commits, I got a bit obsessed with compression. The way it works now, at least in 0.9.8-dev, is compliant with draft-ietf-tls-compression-05.txt, as far as I can tell. Interesting. Is it still stateless or does it retain the compression state for improved performance? The only thing that remains is something that itches me quite a bit. As soon as SSLv23 is used, we can kiss compression goodbye, even if SSLv2 has been disabled. Maybe one for the TLS mailing list? I can think of ways to do this such as dummy ciphersuites etc but it would need to be standardised. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSLv23 always makes a V2ClientHello, no matter what...
On Wed, Oct 08, 2003, Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Tue, 7 Oct 2003 19:16:59 +0200, Dr. Stephen
Henson [EMAIL PROTECTED] said:
steve On Tue, Oct 07, 2003, Richard Levitte - VMS Whacker wrote:
steve
steve As has been seen in my last few commits, I got a bit obsessed with
steve compression. The way it works now, at least in 0.9.8-dev, is
steve compliant with draft-ietf-tls-compression-05.txt, as far as I can
steve tell.
steve
steve Interesting. Is it still stateless or does it retain the
steve compression state for improved performance?
It's stateful, as required by that draft.
I'll have to look at that. I've got some non-blocking zlib BIO code which is
probably best reimplemented using the compression method stuff: assuming its
flexible enough.
steve The only thing that remains is something that itches me quite a bit.
steve As soon as SSLv23 is used, we can kiss compression goodbye, even if
steve SSLv2 has been disabled.
steve
steve
steve Maybe one for the TLS mailing list? I can think of ways to do
steve this such as dummy ciphersuites etc but it would need to be
steve standardised.
I think that part is already answered by the following, taken from
appendix E in RFC 2246:
Ah, I'm itcing on a different thing then :-)
I was thinking that there should be a way to represent supported compression
methods in the v2 client hello. For example RFC2246 appendix E again has a
general way of representing a V3 ciphersuite as a V2 one:
V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
something like:
V2CipherSpec (see TLS name) = { 0xXX, 0xXX, CompressionMethod };
I suspect the reason this hasn't been done is that hardly anyone has
implemented compression so far.
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.demon.co.uk/
Email: [EMAIL PROTECTED], PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Proposed modification for Extension Parser
On Mon, Oct 13, 2003, Frédéric Giudicelli wrote: Hello, The following problem is well known, it's about commas in url for extensions' value. Here is what a normal LDAP syntax should be: ldap://host/uid=ca,ou=CAs,dc=host,dc=org?certificateRevocationList But since the openssl conf parser interprets the commas as a value serparator, the ldap syntax becomes: ldap://host/uid=ca/ou=CAs/dc=host/dc=org?certificateRevocationList However many clients do not understand this syntax (IE for example, sorry :) ). After cheking the code the problem comes from this function X509V3_parse_list in crypto/x509v3/v3_utl.c. I propose to enable commas in extensions syntax by doubling them, so that the syntax becomes something like this: ldap://host/uid=ca,,ou=CAs,,dc=host,,dc=org?certificateRevocationList This doesn't change the current interpretation since the second comma would generate an empty value. This patch has been generated from openssl 0.9.7b. This is unnecessary. Commas are only interpreted as value separators in the single line extension format. If you use the multiline format as documented in openssl.cnf commas have no special meaning and can readily be included. For example: [EMAIL PROTECTED] [altsect] URI=ldap://foo=x,bar=y should be OK. Check the docs for the exact syntax. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email addresses, PGP and S/MIME: see homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Proposed modification for Extension Parser
On Mon, Oct 13, 2003, Frédéric Giudicelli wrote:
Ok, here is the code that I use to add extensions to a to-be-signed
certificate:
bool PKI_CERT::Add_CertExtensions(const HashTable_String * Ext, X509V3_CTX
*ctx, X509 *cert) const
{
X509_EXTENSION *ext;
long i;
const char * name;
const char * value;
for(i=0;iExt-EntriesCount();i++)
{
name=Ext-GetName(i);
value=Ext-Get(i);
if(!name || !value) continue;
if(!(ext = X509V3_EXT_conf(NULL, ctx, (char*)name, (char*)value)))
{
return false;
}
if(!X509_add_ext(cert, ext, -1))
{
X509_EXTENSION_free(ext);
return false;
}
X509_EXTENSION_free(ext);
}
return true;
}
Typicaly name and values would have a value something like this
name=crlDistributionPoint
value=URI:ldap://host/uid=ca,ou=CAs,dc=host,dc=org?certificateRevocationLis
t
As you can see I use X509V3_EXT_conf, and I pass NULL for the LHASH
parameter.
I use X509V3_EXT_conf, because I am not really desiring to reimplement the
10 functions that are below X509V3_EXT_conf, just to change one line in
X509V3_parse_list. That would just not be a great idea, I don't want to have
to maintain code that belongs to OpenSSL.
You have several options. You can populate the structure yourself and the add
it to the certificate using X509_add_ext_i2d() then you can use whatever
syntax you want.
Alternatively you can use the NCONF code to write your own handler and use
X509V3_EXT_nconf() instead: new code should used the nconf variants anyway.
You'll have to do this if you want to handle more complex extensions like
CertificatePolicies or for the new functionality like the dirName forms such
as subjectAltName in 0.9.8.
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.demon.co.uk/
Email addresses, PGP and S/MIME: see homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: your mail
On Thu, Oct 23, 2003, Pierre De Boeck wrote: Hi all, I just try to recompile my openssl applications with the 0.9.7c and the PKCS12_decrypt_d2i function no longer exist. I can use my own decrypt/d2i function but I would prefer to use what OpenSSL provides as a replacement, if any. Any idea? This undocumented function used the (now obsolete) old ASN1 functions. The equivalent is PKCS12_item_decrypt_d2i() which uses the new ASN1 functionality. It shouldn't be too hard to use the new function unless you are using you own ASN1 module. If you are you should convert that to the new format. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email addresses, PGP and S/MIME: see homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Question about EVP_PKEY, X509 and certificates
On Wed, Nov 12, 2003, Geoffrey Huang wrote: Hi there, I'm new to using OpenSSL. I've gathered that the EVP* structures are the high-level structures that OpenSSL prefers me to use. Specifically, I'm using the EVP_PKEY structure to store key pairs in an internal database - it's flexible enough to store RSA and DSA keys. Anyhoo, so here's what I'm trying to do. Given a certificate presented to me (possibly over the network, possibly in a file), I want to store the public key in an EVP_PKEY structure. Any suggestions for the best way to do this? I'm trying to call d2i_X509_PKEY() on the raw cert. This should give me an X509_PKEY structure. Now, how to get the public key and go back to EVP_PKEY? First this should be in openssl-users not openssl-dev. You can use the function X509_get_pubkey() to get an EVP_PKEY structure from an X509 object, that will contain the public key. From there you can use the PUBKEY functions such as i2d_PUBKEY() and so on. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: ASN1 implicit/explicit tagging
On Fri, Nov 14, 2003, Pierre De Boeck wrote:
Hi all,
I have 2 versions of a DER-encoded pkcs7-enveloped-data and I would
like to know which one is correct:
I have attached their printable parsed form and they only differ
in one point, namely at the
EnvelopedData.encryptedContentInfo.encryptedContent component:
- the verExpl.txt encodes it as
[0] {
368 04 1312: OCTET STRING
: FE FE 9F 9C C5 C7 FC 28 FD B0 BA 4B 08 AF AD 3C
: E3 05 A6 89 FF 8A 9A C7 48 FC CC 7B 98 31 DA 3D
: F0 6A 82 6B 7A 47 32 53 F5 C6 F1 39 6B 77 C6 FE
: 8E B0 01 F4 15 9C 51 4A 72 12 71 51 5C 10 BC D4
: 9E F4 AD E5 B3 B1 B9 7F D5 26 BD E1 44 13 24 DD
: 30 A1 32 63 2D 65 B6 71 64 09 52 32 0D FB 6A 65
: 8F 71 86 72 C3 13 61 37 F4 EF E6 73 92 DB F5 7E
: 23 79 82 64 C6 4A 7B 3F BD 3A F6 6B C9 EE A9 14
: [ Another 1184 bytes skipped ]
: }
while the verImpl.txt encodes it as
[0]
: 19 83 FD 11 13 B8 20 3C ED C9 CB B7 3F 06 97 3B
: 46 C7 03 09 FE 24 B8 7B 1D B7 DD F6 05 68 81 85
: B4 21 70 95 6B AB A7 33 54 77 00 F5 D7 CC FC 5F
: 18 47 7E 63 41 94 22 A9 C7 5C 56 09 89 49 BD C7
: 67 D8 9B 48 82 B7 4B 64 F8 D9 11 F3 F8 AE 04 81
: E7 C1 4F 37 F0 37 36 D0 A3 B1 A9 DB 67 09 C1 64
: B6 E0 4B 2D 2A D6 47 2C 24 49 D5 7A 5E 4B 6F FF
: 0E 6E 8B D8 8E 58 85 E9 76 41 02 7D A1 A3 D4 AD
: [ Another 1192 bytes skipped ]
If I check the grammar of that objetct ([0] IMPLICIT EncryptedContent
OPTIONAL),
it seems that it is the verImpl.txt that is correct since IMPLICIT tagging
is used.
Am I correct?
Well yes and no. If it was an IMPLICIT and EXPLICIT issue then yes it should
be IMPLICIT. However from your attachment:
366 A0 NDEF: [0] {
368 04 1312: OCTET STRING
: FE FE 9F 9C C5 C7 FC 28 FD B0 BA 4B 08 AF AD 3C
: E3 05 A6 89 FF 8A 9A C7 48 FC CC 7B 98 31 DA 3D
: F0 6A 82 6B 7A 47 32 53 F5 C6 F1 39 6B 77 C6 FE
: 8E B0 01 F4 15 9C 51 4A 72 12 71 51 5C 10 BC D4
: 9E F4 AD E5 B3 B1 B9 7F D5 26 BD E1 44 13 24 DD
: 30 A1 32 63 2D 65 B6 71 64 09 52 32 0D FB 6A 65
: 8F 71 86 72 C3 13 61 37 F4 EF E6 73 92 DB F5 7E
: 23 79 82 64 C6 4A 7B 3F BD 3A F6 6B C9 EE A9 14
: [ Another 1184 bytes skipped ]
The first thing to notice here is that NDEF. This is therefore not DER but
BER: NDEF is not allowed in DER.
That might indeed be an explicitly tagged octet string with an indefinte length
construted outer tag enclosing a definite length octet string. That would be
wrong, however I'd say that isn't the case here.
What IMHO is much more likely is that it is an implicitly tagged indefinite
length *constructed* octet string which would be perfectly acceptable.
It isn't actually possible to distinguish between the two because they both
have the same encoding.
So the probable answer to you question is that if DER is not compulsory then
both are correct.
Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: ASN1 implicit/explicit tagging
On Fri, Nov 14, 2003, Pierre De Boeck wrote: Ok, I think that PKCS7 accepts both DER and BER. Yes it does. BER is used for streamed content. Though some profiles may require DER. So I suppose that the verImpl.txt is perfectly legal. Right? They are both legal. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Openssl time bugs
On Sat, Nov 15, 2003, David wrote: These bugs all appear to be mostly cosmetic, but they leave me wondering what the latest valid expiration date is and whether the generated certificate is actually valid. The problems are largely based around the behaviour of the system time libraries and things like time_t when it overflows or becomes negative. What actually happens seems to be undefined. To get more consistent behaviour OpenSSL should really do its own date calculations without the inbuilt limitations and unpredictability of system library routines. FYI, I'm working on being my own CA and generating certs to go in some embedded systems, so long expirations are A Good Thing for me. Is there any way to make certs that never expire? No there isn't but you should be able to safely set one with a 30 year expiry date. Many existing key sizes will be ridiculously insecure well before then I suspect... The actual dates in certificates can theoretically go up to the year . Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Certificte extensions: thoughts.
[EMAIL PROTECTED] wrote:
Currently V3 extension support is almost absent.
We've done almost all of what you're suggesting:
typedef struct x509_extension_method_st
{
int nid;
void (*clear)();
int (*get_bool)(); // used if extn is ASN1_BIT_STRING
int (*set_bool)();
int (*get_str)(); // used if extn is ASN1_STRING or array of them
int (*set_str)();
char *(*get_struct)(); // used if extn is constructed type
int (*set_struct)();
ASN1_OCTET_STRING *(*a2i)();
int (*i2a)();
} X509_EXTENSION_METHOD;
We've integrated this into the X509 code (i.e., for Certs and CRL's), as
well as
the req and ca apps. For example, here's a snippet from a config file:
[ gto_root_extensions ]
keyUsage = critical|nonRepudiation|digitalSignature|keyCertSign
certificatePolicies =
critical,2.16.840.1.113731.9.2.1,cps,http://www.gto.com/cps
basicConstraints = critical,TRUE
authorityInfoAccess = id-ad-ocspResponder,http://www.gto.com/ocspv1
(We've got a good chunk, but not all, of the PKIX extensions implemented.)
We'd love to see this code adopted by the project. We've held back from
being public
before because we were waiting to hear back from Eric -- we wanted to avoid
version
and architecture skew. But since things are open right now...
I've been developing things along the lines I mentioned myself. I've
currently got support for strings, bit strings and basicConstraints and
it will happily print out things like:
Netscape Comment:
THIS IS A TEST CERTIFICATE
X509v3 Extended Key Usage:
2.16.840.1.113733.1.8.1, 2.16.840.1.113730.4.1
X509v3 Basic Constraints:
CA=TRUE, pathlen=10
Netscape Cert Type:
SSL CA, S/MIME CA, Object Signing CA
I didn't precisely want to follow what it looked like Eric intended
because it seemed that the a2i,i2a stuff would be duplicating a lot of
code. Just passing it a STACK of name+value pairs and having some
higher level wrappers decompose the config file into the name+value
parts would make the writing of individual extension code much easier.
It seems that almost any extension can be represented in this way.
There are a few exceptions: e.g. those whose values vary from one
request to another (e.g. subjectAltName, various hash based
identifiers).
The reason I mentioned a separate section for this stuff is that it's
the easiest way with the current config stuff to handle things. The
method where you do:
basicConstraints=section_name
[section_name]
CA=TRUE
pathlen=10
allows the STACK of name+value pairs to be easily obtained using the
current config lib stuff.
Although simple this is a bit messy and parsing a comma separated list
of options would be better e.g.
basicConstraints=CA:TRUE,pathlen:10
In my proposal this would just need a cleverer wrapper: the individual
extension code would be unchanged.
Any code you wish to donate would be of course welcome. Particularly for
some of the nastier extensions.
Steve.
--
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant.
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [EMAIL PROTECTED]
NOTE NEW (13/12/98) PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Using two certificates: s_server -dcert -dkey options.
Something which may be of interest is the behaviour of the (currently) undocumented -dcert and -dkey options of s_server. This may not have been mentioned before so better to mention it twice than not at all :-) What these options do is to allow s_server to use two certificates of different types. The 'd' is presumably meant to mean "DSA" but it doesn't really distinguish: its just a way of feeding in another cert and key. Why is this useful? Well if a server has a DSA certificate then the non-RSA modes can be used: so clients don't need to support RSA and "patent free" clients can connect. However if it only has a DSA certificate then the normal (browser) RSA modes cannot be used. If it has both then both can be used. All this means for people using OpenSSL in a server is that it is advisable to permit the use of two certificates and private keys so they can take advantage of this behaviour. Steve. -- Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. For info see homepage at http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED] NOTE NEW (13/12/98) PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Documentation
Sameer Parekh wrote: d) The OpenSSL project should not allow US persons to contribute to the OpenSSL source code. This would be the easiest way to handle things but it might be regarded as over cautious. There are some non crypto areas of OpenSSL where US persons might be able to contribute without breaching US law. Examples would be certificate extension code, message digest algorithms or stuff related to authentication only (e.g. DSS). Or do you think even contributions of this sort could cause problems? Steve. -- Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. For info see homepage at http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED] NOTE NEW (13/12/98) PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: building the latest sources on windows nt
Tom Titchener wrote: Open SSL Developers - 1) When I copy over or unzip from the cvs hierarchy, the protections on the crypto/x509v3/old_v3 directory files always prevent the copy. It's safe to ignore this. Nothing gets built in this directory anyway. Yep that's just legacy stuff. 2) You need to create a date.h file by hand in the crypto directory. If you're running a real shell, you can type the line from the makefile.ssl, e.g.: $ cd crypto $ echo "#define DATE \"`date`\"" date.h Yep. I'll get the perl config script to do this automatically sometime. 3) The version of perl I'm running doesn't like this bit of syntax in the top-level configure source: [example deleted] The version of perl I'm running is: $ perl -version This is perl, version 5.002 with DEBUGGING EMBED My version is 5.004_02 and it has no problems with this. 5) Running configure converts the generic (.org) versions of files to local versions according to your configuration. However there's one that gets forgotten--pem.org. Fortunately, pem.org is the same as pem.h, so you just need to $ cd to crypto/pem $ cp pem.org pem.h I'm not sure they are the same. They are almost the same except for a few architecture specific #defines with the size of structures. You can simulate what other Makes do by building the ctx_size program and doing ctx_size pem.org pem.h I think the simplest way to handle this is to hard code the right values in the config script for those architectures that need it. 7) Next you wanna create your ntdll.mak file: $ perl util/mk1mf.pl dll VC-WIN32 ms/ntdll.mak 8) And your two .def files (there are lots of new source modules): $ perl util/mkdef.pl 32 ssleay ms/ssleay32.def $ perl util/mkdef.pl 32 libeay ms/libeay32.def The batch file ms\do_ms does this. It shouldn't really because not many people have the assembler 'ml'. If you don't have the assembler then: perl util\mk1mf.pl no-asm dll VC-WIN32 ms\ntdll.mak will build the makefile without assembly language stuff. That's it, now you *should* be able to type $ nmake -f ms/ntdll.mak There are still some legacy issues in the Windows stuff: the main application is still called 'ssleay' and the DLL's have EAY in their names. Just a few additional comments. The Windows stuff may occasionally fall behind the main stuff from time to time. Until recently attempting to get this stuff to compile under Win32 at all was a non starter: I spent an annoying amount of time fixing it up. If it doesn't seem to compile right or misses files out then it may be that the tarball doesn't have the latest Win32 stuff. In this case you need to do a: "make files" at the top level to rebuild the MINFO file (which is where the makefiles come from). You might have to do this from Unix. If the mkdef.pl stuff complains about missing functions and the compile fails due to undefined symbols try adding the undefined functions to the end of util/*.num files. Note: if you do this then there is no guarantee that the numbers will match those when the main distribution is fixed, in which case you will need to recompile anything linked against the incompatible DLL. Steve. -- Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. For info see homepage at http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED] NOTE NEW (13/12/98) PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Makefiles
Josh MacDonald wrote: To solve your Makefile problems, I think you should all realize that the GNU autoconf solution, along with automake and libtool, have improved dramatically in the last couple of years. With libtool, your shared library problems are solved completely, with no effort, and it is supported by the the Cygnus utilities on Windows. What is the percieved value of perl, if I may ask? Would it work using VC++ under Windows as the compiler, that is Win 3.1 as well as Win32? Yes there is some demand to still support Win 3.1. The main problem with using Cygnus gcc is the license is incompatible with the OpenSSL one: specifically the underlying SSLeay license which we can't change even if we wanted to. Steve. -- Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. For info see homepage at http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED] NOTE NEW (13/12/98) PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Makefiles
Josh MacDonald wrote: Can you elaborate, specifically, about how the license of the various programs mentioned prevent their use for the present purpose? You really must support this claim. My original comment about license problems refererred to Cygnus gcc library and OpenSSL. Unlike other ports of gcc the library is covered by GPL *not* the library license as is usually the case. This means that anything linked with the Cygnus Win32 library must be placed under GPL. If you check out the OpenSSL license (and the original SSLeay license) it says quite explicitly: "The licence and distribution terms for any publically available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied and put under another distribution licence [including the GNU Public Licence.]" This can't be changed even if we wanted to. If the Cygnus library has changed and this is no longer the case then this isn't a problem any more. The comment does not apply to autoconf et al. If that could be made to work on all platforms currently supported using, for example, VC++ under Win32 and Win 3.1 then fair enough. Steve. -- Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. For info see homepage at http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED] NOTE NEW (13/12/98) PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client certificate problems
Chris Zimman wrote: Starting s_server with: ./ssleay s_server -cert server.pem -CApath ./demoCA -CAfile cacert.pem -verify 1 -www SSL_accept:before SSL initalisation SSL_accept:SSLv3 read client hello A SSL_accept:SSLv3 write server hello A SSL_accept:SSLv3 write certificate A SSL_accept:SSLv3 write certificate request A SSL_accept:SSLv3 write server done A SSL_accept:SSLv3 flush data SSL_accept:failed in SSLv3 read client certificate A 6875:error:140780E1:SSL routines:SSL23_READ:ssl handshake failure:s23_lib.c:190: And then trying to connect with IE produces the usual empty available client certificate box for me. BUT PLEASE -- someone help tackle this client certificate issue, it is very frustrating. Like maybe a FAQ or a small client app that can successfully request a client certificate and get one back from Netscape and MSIE. I've feel like I've answered this one aleph null times but maybe its just my imagination... When a server requests client auth it sends out a list of acceptable CAs. With s_server in OpenSSL this list is in the file passed in the -CAfile option it should be a PEM encoded set of acceptable CA certificates. With SSLeay s_server you had to string the acceptable CA certificates on the end of the server certificate: if you look at apps/server.pem you'll see what I mean. This was felt to be anomalous so OpenSSL uses the -CAfile option. Now if a browser has a client certificate but its CA is not listed when the server makes the client cert request then you either get the blank list (MSIE) or a message saying you haven't got any client certificates (NS). Neither option is very informative. Version of NS before 4.06 would allow any client certificate to be selected: this didn't make much sense either. You can check the list of CAs sent out with by s_server with s_client. Check if the one you want is there. Steve. -- Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. For info see homepage at http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED] NOTE NEW (13/12/98) PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: New EVP, first helping
I'm not clear on a number of points. I think the easiest way to
handle this is to give some of the requirements of the EVP interface
(not all of which work properly at present) and you can see if that fits
in with your proposal.
Heres the first requirement...
The symmetric cipher code must have some cipher independency in fact it
should have a lot. The reason for this is so the EVP_Seal/EVP_Open stuff
can work properly. It doesn't currently work properly and can't work
properly under the current system which is one reason the EVP interface
needs an overhaul.
EVP_Open will typically decrypt an RSA block using a private key. Its
output will be a key and a key length. The key length is the current
sticking point.
The actual cipher to use will be determined by other means. One such
method is via an ASN.1 AlgorithmIdentifier defined as follows:
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }
The "algorithm" object defines the cipher type and the "parameters"
define any cipher specific info.
The "algorithm" object is the NID part of the cipher. In the examples
I'm aware of there is only one NID per cipher type. That is there is
only one RC2 and RC4 object. This immediately shows how the current code
is broken.
So what you have is this: a key, a key length, a NID giving the cipher
type and some ASN.1 parameters which give cipher specific info.
Now in the cases of some ciphers like DES-CBC and 3DES-CBC the
'parameters' only contain the IV. In the case of RC4 it doesn't contain
anything at all. In the case of RC2 it contains an indication of the
effective key length and the IV.
For ciphers with a fixed key length (DES, 3DES) if the key length is
anything other than that fixed value it is an error.
For variable key length ciphers this determines the actual key length,
for example RC2, RC4: this is not handled at present. In fact it can't
be handled at present because the current EVP stuff only provides a
small number of ciphers with fixed key lengths: if your key length isn't
one of the list your are out of luck.
Now what you should be able to do is have an interface where EVP_Open
contains no symmetric cipher specific code (it doesn't at present but it
doesn't work properly either).
The reverse side of things is that you should be able to generate
this ASN.1 stuff. EVP_Seal shouldn't have any cipher specific code
either but the user will obviously need to call some cipher specific
code with the relevant parameters and get the ASN.1 stuff out.
This is all much easier if you do allow EVP_Open to contain cipher
specific code.
However if you don't have EVP_Open contain cipher specific code then you
get some algorithm independency.
Suppose someone writes a brand new cipher, this cipher might be
implemented in hardware for example.
If the EVP_Open/EVP_Seal interface works properly this wont matter. As
soon as the new algorithm is added it will automatically be supported:
it would register a NID and contain some ASN.1 code.
What EVP_Open should be able to do is look up the new cipher by its NID
and then use its various functions to decode the ASN.1 stuff and set the
key and key length. It should then be able to give an error or a
properly initialised cipher context structure.
Now *every* cipher doesn't need to fit in this model, some might not
want anything to do with this ASN.1 stuff some might not have any ASN1
stuff registered.
How this fits in with PKCS#11 is a bit more ambiguous.
It can be handled directly where the key and key length come from
EVP_Open and the other object attributes come from the NID and algorithm
identifier: you'd need an "ASN.1 wrapper" round a PKCS#11 algorithm for
this to work. You'd typically decrypt the key block and then build up a
PKCS#11 object with all the bits.
Alternatively you could have a PKCS#11 mechanism partially override the
EVP_Open interface and call C_Unwrap. This has the advantage that the
unwrapped key never leaves the PKCS#11 library and is never directly
visible to the user, or more importantly an attacker. EVP_Seal could be
handled similarly.
Steve.
--
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant.
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [EMAIL PROTECTED]
NOTE NEW (13/12/98) PGP key: via homepage.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: New EVP, first helping
OK let me put this another way. You don't need to really understand how all the ASN.1 stuff works and I certainly wouldn't expect you to write it, however what is important is that the new scheme allows the ASN.1 stuff to work and it isn't just plain impossible as with the current system. The ASN.1 stuff doesn't quite match up to the current API. Currently you have the key and IV (if needed) passed to EVP_CipherInit (and friends) and everything else is implied by the EVP_CIPHER parameter. The ASN.1 AlgorithmIdentifier supplies everything except the key and sometimes (e.g. RC2) the key length. That is you get the cipher, IV, IV length and various other things implied by the ASN.1. So the proposed: EVP_CIPHER EVP_getcipherbyASN1(unsigned char* asn1_string, unsigned int lenght) would need to be modified to: EVP_CIPHER *EVP_getcipherbyASN1(unsigned char* asn1_string, unsigned int lenght, unsigned char **iv); In fact since this would always be an AlgortithmIdentifier it could be better done with: EVP_CIPHER *EVP_getcipherbyASN1(X509_ALGOR *algorithm, unsigned char **iv); This is easy enough to handle. It would decode the ASN.1 stuff based and lookup the the NID of the algorithm object of the AlgorithmIdentifier. So you need something to convert a NID into an EVP_cipher type_ext function pointer. It would then pass the parameters as an ASN1_TYPE parameter to the cipher specific ASN.1 stuff which would then set up everything else and pass the IV (if necessary) back along with the EVP_CIPHER pointer if everything was consistent or NULL if not. The IV would come back as a Malloc'ed buffer. A potential problem is that you don't always know the key length at this point. This means that you need to be able to modify the key length in the returned EVP_CIPHER structure. The is needed by EVP_Open for variably key length ciphers (RC2, RC4). EVP_Open as I said will typically decrypt an RSA block with a private key. The returned data may be invalid or have an invalid length: as a result it *MUST* be an error if an attempt is made to set an invalid key length. Similarly the ASN.1 stuff may be invalid so equally an attempt to set an invalid IV length must be flagged as an error. Now you proposed: EVP_CIPHER* EVP_cipher-type_ext(EVP_CIPHER_PARAM *param_list, unsigned int param_count); I'd suggest this might be easier to handle if you pass a STACK instead: EVP_CIPHER* EVP_cipher-type_ext(STACK *param_list); You could then set up param_list with some helper functions like EVP_CIPHER_param_set_keylen() etc.. The reverse side of generating the ASN.1 is similar. Given a cipher, key and IV it should be able to generate an AlgorithmIdentifier. This just needs a function to get the NID from a cipher and the cipher to include some ASN.1 code: something returning an ASN1_TYPE structure could be directly placed in the X509_ALGOR structure. Or to summarise you need: Some way to turn a NID into an EVP_cipher type_ext function pointer and some want to get a NID from an EVP_CIPHER structure. Each EVP_cipher type_ext function should have an associated pair of ASN.1 functions: EVP_CIPHER *EVP_ASN1_to_CIPHER(ASN1_TYPE *type, unsigned char **iv) ASN1_TYPE *EVP_CIPHER_to_ASN1(EVP_CIPHER *cipher, unsigned char *iv); Finally you need some way to change the key length of an EVP_CIPHER structure and return an error if this is invalid. Steve. -- Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. For info see homepage at http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED] NOTE NEW (13/12/98) PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: creating Netscape java developer certs
Alicia da Conceicao wrote: Greetings: I am currently developing a number of Java applets for Netscape which require special permissions to do things like write files, which violate Netscape's Java security model. To that end, I need to create signed jar files, using a developer certificate. Unfortunately, I do not know what the difference is, between a user certificate, and a Netscape developer certificate, since I don't know how to extract developer certificates from signed jar files. Does anyone have a Netscape developer certificate I can look at? I would like to run "x509 -text" on it to see what x509 fields are being used. In addition, can I use any open source product, like openssl, to sign Java jar files for use in a Netscape browser? If no open source product is available for jar signing, are there any non-open-source products that I can use for NetBSD (most perfered), FreeBSD, OpenBSD, or Linux, all on ix86 hardware? Although I am quite adept at creating and using user and server certificates, I have no experience at creating and using Netscape developer certificates. I would greatly appreciate any help on this matter. Once I have mastered developer certs, issued from my own private CA, I then plan to buy commerical Netscape developer certs (likely from Thawte), to sign my java for mass distribution. Thanks in advance. Sincerely, Alicia. I have done this myself and its not particularly difficult. There is some info in my PKCS#12 FAQ about creating NS JAR signing certificates. Basically they just have the 'object signing' bit set in the end user certificate. In the current release OpenSSL and the older SSLeay this can be done with a line: nsCertType = 0x10 (or 0xb0 if you want S/MIME and SSL client authentication as well) in the config file (ssleay.cnf or openssl.cnf for OpenSSL). The latest CVS snapshot OpenSSL is less cryptic: nsCertType = objsign or nsCertType = objsign, client, email will do. When you then use 'ca' to sign a request the new values will be added to the certificate and it should be usable for object signing. Netscape does have its own signtool which runs on a variety of platforms, I've tried it under Win32 and Linux. Its not open source due to US export laws. It is free to use and can be downloaded from NS site. Steve. -- Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. For info see homepage at http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED] NOTE NEW (13/12/98) PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RSA_NO_PADDING
Richard Levitte - VMS Whacker wrote: ulf Another difference between 0.8.1 and 0.9.x is that ulf RSA_padding_add_none in 0.9.x prepends a null byte first. ulf ulf If you want that, the code would look like this: I'd vote for having RSA_NO_PADDING mean what it says... Yes so would I. A literal "no padding" would be useful for debugging and demonstrartion purposes as well. Also if you want zero padding you can build it on top of "true no padding". If however you have zero padding and want "true no padding" you can't do it using zero padding. Steve. -- Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. For info see homepage at http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED] NOTE NEW (13/12/98) PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
