> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Dr. Stephen Henson
> On Fri, Aug 30, 2002, Howard Chu wrote:
> > > The output from testca is still a little dodgy, there are a
> few certificate
> > > fields that are printed in ASCII that need to be translated to
> EBCDIC for
> > > appearance's sake. But that's simple to fix; if you're interested
> > > I'll submit
> > > patches for that later.
> >
> > X509v3 extensions weren't handling EBCDIC correctly. Trying to set a
> > subjectAltName resulted in the EBCDIC strings going into the
> cert, instead of
> > ASCII. Here are the fixes for crypto/x509v3. Also, the ca app
> needs a small
> > patch to translate DN components from ASCII to EBCDIC when
> confirming their
> > values.
> Now I look at this, I'm not sure this is being handled the right way.
> I don't have access to an EBCDIC box so this analysis may not be
> 100% accurate...
Your analysis sounds correct to me.
>
> The current stuff (I think) conf->name EBCDIC but conf->value ASCII (where
> it works that is).
Yes.
>
> The reason for the problem is that there are calls to:
>
> X509V3_add_value(name, value, sk);
>
> but there are two cases. If the call is something like:
>
> X509V3_add_value("some_field_name",cert->foo, sk);
>
> where cert->foo is some value from a certificate we end
> up with conf->name using the native character set but
> conf->value using whatever is in the certificate which
> will be ASCII.
>
> If however we do:
>
> X509V3_add_value("some_field_name", "<unsupported>", sk);
>
> both conf->name and conf->value have the native character set.
>
> This isn't a problem if the native character set is ASCII, but
> if it isn't the two cases will differ such as if the native
> is EBCDIC.
Yes.
> So I'd suggest that we decide what values should go in
> conf->name and conf->value. It might be advisable for both
> to always use the native character set, then if you do:
>
> if (strcmp(conf->value, "some_field_value") == 0)
>
> it will always work.
The current approach is not terribly broken. Changing the convention now will
just be a lot of extra work. The bulk of the library is geared for ASCII, and
I think this makes the most sense.
The arbitrary strcmp's may be a problem, but I think that's a different
issue; fields that accept only certain values should have those values
defined in only one place. Instead of embedding "TRUE" string literals all
over the source code, it should be a single constant defined once for the
entire library.
There's an alternate solution to this particular issue, when using the IBM C
compiler - you can set a compiler option/pragma to choose the character set
that will encode any string/char literals. I use this approach in the OS/390
port of OpenLDAP - again, all library internals are ASCII, and EBCDIC
translation only occurs in stdio stubs - reading native config files, and
displaying output. Limiting translation to these interfaces means the
internals still run at full speed with no translation overhead.
>
> Also I'd suggest a new function, X509V3_add_value_native()
> (or whatever) which does any conversion inside and this is
> always called where it might be needed. Then in the call
> to X509V3_add_value_native() we can either just call
> X509V3_add_value (on ASCII machines) or do the conversion
> (on EBCDIC).
In the spirit of this solution, I'd add X509V3_add_value_ascii() instead,
which accepts native strings and stores them as ASCII.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
