Re: [FORGED] TeletexString
Kurt Roeckx writes: >As I understand it, it was the Swedish government, and they claimed that >Microsoft said it was ok. They just contained latin1. That sounds right then, latin-1 would cover Sweden, and given the T61String = latin1 that most (all?) implementations apply it should work fine. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] TeletexString
Kurt Roeckx writes: >I have yet to see a certificate that doesn't just put latin1 in it, which >should get rejected. There were some Deutsche Telekom certificates from the late 1990s that used T61String floating diacritics for which I had some custom code to identify the two-character sequences and convert them to latin-1, which things could actually understand (this was slightly risky because some of those are also plausible latin-1 combinations, so the code checked specifically for likely umlauted a, o and u). That was one of the certs I referred to earlier where we were unable to identify anything that could display them, except possibly custom apps also from Deutsche Telekom. In any case the next release of the certs moved to latin-1, presumably in response to complaints that their certs contained garbage strings that nothing could display. So the most sensible approach would be to assume T61String = latin1, at least that way what a CA puts in a cert will display OK. Just out of interest, which country did the T61String-containing cert come from? With which interpretation of T61String did the resulting strings display correctly? Were they in fact latin-1? Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: [FORGED] TeletexString
​Ryan Sleevi writes: >Is that because you believe it forbidden by spec, or simply unwise? The spec allows almost anything, and in particular because there isn't any one definitive "spec" you can have ten incompatible interpretations that are all compliant to something that can claim to be the spec (see the Style Guide description). However, the chances of anything displaying this stuff correctly is essentially zero. >The value of a linter is fairly proportional to its value in spec adherence. Which of the half-dozen to dozen interpretations of what constitutes "the spec" do you want it to enforce, and why that particular one and not the others? Also, if it knows that the chances of anything being able to correctly handle a particular string form is essentially zero, even if some interpretation of the spec can claim it's OK, shouldn't it warn? >making them errors puts burden on CAs and the community to evaluate whether >or not it's an "actual violation" or just something "monumentally stupid" No, it's a way of telling CAs that if they do this, things will break. That's exactly what the original lint did, "this is permitted in the spec but you probably weren't intending to do that". It's cert*lint*, not certstrictcompliancecheckertoarbitraryunworkablerules. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] TeletexString
On Sun, Jul 8, 2018 at 2:34 PM Kurt Roeckx wrote: > On Sun, Jul 08, 2018 at 04:41:27PM -0400, Ryan Sleevi wrote: > > > > Is that because you believe it forbidden by spec, or simply unwise? > > It's because nobody implements the spec. Those the claim some > support for it are just broken. I have yet to see a certificate > that doesn't just put latin1 in it, which should get rejected. > > Anyway, at some point I started writing a proper parser for > teletexstring. But I don't think it's worth my time if there are 0 > valid certificates using it. If someone can point me to a proper > parser of it, that is open source, I'm willing to use that. My solution was a somewhat pragmatic and somewhat lazy: https://github.com/awslabs/certlint/blob/master/lib/certlint/certlint.rb#L138 NULL is always bad. Other than that, if we find any escape characters in the string let it pass unchecked, otherwise do what Kurt suggested. This avoids false hits of properly encoded strings at the cost of skipping some improperly encoded strings. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] TeletexString
On Sun, Jul 08, 2018 at 04:41:27PM -0400, Ryan Sleevi wrote: > > Is that because you believe it forbidden by spec, or simply unwise? It's because nobody implements the spec. Those the claim some support for it are just broken. I have yet to see a certificate that doesn't just put latin1 in it, which should get rejected. rfc2459, from 1999, already said TeletexString is only for backward compatability and you MUST switch to UTF8String by 2004, but you can keep using it forever if you established an identity before that. Because clearly if you change the encoding people will not recognize you anymore. Anyway, at some point I started writing a proper parser for teletexstring. But I don't think it's worth my time if there are 0 valid certificates using it. If someone can point me to a proper parser of it, that is open source, I'm willing to use that. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] TeletexString
On Sat, Jul 7, 2018 at 4:43 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Sat, Jul 07, 2018 at 01:23:24AM +, Peter Gutmann via > dev-security-policy wrote: > > > > So for certlint I'd always warn for T61String with anything other than > ASCII > > (which century are they living in? Point them at UTF8 and tell them to > come > > back when they've implemented it), treat it as a probably 8859-1 string > when > > checking for validity, and report an error if they try anything like > character > > set switching and fancy escape sequences, which are pretty much > guaranteed not > > to work (i.e. display) properly. > > I think it should generate an error on any character not defined > in 102 and the space character. So any time you try to use anything > in C0, C1 and G1, and those 6 in 102 that are not defined. > Is that because you believe it forbidden by spec, or simply unwise? The value of a linter is fairly proportional to its value in spec adherence. I'm all for warnings for things that are unwise, but otherwise permitted, but making them errors puts burden on CAs and the community to evaluate whether or not it's an "actual violation" or just something "monumentally stupid". The former is far more important to the relying party community, and thus if it's not a spec violation that can be demonstrated as such, making it an error is just a good way to get linters ignored :/ Perhaps I misunderstood the proposal, though? Is this considering the escape sequences or not? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] TeletexString
Kurt Roeckx writes: >I think it should generate an error on any character not defined in 102 and >the space character. So any time you try to use anything in C0, C1 and G1, >and those 6 in 102 that are not defined. Yep, sounds good. With a possible check for latin-1 validity as well in case they've used the T.61 = 8859-1 approximation/kludge. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] TeletexString
On Sat, Jul 07, 2018 at 10:43:26AM +0200, Kurt Roeckx via dev-security-policy wrote: > On Sat, Jul 07, 2018 at 01:23:24AM +, Peter Gutmann via > dev-security-policy wrote: > > > > So for certlint I'd always warn for T61String with anything other than ASCII > > (which century are they living in? Point them at UTF8 and tell them to come > > back when they've implemented it), treat it as a probably 8859-1 string when > > checking for validity, and report an error if they try anything like > > character > > set switching and fancy escape sequences, which are pretty much guaranteed > > not > > to work (i.e. display) properly. > > I think it should generate an error on any character not defined > in 102 and the space character. So any time you try to use anything > in C0, C1 and G1, and those 6 in 102 that are not defined. I just changed the check in x509lint to do that. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] TeletexString
On Sat, Jul 07, 2018 at 01:23:24AM +, Peter Gutmann via dev-security-policy wrote: > > So for certlint I'd always warn for T61String with anything other than ASCII > (which century are they living in? Point them at UTF8 and tell them to come > back when they've implemented it), treat it as a probably 8859-1 string when > checking for validity, and report an error if they try anything like character > set switching and fancy escape sequences, which are pretty much guaranteed not > to work (i.e. display) properly. I think it should generate an error on any character not defined in 102 and the space character. So any time you try to use anything in C0, C1 and G1, and those 6 in 102 that are not defined. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] TeletexString
Peter Bowen via dev-security-policy writes: >In reviewing a recent CA application, the question came up of what is allowed >in a certificate in data encoded as "TeletexString" (which is also sometimes >called T61String). For the full story of T.61 strings, see the X.509 style guide, https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt, it's a flat text file but grep for "T.61/TeletexString" for the text that covers it. Some further notes, at the time a lot of implementations just treated it as 8859-1 (which the guide mentions with the comment on assuming T.61 = latin-1), which worked OK for most cases where it was used, e.g. umlauts and other accented characters for European languages. Also at one point a bunch of people tried to identify any implementation that would display even something as basic as umlauts via floating diacritics and were unable to find anything that did it. So for certlint I'd always warn for T61String with anything other than ASCII (which century are they living in? Point them at UTF8 and tell them to come back when they've implemented it), treat it as a probably 8859-1 string when checking for validity, and report an error if they try anything like character set switching and fancy escape sequences, which are pretty much guaranteed not to work (i.e. display) properly. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
