[PATCH] Configure rsaref
Index: Configure
===
RCS file: /e/openssl/cvs/openssl/Configure,v
retrieving revision 1.35
diff -u -r1.35 Configure
--- Configure 1999/04/09 16:25:25 1.35
+++ Configure 1999/04/12 14:15:02
@@ -292,6 +292,11 @@
{
if ($_ =~ /^no-asm$/)
{ $no_asm=1; }
+ elsif ($_ =~ /^rsaref$/)
+ {
+ $libs.= "-lRSAglue -lrsaref -lRSAglue ";
+ $flags.= "-DRSAref ";
+ }
elsif ($_ =~ /^386$/)
{ $processor=386; }
elsif ($_ =~ /^-/)
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Req/X509 under Win32
Hi, Anyone has the success experience to run Cert management programs under win32 platform. I have tried, but failed, when I run openssl req -new -config /openssl/lib/openssl.cnf -out mycsr.pem I got a error message "unable to find 'distinguished_name' in config problem make Certificate request". any advice will help. Zhigang _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Type-safe stacks
Ahh, I misunderstood what you meant by macros. I thought you meant things like: #define sk_X509_push(sk, v) \ sk_push((stack*)sk, (char*)v) Which is, of course, sub-optimal. Having a bunch of one-line wrapper functions isn't unreasonable. On the other hand, since stack.[ch] are so small, perhaps you should just turn stack.c into a set of #define's? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Type-safe stacks
[EMAIL PROTECTED] wrote: Ahh, I misunderstood what you meant by macros. I thought you meant things like: #define sk_X509_push(sk, v) \ sk_push((stack*)sk, (char*)v) Which is, of course, sub-optimal. Having a bunch of one-line wrapper functions isn't unreasonable. Would I do something suboptimal? :-) On the other hand, since stack.[ch] are so small, perhaps you should just turn stack.c into a set of #define's? Possibly. Or inline them (which works on gcc even for C programs, I believe). I was leaving that kind of fine-tuning for later. Note that STACKs use the heap, and hence are not exactly high-performance objects anyway, except in the two existing #defined functions, sk_num and sk_value. Unfortunately, #defineing those makes them not type-safe. I was considering having them #defined in non-DEBUG mode... Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Type-safe stacks
Ben Laurie wrote: Don't forget that templates are really just a glorified preprocessor (well, OK, they aren't now but they were at first) :-) Seriously, you can do a lot of what templates do with a preprocessor if you try hard enough. Anyway, the interesting stuff all happens here, in what will be safestack.h: [clever macros deleted] Hmm, very nice. That looks sufficiently clever for at least one C compiler to choke on it :-( That will certainly break Win32 if the STACKs need to be accessed outside the DLL. H probably needs a hack or two of the DEF file generator and some new ordinals in the files. I'll wait until it gets commited before I do that. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Type-safe stacks
Dr Stephen Henson wrote: Ben Laurie wrote: Don't forget that templates are really just a glorified preprocessor (well, OK, they aren't now but they were at first) :-) Seriously, you can do a lot of what templates do with a preprocessor if you try hard enough. Anyway, the interesting stuff all happens here, in what will be safestack.h: [clever macros deleted] Hmm, very nice. That looks sufficiently clever for at least one C compiler to choke on it :-( That will certainly break Win32 if the STACKs need to be accessed outside the DLL. H probably needs a hack or two of the DEF file generator and some new ordinals in the files. I'll wait until it gets commited before I do that. Errk. At least it should be really easy to pick up which types have been defined... Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: No key, certificate and CRL API: more info.
Dr Stephen Henson wrote: 4. There is no way to lookup by other methods, for example lookup by subject key id (needed for proper certificate chain verification) or lookup by issuer name (needed to find matching certificates in an SSL client when authentication is requested). To add new lookup methods you need to add new function pointers to the X509_LOOKUP_METHOD structure and this breaks all existing code! Not sure I understand this one: so long as you are prepared to recompile existing code, any new function pointers will be NULL. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] Configure rsaref
A reasonable idea, but why do you use "-lRSAglue" twice? The correct and working order should be "-lRSAglue -lrsaref", shouldn't it? Except for this issue, +1 for the patch. It should, but Richard Revitte suggested to put it in twice. Richard? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RSA failure on irix (no asm)
Al Smith reports that RSA fails on IRIX. He does not use RSAREF, nor any assembler bignum code. This looks like a serious problem. Any ideas what may go wrong there? I'm forwarding Al's messages with his permission. From: Al Smith [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: 0.9.2b problems on irix. Ulf Moeller wrote: problems, however "make test" fails at rsa_oaep_test. Are you using RSAREF? i'm afraid not. Could you please run "make test" on the latest snapshot and mail me the result? The new rsa_oaep_test prints more output that will hopefully allow me to locate the problem. no problem. i fetched the openssl-SNAP-19990411.tar.gz snapshot. ./Configure irix-cc change BN_ASM in the Makefile to point to bn_asm.o make make rehash make test the following output was seen from rsa_oaep_test: ./rsa_oaep_test PKCS#1 v1.5 encryption failed! OAEP encryption failed! PKCS#1 v1.5 encryption failed! OAEP encryption failed! PKCS#1 v1.5 encryption failed! OAEP encryption failed! regards, -al. From: Al Smith [EMAIL PROTECTED] To: [EMAIL PROTECTED] I believe this is a problem in the assembler code to the bignum library. Can you verify that it works when you configure with the option no-asm? am i correct in assuming that "./Configure no-asm irix-cc" replaces BN_ASM=asm/*.o with BN_ASM=bn_asm.o inside the top-level makefile ? i have already been doing this by hand after running ./Configure irix-cc. if i leave the BN_ASM line intact (ie BN_ASM=asm/mips1.o) then building the "openssl" binary fails with undefined symbols: bn_div_words, bn_sub_words, bn_mul_comba4, bn_mul_comba8, bn_sqr_comba4 and bn_sqr_comba8 are all undefined with BN_ASM=asm/mips1.o. with BN_ASM=asm/mips3.o the symbols are again undefined. i can only get "openssl" to compile at all by setting BN_ASM=bn_asm.o. regards, -al. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Type-safe stacks
Ben Laurie [EMAIL PROTECTED] said: If everyone thinks it is a terrible idea I'm prepared to undo it. I'll fight first, though, coz I think it is a great idea :-) I, for one, do think it is a terrible idea and I "vote against" these changes. Marvelous macros are neat and all, but - They fragment a clean general purpose stack module into dozens of different function names, making the code harder to read and understand and harder to debug. - They probably choke currently supported compilers. And worst of all - They break existing apps. IMHO, STACKs should follow the model of malloc() and free() and operate on void types. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: No key, certificate and CRL API: more info.
Ben Laurie wrote: Dr Stephen Henson wrote: 4. There is no way to lookup by other methods, for example lookup by subject key id (needed for proper certificate chain verification) or lookup by issuer name (needed to find matching certificates in an SSL client when authentication is requested). To add new lookup methods you need to add new function pointers to the X509_LOOKUP_METHOD structure and this breaks all existing code! Not sure I understand this one: so long as you are prepared to recompile existing code, any new function pointers will be NULL. Yes you're right provided you can recompile existing code. I was getting a bit ahead of myself there. One of the other desirable (IMHO) requirements I didn't mention was that a driver could be written that exists as a shared library which can then be used by other applications. In that case the driver source might not even be available. In that case I think that adding extra lookup methods will fall over because they might point to garbage. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Type-safe stacks
Anonymous wrote: Ben Laurie [EMAIL PROTECTED] said: If everyone thinks it is a terrible idea I'm prepared to undo it. I'll fight first, though, coz I think it is a great idea :-) I, for one, do think it is a terrible idea and I "vote against" these changes. Marvelous macros are neat and all, but - They fragment a clean general purpose stack module into dozens of different function names, making the code harder to read and understand and harder to debug. I can't agree with that. The function names follow an extremely clear pattern: old: sk_name new: sk_type_name in the old version there is also major scope for getting casts entirely wrong, whereas with the new one you need no casts. In the new one, if you get types wrong, it won't compile (if you treat warnings as errors). In the old one, it falls over at runtime, which is crap. - They probably choke currently supported compilers. We have already decided to support ANSI only, and they only use ANSI facilities (and not even very sophisticated ones). And worst of all - They break existing apps. No, they don't. They cause warnings in existing apps, which otherwise work fine. IMHO, STACKs should follow the model of malloc() and free() and operate on void types. malloc() and free() are not an appropriate model. They hande unstructured data, and STACKs do not. That said, it may well be possible to have a version of STACK that does purely operate on void *, so STACK_OF(x) becomes STACK and sk_type_func becomes sk_func again. The only minor problem is that if the preprocessor doesn't support ## the defines for the functions will have to be done by hand (or by Perl). Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: No key, certificate and CRL API: more info.
Dr Stephen Henson wrote: Ben Laurie wrote: Dr Stephen Henson wrote: 4. There is no way to lookup by other methods, for example lookup by subject key id (needed for proper certificate chain verification) or lookup by issuer name (needed to find matching certificates in an SSL client when authentication is requested). To add new lookup methods you need to add new function pointers to the X509_LOOKUP_METHOD structure and this breaks all existing code! Not sure I understand this one: so long as you are prepared to recompile existing code, any new function pointers will be NULL. Yes you're right provided you can recompile existing code. I was getting a bit ahead of myself there. One of the other desirable (IMHO) requirements I didn't mention was that a driver could be written that exists as a shared library which can then be used by other applications. In that case the driver source might not even be available. In that case I think that adding extra lookup methods will fall over because they might point to garbage. In that case you use magic numbers to avoid looking for the extra methods. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] Configure rsaref
ulf It should, but Richard Revitte suggested to put it in twice. Richard? I only drew from other projects I've been involved in, where there were some kind of cross references between two libraries. To solve such things, the solution is often '-lib1 -lib2 -lib1'. In the libRSAglue and librsaref case (and since there was some kind of problem that didn't go away whatever order you used, IIRC), I was guessing wildly, and perhaps erroneously. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-161 43 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED] Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: No key, certificate and CRL API: more info.
Ben Laurie wrote: Dr Stephen Henson wrote: Ben Laurie wrote: Dr Stephen Henson wrote: 4. There is no way to lookup by other methods, for example lookup by subject key id (needed for proper certificate chain verification) or lookup by issuer name (needed to find matching certificates in an SSL client when authentication is requested). To add new lookup methods you need to add new function pointers to the X509_LOOKUP_METHOD structure and this breaks all existing code! Not sure I understand this one: so long as you are prepared to recompile existing code, any new function pointers will be NULL. Yes you're right provided you can recompile existing code. I was getting a bit ahead of myself there. One of the other desirable (IMHO) requirements I didn't mention was that a driver could be written that exists as a shared library which can then be used by other applications. In that case the driver source might not even be available. In that case I think that adding extra lookup methods will fall over because they might point to garbage. In that case you use magic numbers to avoid looking for the extra methods. I suppose this could be done by having a number in the structure which says which version of the API is supported. Not at the beginning though because that is taken. This does present problems if the someone wants to add a device specific "search by" method. Unfortunately some of the other problems make it tricky to extend the structure because the current lookups only return one matching object. Personally I'd prefer dumping it entirely because it wasn't intended to be used for a full database like API. I was thinking more along the lines of the PKCS#11 (but cut down a bit) to handle this kind of thing where you treat each 'object' as a set of 'attributes' and can search for objects that match a given attribute. Something like: int search(X509DB *db, int obj_type, int attr_type, void *attr, int attrlen, STACK **ret); You need something like this when you want to examine and modify the returned objects anyway. Having lots of little change_this_attr or get_this_attr could get unmanagable very quickly. Though macros for 'get certificate/CRL/key from object' would be useful. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] Configure rsaref
ulf It should, but Richard Revitte suggested to put it in twice. Richard? Did I write that? :) Sorry about the typo. I only drew from other projects I've been involved in, where there were some kind of cross references between two libraries. To solve Ok, then -lRSAglue -lrsaref should be ok. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: No key, certificate and CRL API: more info.
On Tue, 13 Apr 1999, Dr Stephen Henson wrote: I was thinking more along the lines of the PKCS#11 (but cut down a bit) to handle this kind of thing where you treat each 'object' as a set of 'attributes' and can search for objects that match a given attribute. Something like: int search(X509DB *db, int obj_type, int attr_type, void *attr, int attrlen, STACK **ret); Perhaps it makes sense to look at existing APIs which handle this kind of thing such as CDSA, Gutman's API, CAPI2 keystores, etc... The API is (getting so) big that adopting existing ones, even if not perfect, should be a goal. /r$ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Req/X509 under Win32
Hi, I have solve the problem by myself. Under Win32, you should use '\' instead of '/'. and you should change the first few line of openssl.cnf because of Win32 does not has ENV:: defination. cheer. --- Wu Zhigang [EMAIL PROTECTED] wrote: Hi, Anyone has the success experience to run Cert management programs under win32 platform. I have tried, but failed, when I run openssl req -new -config /openssl/lib/openssl.cnf -out mycsr.pem I got a error message "unable to find 'distinguished_name' in config problem make Certificate request". any advice will help. Zhigang _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[STATUS] OpenSSL (Sun 11-Apr-1999)
OpenSSL STATUS Last modified at __ $Date: 1999/04/08 20:45:53 $ DEVELOPMENT STATE o OpenSSL 0.9.3: Under development... o OpenSSL 0.9.2b: Released on March22th, 1999 o OpenSSL 0.9.1c: Released on December 23th, 1998 RELEASE SHOWSTOPPERS o Compilation warnings: ctype-related int vs. char o Compilation error: "unsigned long*" and "int*" under AIX o Undefined BN symbols in assembler stuff on Solaris (see posting "openssl-SNAP-19990308-2130 on Solaris-2.6 SC4" in openssl-dev) o BN assembler code in r3000.s, mips*.s and pa-risc*.s is broken o BSD/OS: assembler functions must not have leading underscores o Niels Poppe reports that RSA fails with alpha.s o exptest fails with irix64-* (Don Badrak [EMAIL PROTECTED]: "Re: Problems to compile openssl on IRIX 6.2", openssl-users) o BN_add test fails on Caldera OpenLinux 1.3 (Marc Christensen [EMAIL PROTECTED] "Compiles but fails big number test?", openssl-users) AVAILABLE PATCHES o OCSP ([EMAIL PROTECTED]) o unsigned vs. non-unsigned ([EMAIL PROTECTED]) o Install prefix for packagers ([EMAIL PROTECTED]) o getenv in ca.c and x509_def.c ([EMAIL PROTECTED]) o linux dynamic libs ([EMAIL PROTECTED]) o MingW support ([EMAIL PROTECTED]) o SPARC v9, SPARC v8 assembler implementations of bn_asm.c ([EMAIL PROTECTED]) IN PROGRESS o Steve is currently working on (in no particular order): Proper (or at least usable) certificate chain verification. Documentation on X509 V3 extension code. PKCS#12 code cleanup and enhancement. o Mark is currently working on: Folding in any changes that are in the C2Net code base that were not in the original SSLeay-0.9.1.b release. Plus other minor tidying. o Ralf is currently working on: 1. Support for SSL_set_default_verify_paths(), SSL_load_verify_locations(), SSL_get_cert_store() and SSL_set_cert_store() functions which work like their existing SSL_CTX_xxx() variants but on a per connection basis. That's needed to let us provide full-featured per-URL client verification in mod_ssl or Apache-SSL. = It still dumps core, so I suspend this and investigate again for OpenSSL 0.9.3. 2. The perl/ stuff to make it really work the first time ;-) = I'll investigate a few more hours for OpenSSL 0.9.2 3. The new documentation set in POD format under doc/ = I'll investigate a few more hours for OpenSSL 0.9.2 4. More cleanups to get rid of obsolete/old/ugly files in the source tree which are not really needed. = Done all which were possible with my personal knowledge o Ben is currently working on: 1. Function Prototype Thought Police issues. 2. Integrated documentation. 3. New TLS Ciphersuites. 4. Anything else that takes his fancy. NEEDS PATCH o broken demos o [EMAIL PROTECTED] (Rich Salz): Bug in X509_name_print [EMAIL PROTECTED] o autogenerated code in pem.h o Jean-Hugues ROYER [EMAIL PROTECTED]: rsa_oaep.c with Watcom C o $(PERL) in */Makefile.ssl o "Sign the certificate?" - "n" creates empty certificate file o add Configure option "rsaref" o dubious declaration of crypt() in des.h OPEN ISSUES o The Makefile hierarchy and build mechanism is still not a round thing: 1. The config vs. Configure scripts It's the same nasty situation as for Apache with APACI vs. src/Configure. It confuses. Suggestion: Merge Configure and config into a single configure script with a Autoconf style interface ;-) and remove Configure and config. Or even let us use GNU Autoconf itself. Then we can avoid a lot of those platform checks which are currently in Configure. 2. The xxx.org - xxx.h generation: It's not obvious for which file xxx.org is the source. Suggestion: Rename xxx.org to xxx.h.in (Autoconf style), this way one sees that xxx.h.in is the input for xxx.h Status: Mark +1 o The installation under "make install" produces a very installation layout: $prefix/certs and $prefix/private dirs. That's not nice. Ralf suggests to move the two certs and private dirs either to $prefix/etc/, $prefix/lib/ or $prefix/share. Alternatively we could also not install the certs at all. Status: Ralf +1 for both not installing the certs at all and moving it to $prefix/etc/. +0 for $prefix/lib/ and $prefix/share. Paul: why is it not nice? Ralf: because it messes up the
Re: Getting rid of ctx_size.c
On Sun, Apr 11, 1999 at 01:17:19PM +0100, Ben Laurie wrote: (remember that HEADER_ENVELOPE_H is always defined here because of a previous #include, and that the dummy structure definitions anyway could fail on some systems because they don't necessary have the alignment needed for the actual structures): Sounds fine to me: but is there any clue why these exist at all? Well, it seems that the intent was to keep the various parts of the library a little independent from each other -- but of course it's only pseudo-independence when it's done by #defining strange length macros and has no real advantages whatsoever. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
No key, certificate and CRL API: more info.
In an earlier message I discussed what I saw as a serious deficiency in OpenSSL: its lack of a key, certificate and CRL database API. In this message I'll mention more info and the general API requirements and why the nearest thing we have at present is not adequate IMHO. There is already a partial solution which is currently under utilised. That is X509_LOOKUP_METHOD. This is an API which allows certificate stores to be set up and use various lookup techniques. As usual this isn't very well documented but the stuff in crypto/x509, (particularly x509_vfy.h, x509_lu.c, by_file.c, by_dir.c) and the behaviour of applications like apps/verify.c gives some idea of how this could be used. There is some unimplemented or under used code which looks like it could handle lookups of CRLs, and private keys as well. It doesn't quite fit all the requirements unfortunately. Some of the enhancements needed are considerable so there are really two options. 1. Radically enhance the X509_LOOKUP_METHOD structure. 2. Add a totally new API e.g. X509_DB. Here are some of the ways in which X509_LOOKUP_METHOD is suitable. 1. A user will want to refer to a certificate or private key using some "friendly name" which will typically be a human readable string. The method 'get_by_alias' seems to be suitable for this. 2. The software will need to retrieve matching private keys for certificates (when available). This can be handled by either the "get_by_alias" or "get_by_fingerprint" with the requirement that matching keys and certificates have the same value. 3. Various kinds of lookup are needed for general SSL and (for example) S/MIME use, typically lookup by subject name or issuer and serial number. Both of these can be readily handled. Here are some of the problems with using X509_LOOKUP_METHOD as it stands. 1. There is no way to determine the "properties" of an object, that is after retrieving a certificate you can't find the associated alias for example. 2. The API will only return one object based on the lookup criteria. It is possible that a user might have different objects with the same criteria: for example the same subject name with several certificates from different CAs. 3. There is no general method to 'enumerate' all the objects of a given type in a store. There are several situations where this is either desirable or essential. Examples include presenting a list of acceptable certificates to a user or finding a list of acceptable CAs for SSL client authentication. 4. There is no way to lookup by other methods, for example lookup by subject key id (needed for proper certificate chain verification) or lookup by issuer name (needed to find matching certificates in an SSL client when authentication is requested). To add new lookup methods you need to add new function pointers to the X509_LOOKUP_METHOD structure and this breaks all existing code! 5. The method where a lookup is initialised (e.g. the directory or file to use) is not standardised, usually it involves a lookup specific 'ctrl' option. 6. There is no way to obtain additional information about an object, such as that it is a trusted CA for some purpose. 7. There is no standard way to require password entry before an object can be used: for example a PIN before a private key can be retrieved. 8. The whole thing is effectively read only, you can't add objects to a store in a transparent manner or, delete/modify those already there. The list could be extended considerably and X509_LOOKUP wasn't really intended to be used like this. Bolting stuff on the end of it could well end up being very messy. So what I'd suggest is that this is started from scratch. As may be apparent at this stage there is no trivial solution to this but I have a number of ideas that should not be *too* painful. I'll suggest how it all might be done later... Again comments welcomed. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
No key, certificate and CRL API: the problem.
I've been threatening to discuss this for some time. I've been aware of the problem for some time but more recently it has started to seriously hamper related development. Anyway here goes... Currently there is IMHO a big problem in the way OpenSSL handles private keys, certificates and CRLs. At best all you've got is a bunch of files with the actual 'structure' contained inside. This is fine at a basic level but for many more advanced applications it is no good at all. A typical example is a smart card: things can be done transparently once the actual key has been set up, however to set up the key needs a local non portable hack. What would be better would be to allow code that supported the card to "install" its a key and certificates so any application could say use key "foo" on driver "bar" and not worry about where it comes from. This would mean for example that an SSL application could automatically use plain files, smart cards, crypto accelerators, PKCS #12 files, PKCS#11 libraries or custom databases and not worry about the details. Similarly there is a problem with certificate stores containing trusted CAs. Currently there are two main options, the directory full of symbolic links or "everything in a file". The symbolic link option doesn't even work on environments without sym links (e.g. Win32) and even then it can only lookup certificates based on subject name (and then only one match). Ideally you should be able to include a "trust database" which contains certificates that can be looked up in a variety of ways and each certificate can be trusted or distrusted for separate purposes: SSL client, SSL server etc etc. OK that's the problem as I see it. Comments welcomed. I'll give more info shortly. If you think "X509_LOOKUP will do all that" then read the second message. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
