HiHO... > I get an idea for parsing the extensions from Stephan Martin (TinyCA). > He puts the extensions in an two-dimensional array @ext (ext_name, > value_array).
What you got from me, was no array, it was a hash. Something like:
$exts->{'extension-name'}->['value1', 'value2', 'value3']
I just wondered, why in the original OpenSSL.pm is an array @exts
declared, but never used - that was what i talked about arrays.
> The problem is that we use directly the names of the extensions which
> are used by OpenSSL and get in trouble if these names are changed by
> OpenSSL (it is a violation of our abstraction). Should we normalize the
> names and use a hash with the normalized names?
Technically that would be no problem, but at the present i can't see the
need for using this abstract layer. At the present, there would only be
the possibility to *read* the extensions.
And i think its better to have a more general parser to read every
certificate. You get a hash with everything and can look what to do with
it. For an api to *set* some extensions the abstraction is more important
i think.
That's the same problem, like the different ways of parsing
the Subject-DN in OpenSSL.pm and REQ.pm (I think, it was there??)
The one parses in a generic way everything and provides a hash with all
existent data and you can look, what you want to use. And the other one
looks only for specific parts and you will never be able to see the rest.
stephan
--
t="\$_='for(\$i=-2;\$_=substr(\"2720ab25409d2500f82310a6272\",\$i+=2,3);)
.~.
/V\ [ [EMAIL PROTECTED] GnuPG: 0x7E30CD6D ]
/( )\
^ ~ ^ {\$_=\$i++%2?hex:oct;\$_=chr(\$_%(2**2*22));\$_=\$i?lc:{};print;
}';s/\( +\)|[.\/V~^\\\]+| {2,}|\\[\s+.+\s+\\]//g;eval \$_;"&&echo $t|perl
msg00689/pgp00000.pgp
Description: PGP signature
