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".