[gnutls-dev] Re: non-ASCII ASN.1 string types

[Simon Josefsson]

Joe Orton <address@hidden> writes:

> On Sun, Oct 17, 2004 at 12:46:30PM +0200, Nikos Mavrogiannopoulos wrote:
>> On Sunday 17 October 2004 12:08, Joe Orton wrote:
>> 
>> > > Ok. The newest patch will print something like:
>> > > Subject: C=GB,ST=Cambridgeshire,L=Cambridge,O=Neon Hackers
>> > > Ltd,OU=#48e86c6c6f20576f726c64,CN=localhost,address@hidden
>> > I dunno, I'd rather the functions fail if the RDN can't be
>> > auto-converted into UTF-8 per the docs
>> I don't like this behaviour. And according to my intrerpretation of rfc2253, 
>> this is the proper thing to do when an unsupported character set is found in 
>> the asn.1 encoding.
>
> Well I guess the interface is simply not flexible enough for this to be
> decided by the app, where ultimately it should be.  I have no need for
> 2253-style formatting in neon, I'd prefer to be able to skip RDNs which
> I can't produce human-readable strings from than show random hex strings
> to the user.

That is a worthy goal, and if you want to work on adding some
interface in GnuTLS, similar to the OpenSSL X509_NAME, to achieve it,
I think it could be incorporated.

For what it's worth, I agree with Nikos that adding UCS2->UTF8
conversion is to enter a problematic road.  For non-ASCII handling, I
believe that GnuTLS should use some external library, that is focused
on that problem.  There are so many pitfalls in charset handling that
I wouldn't want the GnuTLS code to have to deal with them too.  TLS is
complex enough as it is.  GNU Libidn can do charset conversion, but
there may be other candidates.

I'm sorry I don't have free time to help with the OID code you posted.
If you debug it further, and submit your code as a new self test
(possibly together with a patch to fix any bugs), I will try to work
on integrating it.

Thanks,
Simon