[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: solutions

From: Simon Josefsson
Subject: Re: solutions
Date: Tue, 04 Aug 2009 13:56:27 +0200
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (gnu/linux)

Werner Koch <address@hidden> writes:

> On Mon,  3 Aug 2009 23:38, address@hidden said:
>> However, isn't this the wrong way to address the real problem?  It seems
>> callers of the function should be fixed to be careful not to assume
>> decoded data does not contain NULs?
> This is often hard to implement.
> FWIW, Libksba uses an rfc-2253 representation of DNs in its API, thus
> there is no problem due to the required quoting.

Right, and this seems to be the right way forward too.  GnuTLS uses RFC
2253 format too, but it didn't escape strings properly.  :-(

> However, for bad (well, unlikely) encodings of URLs, Libksba now uses
> a made up OID to indicate this error:
> (invalid encoded OID).  You may want to use a similar hack.

I don't see how to use this in GnuTLS since there are functions that
return data associated with a particular (input variable) OID.  If that
function is passed the OID for CN, it has to return the information,
otherwise you'll get other problems if you return an error saying that
there is no CN field.

But if we use the RFC 2253 formatting, all things are safe.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]