2011/7/29 Howard Chu hyc@symas.com:
Erwann ABALEA wrote:
[...]
I'm reading now libldap/t61.c. I just read the IETF draft, and the numerous tables... What a mess. X.680 has a reference to T.61 recommendation, which was deleted some years ago, and I'm not clever enough to make Google find a copy of the standard. It can't be bought anymore from ITU, but it's still referenced by later standards. Nice.
The 1988 edition is still downloadable. http://www.itu.int/rec/T-REC-T.61-198811-S/en
One click further... Sorry, I read "Superseded" for the 1988 edition, and "Withdrawn" for the 1993 one, and didn't realize I could click on the 1988 link to download this edition.
It also references T.51: http://www.itu.int/rec/T-REC-T.51/en
Unfortunately the 1993 edition of T.61 is gone.
Even more, it is displayed as "Never published."
Meanwhile, I still haven't found the Czech CSCA certificate, but I know what to do with the remaining 1% uncertainty. The CN field is encoded as T61String, to hold the "CSCA_CZ" value. That fits well within the 7bits limit.
Then you should just be using PrintableString. You're required to use the least-inclusive string type, after all.
Howard, you're very good. But you too can make mistakes :) 1. PrintableString is inadequate (because of the underscore character). 2. It's not *my* certificate, it's the Czech Republic certificate used to issue passports that will be verified by every other country. I don't work for them, I'm french :) (OK, I don't know where you live either) 3. And the "you're required to use the least-inclusive string type" statement is wrong, there's no such requirement, nowhere, everybody's free to use UTF8String even when PrintableString could be used (it's even RECOMMENDED to do so). The good option would have been to use UTF8String, for sure. But they already produced passports, and changing the root certificate of this importance is not an easy task.
Instead, RFC4518 states that non-Unicode strings are to be translated to Unicode, even TeletexString. The reader is warned that it is NOT RECOMMENDED to use such encoding, and that no standard conversion rules between them exists, but this conversion is *not* optional.
If everything is internally converted to UTF8 and t61.c seems to provide a lossless T.61 to UTF8 conversion, why isn't it used?
Because it's incomplete. It only handles the original 333 character repertoire of T.61, it doesn't handle shift-in/shift-out to other character sets. I believe in the last version of T.61 there was support for Japanese (JIS), Chinese, and Greek. So quite a lot more logic and tables needs to be added, and it looks like a lot of work for something nobody should actually be using.
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?
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?