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