[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]
