Hello Dimitris! You are right, of course there are mandatory RFC to take into account. But there is - to my knowledge - no RFC that says, you MUST NOT issue a certificate to a domain that could be interpreted as an IDNA2008 punycode.
With best regards, Rufus Buschart Siemens AG Information Technology Human Resources PKI / Trustcenter GS IT HR 7 4 Hugo-Junkers-Str. 9 90411 Nuernberg, Germany Tel.: +49 1522 2894134 mailto:rufus.busch...@siemens.com www.twitter.com/siemens www.siemens.com/ingenuityforlife Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 > -----Ursprüngliche Nachricht----- > Von: Dimitris Zacharopoulos <ji...@it.auth.gr> > Gesendet: Donnerstag, 24. Januar 2019 11:52 > An: Buschart, Rufus (GS IT HR 7 4) <rufus.busch...@siemens.com>; > mozilla-dev-security-pol...@lists.mozilla.org > Betreff: Re: AW: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded > international domain names > > I referred to your comment that "you perform a successful domain validation". > My point, which you seem to understand and agree, is > that there are additional rules than just DNS validation. > > Dimitris. > > > On 24/1/2019 12:21 μ.μ., Buschart, Rufus wrote: > > Hello Dimitris, > > > > of course not, because the underscore is not part of the syntax for a > > hostname acc. RFC 1034, chapter 3.5. whereas xn--gau- > 7ka.siemens.de is a perfectly valid hostname. > > > > With best regards, > > Rufus Buschart > > > > Siemens AG > > Information Technology > > Human Resources > > PKI / Trustcenter > > GS IT HR 7 4 > > Hugo-Junkers-Str. 9 > > 90411 Nuernberg, Germany > > Tel.: +49 1522 2894134 > > mailto:rufus.busch...@siemens.com > > www.twitter.com/siemens > > > > www.siemens.com/ingenuityforlife > > > > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim > > Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and > > Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, > > Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered > > offices: Berlin and Munich, Germany; Commercial registries: Berlin > > Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 > > > >> -----Ursprüngliche Nachricht----- > >> Von: Dimitris Zacharopoulos <ji...@it.auth.gr> > >> Gesendet: Donnerstag, 24. Januar 2019 11:16 > >> An: Buschart, Rufus (GS IT HR 7 4) <rufus.busch...@siemens.com>; > >> mozilla-dev-security-pol...@lists.mozilla.org > >> Betreff: Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded > >> international domain names > >> > >> On 24/1/2019 10:47 π.μ., Buschart, Rufus via dev-security-policy wrote: > >>> Good morning! > >>> > >>> I would like to sharpen my argument from below a little bit: If a CA > >>> gets a request to issue a certificate for the domain xn--gau- > >> 7ka.siemens.de, how can the CA tell, that xn--gau-7ka is a punycode > >> string in IDNA2008 and not only a very strange server name? At least > >> I don't have a glass bowl to read the mind of my customers. Therefor I > >> would say, it is perfectly okay to issue a certificate for xn-- > gau-7ka.siemens.de as long as you perform a successful domain validation for > xn--gau-7ka.siemens.de. > >> By following this argument, you would also approve issuance of domain > >> names that contain the underscore "_" character, right? > >> > >> Dimitris. > >> > >>> With best regards, > >>> Rufus Buschart > >>> > >>> Siemens AG > >>> Information Technology > >>> Human Resources > >>> PKI / Trustcenter > >>> GS IT HR 7 4 > >>> Hugo-Junkers-Str. 9 > >>> 90411 Nuernberg, Germany > >>> Tel.: +49 1522 2894134 > >>> mailto:rufus.busch...@siemens.com > >>> www.twitter.com/siemens > >>> > >>> www.siemens.com/ingenuityforlife > >>> > >>> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim > >>> Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and > >>> Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, > >>> Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered > >>> offices: Berlin and Munich, Germany; Commercial registries: Berlin > >>> Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE > >>> 23691322 > >>> > >>>> -----Ursprüngliche Nachricht----- > >>>> Von: dev-security-policy > >>>> <dev-security-policy-boun...@lists.mozilla.org> Im Auftrag von > >>>> Buschart, Rufus via dev-security-policy > >>>> Gesendet: Mittwoch, 23. Januar 2019 20:24 > >>>> An: mozilla-dev-security-pol...@lists.mozilla.org > >>>> Betreff: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded > >>>> international domain names > >>>> > >>>> Hello! > >>>> > >>>>> Von: Servercert-wg <mailto:servercert-wg-boun...@cabforum.org> Im > >>>>> Auftrag von Wayne Thayer via Servercert-wg > >>>>> > >>>>>> On Mon, Jan 21, 2019 at 5:50 PM Jeremy Rowley via Servercert-wg > >>>>>> <mailto:servercert...@cabforum.org> wrote: > >>>>>> We received a report for someone saying that certificates issued with > >>>>>> puny-code are mis-issued if they use IDNA2008. > >>>>>> Considering a number of people probably received the same report, I > >>>>>> figured we should raise and discuss the implications > here. > >>>>>> ISSUES: > >>>>>> 1. Does a CA have to check the puny-code provided by a customer > >>>>>> for compliance? Generally, we send the validation request to the > >>>>>> puny-code domain (not the pre-conversation name). This confirms > >>>> control over the domain so is there a need to check this? > >>>>>> If we aren’t doing the conversion, are we actually an implementer in > >>>>>> this case? > >>>>> The BRs require 5280 compliance, so yes I think CAs need to ensure that > >>>>> certificates they sign conform to IDNA2003. > >>>> Where exactly in RFC5280 do you find the requirement that domains > >>>> that follow IDNA2008 but not IDNA2003 are not permitted in a > >>>> certificate? If I understand chapter 7.3 of RFC2008 correctly, it > >>>> describes how to process a domain that follows IDNA2003 (rfc3490) > >> but it does not forbid that a domain can be encoded in IDNA2008 > >> (rfc5890 / rfc5891). It simply says nothing special about how to handle it. > >>>> Therefor I would interpret RFC5280 that in this case the domain > >>>> name in punycode can (or better say MUST) be treated like any other > >>>> domain name. > >>>> > >>>> Excerpt from the bug mentioned by Jürgen: > >>>>> Question: Are ACE-labels not encoded as IDNA 2003 in certificates > >>>>> a misissuance under the Baseline Requirements? Yes, we think > >>>> this is currently the case: > >>>>> Baseline Requirements mandate conformance to exactly RFC 5280 and > >>>>> don't reference/allow any updates, e.g., RFC 8399 > >>>>> > >>>>> Chapter 7.2 of RFC 5280 https://tools.ietf.org/html/rfc5280#page-97 > >>>>> states: > >>>>> "Specifically, conforming implementations MUST perform the > >>>>> conversion operation specified in Section 4 of RFC 3490, with the > >>>> following clarifications: ...." > >>>>> So, IDNs must be converted according to the rules of RFC 3490 > >>>>> > >>>>> We, as a CA, don't perform the conversion mentioned in RFC 5280. > >>>>> We receive/process ACE-labels only. This means that our system > >>>> is likely not meant by the wording "conforming implementations" of RFC > >>>> 5280. > >>>>> However, our systems have the technical means and generally the > >>>>> responsibility to check for correct input. So, we shall > >>>> check/enforce IDNA 2003 ACE-labels. > >>>> > >>>> I don't share your opinion, that you MUST check if a domain is a > >>>> valid IDNA2003 domain, just because you could technically do so. I > >>>> think this leads on a very slippery road. With the same argument > >>>> one could require a CA to scan every web server before the issuance > >>>> of a certificate (or even regularly while the certificate is valid) if > >>>> the web server is distributing malware (BRGs chapter 9.6.3 sub > bullet 8). > >> And this is obviously not the duty of a CA. So I understand the > >> spirit of RFC 5280 and the BRGs that a CA has to perform domain validation > >> on the ACE-label but not to enforce any additional > syntax on top of validated dNSNames. > >>>> With best regards, > >>>> Rufus Buschart > >>>> > >>>> Siemens AG > >>>> Information Technology > >>>> Human Resources > >>>> PKI / Trustcenter > >>>> GS IT HR 7 4 > >>>> Hugo-Junkers-Str. 9 > >>>> 90411 Nuernberg, Germany > >>>> Tel.: +49 1522 2894134 > >>>> mailto:rufus.busch...@siemens.com > >>>> www.twitter.com/siemens > >>>> > >>>> www.siemens.com/ingenuityforlife > >>>> > >>>> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim > >>>> Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and > >>>> Chief Executive Officer; Roland Busch, Lisa Davis, Klaus > >> Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. > >>>> Thomas; Registered offices: Berlin and Munich, Germany; Commercial > >>>> registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; > >>>> WEEE-Reg.-No. DE 23691322 > >>>> > >>>>> -----Ursprüngliche Nachricht----- > >>>>> Von: dev-security-policy > >>>>> <dev-security-policy-boun...@lists.mozilla.org> Im Auftrag von > >>>>> Jürgen Brauckmann via dev-security-policy > >>>>> Gesendet: Mittwoch, 23. Januar 2019 13:42 > >>>>> An: mozilla-dev-security-pol...@lists.mozilla.org > >>>>> Betreff: Incident Report DFN-PKI: Non-IDNA2003 encoded > >>>>> international domain names > >>>>> > >>>>> We received a report about non-idna2003 encoded international > >>>>> domain names. 4 certificates were affected and are revoked by > >>>> now. > >>>>> Details can be found here: > >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1522080 > >>>>> > >>>>> Please also take note of the ongoing discussion regarding this > >>>>> topic in the CA/B Forum's Server Certificate Working Group mailing > >> list: > >>>>> https://cabforum.org/pipermail/servercert-wg/2019-January/000520.html > >>>>> ff. > >>>>> > >>>>> Thanks, > >>>>> Jürgen > >>>>> _______________________________________________ > >>>>> dev-security-policy mailing list > >>>>> dev-security-policy@lists.mozilla.org > >>>>> https://lists.mozilla.org/listinfo/dev-security-policy > >>> _______________________________________________ > >>> dev-security-policy mailing list > >>> dev-security-policy@lists.mozilla.org > >>> https://lists.mozilla.org/listinfo/dev-security-policy > >>> > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
