solutions

[Simon Josefsson]

Werner Koch <wk at gnupg.org> writes:

> On Mon,  3 Aug 2009 23:38, simon at josefsson.org 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: 1.3.6.1.4.1.11591.2.12242973
> (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.

/Simon