Re: No key, certificate and CRL API: more info.
Rich Salz wrote: 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. I think the best you could get is a "look and feel" (ugh!) of some other API because the stuctures used would not be compatible (or it would use handles instead of the structures directly: I think handles will be needed anyway). CAPI2 I know about but it has separate techniques for private keys, certificates and CRLs (and no 'login' API). I'll look into the others. PKCS#11 is the nearest to what I would regard as our needs that I've seen so far but some things (like the ability to search for arbitrary multiple matching attributes) aren't needed. 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: 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: 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: 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: 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: 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]
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]
