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
