Re: TeletexString
On 09/07/2018 03:31, Peter Gutmann wrote: 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? The SPEC obviously is X.690(2015) clause 8.23, most notably Table 3, and the ISO standards therein referenced (ISO 2022 and ISO 2375). Note that clause 8.23.5.1 (via X.680(2015) Table 8) seems to further restrict the escape codes to those that select one of the character sets "6, 87, 102, 103, 106, 107, 126, 144, 150, 153, 156, 164, 165, 168 + SPACE + DELETE" (See also Note 2 to X.680(2015) Table 8 about character set 6 versus 102). For TLS capable certificates, the additional restrictions in the latest CAB/F BRs, and the therein referenced parts of the PKIX RFCs further restrict what is allowed. For e-mail or IPsec certificates, there are no common standards currently in place, and since the linter is not Mozilla specific it cannot assume any Mozilla policies for such certificates. IPsec is notable because the authors of RFC4945 added a strong recommendation that IPsec certificates do not specify extended key usage. For Code signing certificates (not Mozilla relevant, but relevant for CAB/F BR compliance), the CAB/F BRs for such certificates further restrict the certificate contents. 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? Therefore, any use of permitted ISO 2022 escape sequences in TeletexString should still generate a warning. As should strings containing the DELETE character. Spaces however are permitted in many elements, for example O,L,ST,street and a non-address CN. 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. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ 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: >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: TeletexString
On Sat, Jul 7, 2018 at 4:07 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Fri, Jul 06, 2018 at 02:43:45PM -0700, Peter Bowen via > dev-security-policy wrote: > > 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). > > > > Specifically, certlint will report an error if a TeletexString > > contains any characters not in the "Teletex Primary Set of Graphic > > Characters" unless the TeletexString contains an escape sequence. For > > example, including 'ä', or 'ö' will trigger this error unless preceded > > by an escape sequence. > > > > In order to figure out what can be used, one need to reference X.690 > > Table 3, which notes that G0 is assumed to start with character set > > 102. Character set 102 is defined at > > https://www.itscj.ipsj.or.jp/iso-ir/102.pdf. Note that 102 isn't the > > same as ASCII nor is it i the same as the first part of Unicode. > > I'm not sure why you bring this up. Anyway, according to X.690, > the default is: > > G0: 102 > C0: 106 > C1: 107 > > Or as escape sequences and locking shift: > ESC 2/8 7/5 LS0 (G0 102, locking shift 0) > ESC 2/1 4/5 (C0 106) > ESC 2/2 4/8 (C1 107) > > But what is just as important is that G1 does not have a default, > while at least some people assume it's 103. While 102 is close to > ASCII, there is nothing for G1 that is close to latin1. > This came up in a recent CA review, in which a CA did not properly escape, but stated that the vendor told them this is correct. See https://bug1417041.bmoattachments.org/attachment.cgi?id=8985908 ___ 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: TeletexString
On Fri, Jul 06, 2018 at 02:43:45PM -0700, Peter Bowen via dev-security-policy wrote: > 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). > > Specifically, certlint will report an error if a TeletexString > contains any characters not in the "Teletex Primary Set of Graphic > Characters" unless the TeletexString contains an escape sequence. For > example, including 'ä', or 'ö' will trigger this error unless preceded > by an escape sequence. > > In order to figure out what can be used, one need to reference X.690 > Table 3, which notes that G0 is assumed to start with character set > 102. Character set 102 is defined at > https://www.itscj.ipsj.or.jp/iso-ir/102.pdf. Note that 102 isn't the > same as ASCII nor is it i the same as the first part of Unicode. I'm not sure why you bring this up. Anyway, according to X.690, the default is: G0: 102 C0: 106 C1: 107 Or as escape sequences and locking shift: ESC 2/8 7/5 LS0 (G0 102, locking shift 0) ESC 2/1 4/5 (C0 106) ESC 2/2 4/8 (C1 107) But what is just as important is that G1 does not have a default, while at least some people assume it's 103. While 102 is close to ASCII, there is nothing for G1 that is close to latin1. 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
TeletexString
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). Specifically, certlint will report an error if a TeletexString contains any characters not in the "Teletex Primary Set of Graphic Characters" unless the TeletexString contains an escape sequence. For example, including 'ä', or 'ö' will trigger this error unless preceded by an escape sequence. In order to figure out what can be used, one need to reference X.690 Table 3, which notes that G0 is assumed to start with character set 102. Character set 102 is defined at https://www.itscj.ipsj.or.jp/iso-ir/102.pdf. Note that 102 isn't the same as ASCII nor is it i the same as the first part of Unicode. I hope that this helps explain why these errors show in certlint. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
