Heres a few random thoughts on how I think certificate extensions could
be handled.

Currently V3 extension support is almost absent. To help matters I wrote
ca-fix ages ago until proper extension support was added (it was always
"real soon now") but alas it never was. I'm reluctant to add ca-fix into
the main distribution because I regard it as a kludge designed as a
short term measure until something better was available.

One major need for extensions is that their values can be entered into
things like config files for things like 'req' and 'ca' and printed out
with something like 'x509'. Adding a new extension should not require
patching these utilities if at all possible.

So what I propose is somthing like this. Each extension is part of a
lookup table. 

The table contains a set of six associated functions for each extension.
The functions would be: asn1_new, asn1_free, d2i, i2d, v2i, i2v. The
first four are just standard ASN1 allocation and conversion stuff.

v2i and i2v need special mention. The idea is that a STACK of name+value
pairs (CONF_VALUE structures to be precise) are handled by these. 

v2i takes these values and converts them to the internal structure
format.

i2v does the opposite.

Typically v2i will lookup the "name" of each CONF_VALUE element in a
list and set up the relevant structure member with the "value". i2v will
do the opposite.

Things like bit strings (keyUsage netscape-certificate-type) and single
value extensions (netscape-comment) could have some flexible wrappers
that allow these to be rapidly added. Typically all these would need
would be a table giving the names of the various bits.

Built on top of this lot would be some higher level functions to allow a
section in a config file to be converted into a set of extensions and a
set of extensions to be printed out.

Typically the config file would have something like this in it:

basicConstraints=CAbasic

....

[CAbasic]

CA=TRUE
pathlen=10

single valued extensions could be handled as at present.

Anyway thats just a few random thoughts.

There are some problems with this: like handling some of the extensions
that have variable values (subjectAltName springs to mind) or those
which are based on hashes of things like public keys etc.

Comments anyone?

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]

Reply via email to