Re: invalid syntax when teletexstring

[Erwann ABALEA <eabalea@gmail.com>]

2011/7/29 Howard Chu <hyc@symas.com>:
> Erwann ABALEA wrote:
>> If the support for JIS, Chinese, and Greek characters were to be
>> included in the 1993 edition, and this edition has never been
>> published, couldn't it be possible to ignore them?
>> X.680 (1997 edition) also references the 1988 edition of T.61, and if
>> no newer edition is present, then it still must be used, right?
>
> Actually Japanese and Chinese are already specified in the 1988 edition.
> Greek is mentioned there but is lacking a specification of which escape code
> to use. Probably it's defined elsewhere, like a later version of ISO 2022 or
> somesuch.

I agree it's very badly "normalized", to say the least. Another
spaghetti plate to look through...

>> Is an incomplete (but documented) support for T61String really worse
>> than no support for it at all? Even if literature tells that no
>> perfect support can exist?
>
> In the security arena, yes. E.g. if we accept a T61String that uses escape
> codes, we will not normalize it correctly to UTF-8. From there we would be
> giving "definitive" yes/no results to matches, based on invalid comparisons.

The security argument is good. For my personal use, certificateMatch
filter is not used. But I'll need to store X.509 certificates, some
containing T61String elements in issuerDN, and retrieve them using
more classic search filters
&((objectClass=inetOrgPerson)(cn=...)(sn=...)) and get the
userCertificate;binary attribute.
I found some messages from 2006 telling that certificateMatch were
done using OpenSSL. Did you chose to code it differently to support
other crypto libraries, such as GnuTLS?

Be compliant with all the standards is difficult, I know, especially
when they're incomplete and/or divergent. I have no other proposition
than letting the admin chose between "I want to be able to use
certificateMatch" and "I want to be able to store any stupid
certificate in my tree".

-- 
Erwann.