Dr Stephen Henson wrote:
>
> 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.
It might be nice to have these for fields within the extensions, too.
Anyway, the scheme sounds good to me!
>
> 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.
Presumably the first case can be handled by allowing the config to be
overridden on the command line (with just name-value pairs, as in the
config file, or perhaps it would have to be something like
"extension.name=value"?), and the second just has to be explicitly
programmed (so you configure the keyfile, and it uses the hash of the
key instead).
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: [EMAIL PROTECTED] |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
