Re: Chunghwa Telecom eCA Root Inclusion Request
Dear Wayne, Our two customers requested to use original CSR to issue two shorter validity SSL certificates. By the re-issuance function of a program, to insert original applications data, our SSL RA Officers checked the addresses but they forgot to add L in Subject DN. So there are two SSL Certificates as below lack of L or S in Subject DN. 1.Serial Number:20BD5F0B51809E44C0718AB133CA5E78 CN=*.sercomm.com, O=中磊電子股份有限公司, C=TW or https://crt.sh/?id=508868868 2.Serial Number:3CE33A6D8899A211FB2D296D9E0B69CB CN=app3.uupon.tw, O=點鑽整合行銷股份有限公司, C=TW or https://crt.sh/?id=512788172 Our researchers of Telecommunication Laboratories of Chunghwa Telecom found above issue on June 11 and told our SSL RA Officers to contact the customers. When I was back to my office after the travlelling from England and disussed with my colleauges, I mailed the situation and the plan to Wayne and Kathleen on June 15. This certificate of https://crt.sh/?id=512788172 was revoked on June 11 soon. We have re-issued new certificates for two customers as below: 42664EEA106F2CBF736ADBF949D4218F CN=*.sercomm.com, O=中磊電子股份有限公司, L=臺北市, C=TW or https://crt.sh/?id=519100183 100079C87402938109A5FEC040C5BE0F CN=app3.uupon.tw, O=點鑽整合行銷股份有限公司, L=臺北市, C=TW or https://crt.sh/?id=549539943 After our customer installed a new certificate (https://crt.sh/?id=519100183) in their web servers, network equipments and firewall, The certificate of https://crt.sh/?id=508868868 was revoked on June 21,. The checking function of Subject DN about either L or S are online June 22. I mailed to Wayne and Kathleen on June 22. We confirm that the problem has been solved and will not happen in the future. As we have discussed in CABF, Taiwan is a small country without state/provinces. We follow X.500, X.520 and Taiwan’s government’s DIT for the certificates. We can unique identify the subject without state/provinces and locality in DN for a central government agency or a company. (For example, In Taiwan's Company Act, https://law.moj.gov.tw/Eng/LawClass/LawAll.aspx?PCode=J0080001, Article 18 No company may use a corporate name which is identical with that of another company. ). We really receive some subscribers of central government agency or a company asked why your CA adds L in the subject DN of an SSL certificate. We explain that we follow the BR about either L or S should be in Subject DN now. ___ 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
