Re: IA5 String...
There was a lot of energy around S/MIME. People are implementing it. Internally, it's pretty kludgely, but it does provide pretty good cryptographic services. (as an aside, my favorite kludge anecdote is the fact that X.509 certificates use an IA5 character set rather than ASCII, so that the @ in email addresses has to be represented as (a) instead).
Wow, is this true? I dont think so. The CCITT document I have (CCITT T.50) mentions that an @ sign (Commercial at) is a member of the IRV.
From what I understand IA5 basically means US ASCII.
Alex
If people are going to criticize X.509, they ought to at least get their facts straight, beginning with the difference between Printable String (standardized around the time of the IBM 1403 printer with its 48 character print chain) and some of the more extended alphabets. In particular, X.500 has been amended to include BMPString within DirectoryString, and BMPString is essentially Unicode. Now, there may be some who would argue that a 16 bit character isn't sufficient to represent every language in the galaxy (Old High Martian may have some additional requirements), but as a first approximation it should certainly good enough. And one of the virtues of ASN.1 is that a compliant implemtnation shouldn't have to be concerned with such details as the alphabet that is used. Bob Robert R. Jueneman GTE Laboratories 40 Sylvan Road Waltham, MA 02254 Jueneman@gte.com 1-617/466-2820 "The opinions expressed are my own, and may not reflect the official position of GTE, if any, on this subject."
On Feb 26, 11:12am, Jueneman@gte.com wrote:
Wow, is this true? I dont think so. The CCITT document I have (CCITT T.50) mentions that an @ sign (Commercial at) is a member of the IRV.
From what I understand IA5 basically means US ASCII.
[ ... deletia ... ]
If people are going to criticize X.509, they ought to at least get their facts straight, beginning with the difference between Printable String (standardized around the time of the IBM 1403 printer with its 48 character print chain) and some of the more extended alphabets. In particular, X.500 has been amended to include BMPString within DirectoryString, and BMPString is essentially Unicode. Now, there may be some who would argue that a 16 bit character isn't sufficient to represent every language in the galaxy (Old High Martian may have some additional requirements), but as a first approximation it should certainly good enough.
I don't recall who made the comment that X.509 used IA5, but I was the one who noted (wrongly?) that IA5 had no representation of the at sign ("@"), and instead used a lower-case letter "a" inside of parentheses. I remembered it then in context with all the work I'd done on the X.400 projects tying together the DISA cc:Mail and the OSD MS-Mail backbones, and I'm still quite convinced that at least in the context of the systems we were using, this is exactly what IA5 meant. There was much wailing and gnashing of teeth over this one, because it made our directory sync and directory query stuff all that much more of a pain. It could even have contributed to the stillbirth of those projects, the omnipresent and oppressive spectre of DMS not withstanding. Now, perhaps the definition of IA5 has changed, and if so, then that's great. Or maybe DISA and the X.400 we had (not too unrelated to the formless but very chilling DMS) were badly broken and this is what they made us live with. In any event, if X.509 certificates don't have this problem, then that is wonderful. It's another reason why we might want to support X.509v3 certificates as an absolute minimum acceptable standard.
And one of the virtues of ASN.1 is that a compliant implemtnation shouldn't have to be concerned with such details as the alphabet that is used.
I await the wisdom of Steve Crocker to be visted upon us regarding the use of ASN.1. I do know that, from general principle, the mere concept of being forced to go out and buy something like an ASN.1 compiler just so that I can implement a parser for a format seems abhorrent in the extreme. Not to mention the additional complexity, unwieldiness, and sluggishness it lends to the final product. -- Brad Knowles MIME/PGP: BKnowles@aol.net Mail Systems Administrator <http:www.his.com/~brad/> for America Online, Inc. Ph: (703) 453-4148
participants (2)
-
Brad Knowles -
Jueneman＠gte.com