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.
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
