info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names
550 views
Skip to first unread message
Jürgen Brauckmann
Jan 23, 2019, 7:42:21 AM1/23/19
to mozilla-dev-s...@lists.mozilla.org
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
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
Buschart, Rufus
Jan 23, 2019, 2:24:36 PM1/23/19
to mozilla-dev-s...@lists.mozilla.org
Hello!
> Von: Servercert-wg <mailto:servercert...@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:server...@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.b...@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-...@lists.mozilla.org> Im Auftrag von Jürgen Brauckmann via dev-security-policy
> Gesendet: Mittwoch, 23. Januar 2019 13:42
> An: mozilla-dev-s...@lists.mozilla.org
> Betreff: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> Von: Servercert-wg <mailto:servercert...@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:server...@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.b...@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-...@lists.mozilla.org> Im Auftrag von Jürgen Brauckmann via dev-security-policy
> Gesendet: Mittwoch, 23. Januar 2019 13:42
> An: mozilla-dev-s...@lists.mozilla.org
> Betreff: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
Buschart, Rufus
Jan 24, 2019, 3:48:09 AM1/24/19
to mozilla-dev-s...@lists.mozilla.org
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.b...@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-...@lists.mozilla.org> Im Auftrag von Buschart, Rufus via dev-security-policy
> Gesendet: Mittwoch, 23. Januar 2019 20:24
> An: mozilla-dev-s...@lists.mozilla.org
> Betreff: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names
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.b...@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-----
> Gesendet: Mittwoch, 23. Januar 2019 20:24
> An: mozilla-dev-s...@lists.mozilla.org
> Betreff: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names
Kurt Roeckx
Jan 24, 2019, 4:04:23 AM1/24/19
to mozilla-dev-s...@lists.mozilla.org
On 2019-01-24 9:47, Buschart, Rufus 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.
Will you fill something in in the commonName? I think what is expected
> 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.
in the commonName is what the user would type and expect to see, I don't
think the commonName should contain xn--gau-7ka.siemens.de. If you have
a commonName, I would expect that it contains gauß.siemens.de. And if
you create a commonName then, you are required to check that it matches
the xn--gau-7ka.siemens.de in the SAN.
Kurt
Dimitris Zacharopoulos
Jan 24, 2019, 5:15:22 AM1/24/19
to Buschart, Rufus, mozilla-dev-s...@lists.mozilla.org
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
> 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.
names that contain the underscore "_" character, right?
Dimitris.
Buschart, Rufus
Jan 24, 2019, 5:21:38 AM1/24/19
to Dimitris Zacharopoulos, mozilla-dev-s...@lists.mozilla.org
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.b...@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.b...@siemens.com>; mozilla-dev-s...@lists.mozilla.org
> Betreff: Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names
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.b...@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-----
> Gesendet: Donnerstag, 24. Januar 2019 11:16
> An: Buschart, Rufus (GS IT HR 7 4) <rufus.b...@siemens.com>; mozilla-dev-s...@lists.mozilla.org
> Betreff: Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names
Buschart, Rufus
Jan 24, 2019, 5:35:44 AM1/24/19
to mozilla-dev-s...@lists.mozilla.org
Hello Kurt!
We don't fill in the CN of a certificate. We verify that in the CSR of the customer the subject:CommonName is part of the extensions:subjectAltName (as required in BRGs 7.1.4.2.2.a). So we would only issue a certificate with:
{
CN = xn--gau-7ka.siemens.de
SAN = xn--gau-7ka.siemens.de, gauss.siemens.de
}
but not with
{
CN = gauß.siemens.de
SAN = xn--gau-7ka.siemens.de, gauss.siemens.de
}
And technically I don't see any reason why someone would want to have a certificate with CN = gauß.siemens.de, as the unicode URL gauß.siemens.de is only of interest in the address bar of the browser and they perform the IDNA conversion.
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.b...@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-...@lists.mozilla.org> Im Auftrag von Kurt Roeckx via dev-security-policy
> Gesendet: Donnerstag, 24. Januar 2019 10:04
> An: mozilla-dev-s...@lists.mozilla.org
> Betreff: Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names
We don't fill in the CN of a certificate. We verify that in the CSR of the customer the subject:CommonName is part of the extensions:subjectAltName (as required in BRGs 7.1.4.2.2.a). So we would only issue a certificate with:
{
CN = xn--gau-7ka.siemens.de
SAN = xn--gau-7ka.siemens.de, gauss.siemens.de
}
but not with
{
CN = gauß.siemens.de
SAN = xn--gau-7ka.siemens.de, gauss.siemens.de
}
And technically I don't see any reason why someone would want to have a certificate with CN = gauß.siemens.de, as the unicode URL gauß.siemens.de is only of interest in the address bar of the browser and they perform the IDNA conversion.
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.b...@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-----
> Gesendet: Donnerstag, 24. Januar 2019 10:04
> An: mozilla-dev-s...@lists.mozilla.org
> Betreff: Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names
>
> On 2019-01-24 9:47, Buschart, Rufus wrote:
> On 2019-01-24 9:47, Buschart, Rufus 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.
>
> >
> > 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.
>
> Will you fill something in in the commonName? I think what is expected in the commonName is what the user would type and expect
> to see, I don't think the commonName should contain xn--gau-7ka.siemens.de. If you have a commonName, I would expect that it
> contains gauß.siemens.de. And if you create a commonName then, you are required to check that it matches the xn--gau-
> 7ka.siemens.de in the SAN.
>
>
> Kurt
> to see, I don't think the commonName should contain xn--gau-7ka.siemens.de. If you have a commonName, I would expect that it
> contains gauß.siemens.de. And if you create a commonName then, you are required to check that it matches the xn--gau-
> 7ka.siemens.de in the SAN.
>
>
> Kurt
Dimitris Zacharopoulos
Jan 24, 2019, 5:52:22 AM1/24/19
to Buschart, Rufus, mozilla-dev-s...@lists.mozilla.org
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.
>
>>>> international domain names
>>>>
>>>>> domain names
>>>>>
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.b...@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-----
>> An: Buschart, Rufus (GS IT HR 7 4) <rufus.b...@siemens.com>; mozilla-dev-s...@lists.mozilla.org
> 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.b...@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-----
>> 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.
>>> 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.
>>
>>
>> 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.b...@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-...@lists.mozilla.org> Im Auftrag von
>>> 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.b...@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-...@lists.mozilla.org> Im Auftrag von
>>>> Buschart, Rufus via dev-security-policy
>>>> Gesendet: Mittwoch, 23. Januar 2019 20:24
>>>> An: mozilla-dev-s...@lists.mozilla.org
>>>> Betreff: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded
>>>> Gesendet: Mittwoch, 23. Januar 2019 20:24
>>>> An: mozilla-dev-s...@lists.mozilla.org
>>>> international domain names
>>>>
>>>> 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.b...@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-...@lists.mozilla.org> Im Auftrag von
>>>> 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.b...@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-...@lists.mozilla.org> Im Auftrag von
>>>>> Jürgen Brauckmann via dev-security-policy
>>>>> Gesendet: Mittwoch, 23. Januar 2019 13:42
>>>>> An: mozilla-dev-s...@lists.mozilla.org
>>>>> Betreff: Incident Report DFN-PKI: Non-IDNA2003 encoded international
>>>>> Gesendet: Mittwoch, 23. Januar 2019 13:42
>>>>> An: mozilla-dev-s...@lists.mozilla.org
>>>>> 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
>>>>> 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
Rob Stradling
Jan 24, 2019, 6:08:27 AM1/24/19
to Kurt Roeckx, mozilla-dev-s...@lists.mozilla.org
On 24/01/2019 09:04, Kurt Roeckx via dev-security-policy wrote:
> On 2019-01-24 9:47, Buschart, Rufus wrote:
> On 2019-01-24 9:47, Buschart, Rufus 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.
>
>>
>> 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.
>
> Will you fill something in in the commonName? I think what is expected
> in the commonName is what the user would type and expect to see, I don't
> think the commonName should contain xn--gau-7ka.siemens.de. If you have
> a commonName, I would expect that it contains gauß.siemens.de.
Hi Kurt.
> in the commonName is what the user would type and expect to see, I don't
> think the commonName should contain xn--gau-7ka.siemens.de. If you have
> a commonName, I would expect that it contains gauß.siemens.de.
BRs 7.1.4.2.2 says that the subject:commonName "MUST contain a single IP
address or Fully-Qualified Domain Name that is one of the values
contained in the Certificate’s subjectAltName extension (see Section
7.1.4.2.1)."
Fitting the U-label into subjectAltName:dNSName (an IA5String, not a
UTF8String) would be...hard, so in practice the dNSName has to contain
the A-label.
So what does "is one of the values" mean? It's certainly valid to use
the A-label in both the CN and SAN:dNSName. However, it's arguably
invalid (or at least it's not obviously valid) to put the A-label in the
SAN:dNSName and the corresponding U-label in the CN. (i.e., the U-label
and the A-label are different representations of the same value, but
they are not the same value).
This issue is one of the things that CABForum ballot 202 sought to
clarify, and IIRC it was actually the reason why ballot 202 failed.
> And if
> you create a commonName then, you are required to check that it matches
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
Buschart, Rufus
Jan 24, 2019, 6:14:22 AM1/24/19
to mozilla-dev-s...@lists.mozilla.org
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.b...@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
> Betreff: Re: AW: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names
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.b...@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>
> Betreff: Re: AW: 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.
> >>> 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.
Hanno Böck
Jan 24, 2019, 6:36:05 AM1/24/19
to dev-secur...@lists.mozilla.org, Buschart, Rufus
On Thu, 24 Jan 2019 11:14:11 +0000
"Buschart, Rufus via dev-security-policy"
4.2.3.1. Hyphen Restrictions
The Unicode string MUST NOT contain "--" (two consecutive hyphens) in
the third and fourth character positions and MUST NOT start or end
with a "-" (hyphen).
This means you can't have a valid host name that is just
xn--[something]. You can only have it if it is also a valid IDN name.
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
"Buschart, Rufus via dev-security-policy"
<dev-secur...@lists.mozilla.org> wrote:
> 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.
https://tools.ietf.org/html/rfc5891
> 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.
4.2.3.1. Hyphen Restrictions
The Unicode string MUST NOT contain "--" (two consecutive hyphens) in
the third and fourth character positions and MUST NOT start or end
with a "-" (hyphen).
This means you can't have a valid host name that is just
xn--[something]. You can only have it if it is also a valid IDN name.
--
Hanno Böck
https://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
Buschart, Rufus
Jan 24, 2019, 7:17:18 AM1/24/19
to dev-secur...@lists.mozilla.org
Hello
> -----Ursprüngliche Nachricht-----
> Von: Hanno Böck <ha...@hboeck.de>
> Gesendet: Donnerstag, 24. Januar 2019 12:36
While all ACE labels begin with the ACE prefix, not all labels
beginning with the ACE prefix are necessarily ACE labels. Non-ACE
labels that begin with the ACE prefix will confuse users and SHOULD
NOT be allowed in DNS zones.
But first of all this is only a SHOULD requirement and second it places the burden on the operator of the DNS zones.
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.b...@siemens.com
> -----Ursprüngliche Nachricht-----
> Von: Hanno Böck <ha...@hboeck.de>
> Gesendet: Donnerstag, 24. Januar 2019 12:36
>
> On Thu, 24 Jan 2019 11:14:11 +0000
> "Buschart, Rufus via dev-security-policy"
> <dev-secur...@lists.mozilla.org> wrote:
>
> > 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.
>
> https://tools.ietf.org/html/rfc5891
>
> 4.2.3.1. Hyphen Restrictions
>
> The Unicode string MUST NOT contain "--" (two consecutive hyphens) in
> the third and fourth character positions and MUST NOT start or end
> with a "-" (hyphen).
>
> This means you can't have a valid host name that is just xn--[something]. You can only have it if it is also a valid IDN name.
>
I don't read it like this. This chapter describes the "Unicode string" which is the U-label before conversion. The hostname is the A-label after conversion and in the certificate you find the hostname. The RFC 3490 clearly addressed this issue:
> On Thu, 24 Jan 2019 11:14:11 +0000
> "Buschart, Rufus via dev-security-policy"
> <dev-secur...@lists.mozilla.org> wrote:
>
> > 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.
>
> https://tools.ietf.org/html/rfc5891
>
> 4.2.3.1. Hyphen Restrictions
>
> The Unicode string MUST NOT contain "--" (two consecutive hyphens) in
> the third and fourth character positions and MUST NOT start or end
> with a "-" (hyphen).
>
> This means you can't have a valid host name that is just xn--[something]. You can only have it if it is also a valid IDN name.
>
While all ACE labels begin with the ACE prefix, not all labels
beginning with the ACE prefix are necessarily ACE labels. Non-ACE
labels that begin with the ACE prefix will confuse users and SHOULD
NOT be allowed in DNS zones.
But first of all this is only a SHOULD requirement and second it places the burden on the operator of the DNS zones.
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.b...@siemens.com
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
Important notice: This e-mail and any attachment thereof contain corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system. Thank you.
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
Kurt Roeckx
Jan 24, 2019, 9:09:41 AM1/24/19
to mozilla-dev-s...@lists.mozilla.org
On 2019-01-24 12:08, Rob Stradling wrote:
>
> Hi Kurt.
>
> BRs 7.1.4.2.2 says that the subject:commonName "MUST contain a single IP
> address or Fully-Qualified Domain Name that is one of the values
> contained in the Certificate’s subjectAltName extension (see Section
> 7.1.4.2.1)."
>
> Fitting the U-label into subjectAltName:dNSName (an IA5String, not a
> UTF8String) would be...hard, so in practice the dNSName has to contain
> the A-label.
>
> So what does "is one of the values" mean? It's certainly valid to use
> the A-label in both the CN and SAN:dNSName. However, it's arguably
> invalid (or at least it's not obviously valid) to put the A-label in the
> SAN:dNSName and the corresponding U-label in the CN. (i.e., the U-label
> and the A-label are different representations of the same value, but
> they are not the same value).
I expect all fields in the subject to be things you can just read, so
>
> Hi Kurt.
>
> BRs 7.1.4.2.2 says that the subject:commonName "MUST contain a single IP
> address or Fully-Qualified Domain Name that is one of the values
> contained in the Certificate’s subjectAltName extension (see Section
> 7.1.4.2.1)."
>
> Fitting the U-label into subjectAltName:dNSName (an IA5String, not a
> UTF8String) would be...hard, so in practice the dNSName has to contain
> the A-label.
>
> So what does "is one of the values" mean? It's certainly valid to use
> the A-label in both the CN and SAN:dNSName. However, it's arguably
> invalid (or at least it's not obviously valid) to put the A-label in the
> SAN:dNSName and the corresponding U-label in the CN. (i.e., the U-label
> and the A-label are different representations of the same value, but
> they are not the same value).
U-labels. It does not make sense to show users an A-label, they do not
understand what that means. The fields in a subject allows writing
things in Unicode, there is no reason not to use it. The A-label is
really just an technical thing related to DNS, and so only belongs in
places where for technical reasons you need to use it. If you want to
show them rfc5280 says you "should" convert them to Unicode. For fields
where you can write Unicode, there really isn't a reason to not put the
Unicode in it directly.
So in my opinion, the CN would be "gauß.siemens.de", and the SAN would
be "xn--gau-7ka.siemens.de". They might add some alternatives like
gauss.siemens.de to the SAN, and you can then also use that as CN. (But
I think they should stop using that ss for ß, and really use gauß.)
I think that if you want to force the use of A-labels in the CN field
that you should really update RFC5280 and X.520, so that IA5String is
the only option in CN. But that just doesn't make any sense.
Kurt
Rob Stradling
Jan 24, 2019, 9:41:38 AM1/24/19
to Kurt Roeckx, mozilla-dev-s...@lists.mozilla.org
On 24/01/2019 14:09, Kurt Roeckx via dev-security-policy wrote:
> On 2019-01-24 12:08, Rob Stradling wrote:
>>
> On 2019-01-24 12:08, Rob Stradling wrote:
>>
>> Hi Kurt.
>>
>> BRs 7.1.4.2.2 says that the subject:commonName "MUST contain a single IP
>> address or Fully-Qualified Domain Name that is one of the values
>> contained in the Certificate’s subjectAltName extension (see Section
>> 7.1.4.2.1)."
>>
>> Fitting the U-label into subjectAltName:dNSName (an IA5String, not a
>> UTF8String) would be...hard, so in practice the dNSName has to contain
>> the A-label.
>>
>> So what does "is one of the values" mean? It's certainly valid to use
>> the A-label in both the CN and SAN:dNSName. However, it's arguably
>> invalid (or at least it's not obviously valid) to put the A-label in the
>> SAN:dNSName and the corresponding U-label in the CN. (i.e., the U-label
>> and the A-label are different representations of the same value, but
>> they are not the same value).
>
>>
>> BRs 7.1.4.2.2 says that the subject:commonName "MUST contain a single IP
>> address or Fully-Qualified Domain Name that is one of the values
>> contained in the Certificate’s subjectAltName extension (see Section
>> 7.1.4.2.1)."
>>
>> Fitting the U-label into subjectAltName:dNSName (an IA5String, not a
>> UTF8String) would be...hard, so in practice the dNSName has to contain
>> the A-label.
>>
>> So what does "is one of the values" mean? It's certainly valid to use
>> the A-label in both the CN and SAN:dNSName. However, it's arguably
>> invalid (or at least it's not obviously valid) to put the A-label in the
>> SAN:dNSName and the corresponding U-label in the CN. (i.e., the U-label
>> and the A-label are different representations of the same value, but
>> they are not the same value).
>
> I expect all fields in the subject to be things you can just read, so
> U-labels. It does not make sense to show users an A-label, they do not
> understand what that means. The fields in a subject allows writing
> things in Unicode, there is no reason not to use it.
<snip>
> U-labels. It does not make sense to show users an A-label, they do not
> understand what that means. The fields in a subject allows writing
> things in Unicode, there is no reason not to use it.
Here's an example cert containing the A-label in the SAN:dNSName and the
U-label in the CN. (It was issued by Sectigo, known back then as Comodo
CA, before we switched to always putting the A-label in the CN):
https://crt.sh/?id=213062481&opt=cablint,x509lint,zlint
x509lint agrees with your opinion (unsurprisingly!), but both cablint
and zlint complain.
Peter Bowen
Jan 24, 2019, 10:17:54 AM1/24/19
to Buschart, Rufus, dev-secur...@lists.mozilla.org
On Thu, Jan 24, 2019 at 4:17 AM Buschart, Rufus via dev-security-policy <
I agree with Rufus. There are really two issues here:
1) The original reports to the CAs claimed an issue because RFC 5280
references the original IDNA RFCs (now known as IDNA2003).
RFC 5280 says "Rules for encoding internationalized domain names are
specified in Section 7.2 <https://tools.ietf.org/html/rfc5280#section-7.2>."
Section 7.2 says: "one choice in GeneralName is the dNSName field, which is
defined as type IA5String. IA5String is limited to the set of ASCII
characters. To accommodate internationalized domain names in the current
structure, conforming implementations MUST convert internationalized domain
names to the ASCII Compatible Encoding (ACE) format as specified in Section
4 of RFC 3490 before storage in the dNSName field."
This makes it clear it is only discussing a case where a domain name is
processed that does not meet the IA5String semantics. Therefore both "
xn--foo-bar-ghost.example.com" or "zq--special.example.com" are both
acceptable in certificates as these do not need encoding and are valid
preferred name syntax.
2) How should CAs handle this going forward?
RFC 8399, dated May 2018, explicitly updates RFC 5280. It says "Conforming
CAs SHOULD ensure that IDNs are valid. This can be done by validating all
code points according to IDNA2008 [RFC5892]." Note that this is only a
"SHOULD". The CA/Browser Forum ballot 202 attempted to make this stricter,
requiring that CAs not issue for names that contain Reserved LDH labels
unless they start with the ACE prefix and the remainder is valid Punycode.
However this ballot failed.
This leaves us at the point that CAs "SHOULD" ensure IDNs are valid, but
they may issue for names with any LDH label that passes the validation of
control required by the BRs.
Maybe Mozilla should add something about acceptable LDH labels to the CA
policy?
Thanks,
Peter
1) The original reports to the CAs claimed an issue because RFC 5280
references the original IDNA RFCs (now known as IDNA2003).
RFC 5280 says "Rules for encoding internationalized domain names are
specified in Section 7.2 <https://tools.ietf.org/html/rfc5280#section-7.2>."
Section 7.2 says: "one choice in GeneralName is the dNSName field, which is
defined as type IA5String. IA5String is limited to the set of ASCII
characters. To accommodate internationalized domain names in the current
structure, conforming implementations MUST convert internationalized domain
names to the ASCII Compatible Encoding (ACE) format as specified in Section
4 of RFC 3490 before storage in the dNSName field."
This makes it clear it is only discussing a case where a domain name is
processed that does not meet the IA5String semantics. Therefore both "
xn--foo-bar-ghost.example.com" or "zq--special.example.com" are both
acceptable in certificates as these do not need encoding and are valid
preferred name syntax.
2) How should CAs handle this going forward?
RFC 8399, dated May 2018, explicitly updates RFC 5280. It says "Conforming
CAs SHOULD ensure that IDNs are valid. This can be done by validating all
code points according to IDNA2008 [RFC5892]." Note that this is only a
"SHOULD". The CA/Browser Forum ballot 202 attempted to make this stricter,
requiring that CAs not issue for names that contain Reserved LDH labels
unless they start with the ACE prefix and the remainder is valid Punycode.
However this ballot failed.
This leaves us at the point that CAs "SHOULD" ensure IDNs are valid, but
they may issue for names with any LDH label that passes the validation of
control required by the BRs.
Maybe Mozilla should add something about acceptable LDH labels to the CA
policy?
Thanks,
Peter
Kurt Roeckx
Jan 24, 2019, 10:36:31 AM1/24/19
to mozilla-dev-s...@lists.mozilla.org
On 2019-01-24 15:41, Rob Stradling wrote:
>
> Here's an example cert containing the A-label in the SAN:dNSName and the
> U-label in the CN. (It was issued by Sectigo, known back then as Comodo
> CA, before we switched to always putting the A-label in the CN):
>
> https://crt.sh/?id=213062481&opt=cablint,x509lint,zlint
>
> x509lint agrees with your opinion (unsurprisingly!), but both cablint
> and zlint complain.
x509lint doesn't do anything related to this. I've disabled the code to
>
> Here's an example cert containing the A-label in the SAN:dNSName and the
> U-label in the CN. (It was issued by Sectigo, known back then as Comodo
> CA, before we switched to always putting the A-label in the CN):
>
> https://crt.sh/?id=213062481&opt=cablint,x509lint,zlint
>
> x509lint agrees with your opinion (unsurprisingly!), but both cablint
> and zlint complain.
check that the CN is one of the SANs because I didn't write the code
related to the conversion from the U-label to the A-label yet. It used
to behave exactly like zlint and say it doesn't match, but I think
that's wrong. It's was clearly my intention to say that a certificate
like that is the correct way to do it. One of the reasons I didn't do
this is that it was not obvious to me at that time which is the correct
standard to use, which I guess is why this thread was started.
Kurt
Peter Bowen
Jan 24, 2019, 10:41:36 AM1/24/19
to Kurt Roeckx, mozilla-dev-s...@lists.mozilla.org
On Thu, Jan 24, 2019 at 7:36 AM Kurt Roeckx via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> On 2019-01-24 15:41, Rob Stradling wrote:
> >
dev-secur...@lists.mozilla.org> wrote:
> On 2019-01-24 15:41, Rob Stradling wrote:
> >
> > Here's an example cert containing the A-label in the SAN:dNSName and the
> > U-label in the CN. (It was issued by Sectigo, known back then as Comodo
> > CA, before we switched to always putting the A-label in the CN):
> >
> > https://crt.sh/?id=213062481&opt=cablint,x509lint,zlint
> >
> > x509lint agrees with your opinion (unsurprisingly!), but both cablint
> > and zlint complain.
>
> > U-label in the CN. (It was issued by Sectigo, known back then as Comodo
> > CA, before we switched to always putting the A-label in the CN):
> >
> > https://crt.sh/?id=213062481&opt=cablint,x509lint,zlint
> >
> > x509lint agrees with your opinion (unsurprisingly!), but both cablint
> > and zlint complain.
>
> x509lint doesn't do anything related to this. I've disabled the code to
> check that the CN is one of the SANs because I didn't write the code
> related to the conversion from the U-label to the A-label yet. It used
> to behave exactly like zlint and say it doesn't match, but I think
> that's wrong. It's was clearly my intention to say that a certificate
> like that is the correct way to do it. One of the reasons I didn't do
> this is that it was not obvious to me at that time which is the correct
> standard to use, which I guess is why this thread was started.
You don’t need to choose between IDNA2003 and 2008 to do A-label to
> check that the CN is one of the SANs because I didn't write the code
> related to the conversion from the U-label to the A-label yet. It used
> to behave exactly like zlint and say it doesn't match, but I think
> that's wrong. It's was clearly my intention to say that a certificate
> like that is the correct way to do it. One of the reasons I didn't do
> this is that it was not obvious to me at that time which is the correct
> standard to use, which I guess is why this thread was started.
U-label. That direction is identical for both. So you can try each of the
SANs and see if it decides to the CN.
>
Buschart, Rufus
Jan 24, 2019, 11:55:22 AM1/24/19
to Kurt Roeckx, mozilla-dev-s...@lists.mozilla.org
Hi Kurt!
> -----Ursprüngliche Nachricht-----
> Von: dev-security-policy <dev-security-...@lists.mozilla.org> Im Auftrag von Kurt Roeckx via dev-security-policy
> The fields in a subject allows writing things in Unicode, there is no reason not to use it.
Sure it allows it, but as long as the CA doesn't permits it, the CA doesn't have to do any conversion from U-label to A-label at all.
> The A-label is
> really just an technical thing related to DNS, and so only belongs in places where for technical reasons you need to use it.
Like the CN, as nobody non-technical ever sees the CN.
> If you want
> to show them rfc5280 says you "should" convert them to Unicode. For fields where you can write Unicode, there really isn't a reason
> to not put the Unicode in it directly.
>
> So in my opinion, the CN would be "gauß.siemens.de", and the SAN would be "xn--gau-7ka.siemens.de". They might add some
> alternatives like gauss.siemens.de to the SAN, and you can then also use that as CN. (But I think they should stop using that ss for ß,
> and really use gauß.)
I agree, that if a CA issues a certificate with the CN "gauß.siemens.de" the CA has to perform a conversion acc. IDNA2003 for all checks, but if the CA only issues the CN "xn--gau-7ka.siemens.de" they don't have to care if this is IDNA2003 or IDNA2008.
>
> I think that if you want to force the use of A-labels in the CN field that you should really update RFC5280 and X.520, so that IA5String is
> the only option in CN. But that just doesn't make any sense.
I don't want to force anybody not to use Unicode in the CN, but I want to make clear, that if a CA only allows CNs that follow RFC 1034, chapter 3.5, they don't have to care about compliance with IDNA2008 / IDNA2003.
> -----Ursprüngliche Nachricht-----
> Von: dev-security-policy <dev-security-...@lists.mozilla.org> Im Auftrag von Kurt Roeckx via dev-security-policy
> I expect all fields in the subject to be things you can just read, so U-labels. It does not make sense to show users an A-label, they do
> not understand what that means.
Normally the content of a certificate is not shown to the end user at all. The end user sees the address bar of the browser. In the address bar of the browser the U-label is shown. Then the browser makes the translation from the U-label to the A-label, either using IDNA2003 or IDNA2008. We should check the behavior of SSH clients but how many SSH client users are there compared to browser users?
> not understand what that means.
> The fields in a subject allows writing things in Unicode, there is no reason not to use it.
> The A-label is
> really just an technical thing related to DNS, and so only belongs in places where for technical reasons you need to use it.
> If you want
> to show them rfc5280 says you "should" convert them to Unicode. For fields where you can write Unicode, there really isn't a reason
> to not put the Unicode in it directly.
>
> So in my opinion, the CN would be "gauß.siemens.de", and the SAN would be "xn--gau-7ka.siemens.de". They might add some
> alternatives like gauss.siemens.de to the SAN, and you can then also use that as CN. (But I think they should stop using that ss for ß,
> and really use gauß.)
>
> I think that if you want to force the use of A-labels in the CN field that you should really update RFC5280 and X.520, so that IA5String is
> the only option in CN. But that just doesn't make any sense.
Tim Hollebeek
Jan 24, 2019, 2:19:42 PM1/24/19
to Kurt Roeckx, mozilla-dev-s...@lists.mozilla.org
I think the assertion that the commonName has anything to do with what the
user would type and expect to see is unsupported by any of the relevant
standards, and as Rob noted, having it be different from the SAN strings is
not in compliance with the Baseline Requirements. It's also deprecated. If
anything, it should cease to exist.
Requiring translation to a U-label by the CA adds a lot of additional complexity
with no benefit.
What users type and see are issues that are best left to Application Software
Suppliers (browsers).
-Tim
> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org>
> On Behalf Of Kurt Roeckx via dev-security-policy
> Sent: Thursday, January 24, 2019 4:04 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded
> international domain names
>
> %3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
user would type and expect to see is unsupported by any of the relevant
standards, and as Rob noted, having it be different from the SAN strings is
not in compliance with the Baseline Requirements. It's also deprecated. If
anything, it should cease to exist.
Requiring translation to a U-label by the CA adds a lot of additional complexity
with no benefit.
What users type and see are issues that are best left to Application Software
Suppliers (browsers).
-Tim
> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org>
> On Behalf Of Kurt Roeckx via dev-security-policy
> Sent: Thursday, January 24, 2019 4:04 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded
> international domain names
>
> On 2019-01-24 9:47, Buschart, Rufus 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.
>
> >
> > 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.
>
> Will you fill something in in the commonName? I think what is expected in
> the commonName is what the user would type and expect to see, I don't
> think the commonName should contain xn--gau-7ka.siemens.de. If you have
> a commonName, I would expect that it contains gauß.siemens.de. And if you
> the commonName is what the user would type and expect to see, I don't
> think the commonName should contain xn--gau-7ka.siemens.de. If you have
> create a commonName then, you are required to check that it matches the
> xn--gau-7ka.siemens.de in the SAN.
>
>
> Kurt
> xn--gau-7ka.siemens.de in the SAN.
>
>
> Kurt
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://clicktime.symantec.com/36Cdb8NdVuWoSCnRVsmajRE7Vc?u=https
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> %3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
Wayne Thayer
Jan 24, 2019, 8:33:51 PM1/24/19
to Peter Bowen, Buschart, Rufus, dev-secur...@lists.mozilla.org
On Thu, Jan 24, 2019 at 8:17 AM Peter Bowen via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> I agree with Rufus. There are really two issues here:
>
> 1) The original reports to the CAs claimed an issue because RFC 5280
> references the original IDNA RFCs (now known as IDNA2003).
>
> RFC 5280 says "Rules for encoding internationalized domain names are
> specified in Section 7.2 <https://tools.ietf.org/html/rfc5280#section-7.2
> >."
> Section 7.2 says: "one choice in GeneralName is the dNSName field, which is
> defined as type IA5String. IA5String is limited to the set of ASCII
> characters. To accommodate internationalized domain names in the current
> structure, conforming implementations MUST convert internationalized domain
> names to the ASCII Compatible Encoding (ACE) format as specified in Section
> 4 of RFC 3490 before storage in the dNSName field."
>
> This makes it clear it is only discussing a case where a domain name is
> processed that does not meet the IA5String semantics. Therefore both "
> xn--foo-bar-ghost.example.com" or "zq--special.example.com" are both
> acceptable in certificates as these do not need encoding and are valid
> preferred name syntax.
>
> Thank you for weighing in on this Peter. I think your (and Rufus')
dev-secur...@lists.mozilla.org> wrote:
>
> I agree with Rufus. There are really two issues here:
>
> 1) The original reports to the CAs claimed an issue because RFC 5280
> references the original IDNA RFCs (now known as IDNA2003).
>
> RFC 5280 says "Rules for encoding internationalized domain names are
> specified in Section 7.2 <https://tools.ietf.org/html/rfc5280#section-7.2
> >."
> Section 7.2 says: "one choice in GeneralName is the dNSName field, which is
> defined as type IA5String. IA5String is limited to the set of ASCII
> characters. To accommodate internationalized domain names in the current
> structure, conforming implementations MUST convert internationalized domain
> names to the ASCII Compatible Encoding (ACE) format as specified in Section
> 4 of RFC 3490 before storage in the dNSName field."
>
> This makes it clear it is only discussing a case where a domain name is
> processed that does not meet the IA5String semantics. Therefore both "
> xn--foo-bar-ghost.example.com" or "zq--special.example.com" are both
> acceptable in certificates as these do not need encoding and are valid
> preferred name syntax.
>
interpretation of section 7.2 is a stretch, but I can admit that it isn't
clear if the intent is to require conformance to RFC 3490 if the string
does not require conversion. Given the ambiguity, I am now leaning toward
treating these misissuance reports as invalid.
2) How should CAs handle this going forward?
>
> RFC 8399, dated May 2018, explicitly updates RFC 5280. It says "Conforming
> CAs SHOULD ensure that IDNs are valid. This can be done by validating all
> code points according to IDNA2008 [RFC5892]." Note that this is only a
> "SHOULD". The CA/Browser Forum ballot 202 attempted to make this stricter,
> requiring that CAs not issue for names that contain Reserved LDH labels
> unless they start with the ACE prefix and the remainder is valid Punycode.
> However this ballot failed.
>
> This leaves us at the point that CAs "SHOULD" ensure IDNs are valid, but
> they may issue for names with any LDH label that passes the validation of
> control required by the BRs.
>
> Maybe Mozilla should add something about acceptable LDH labels to the CA
> policy?
>
raised with this part of ballot 202 [2], so before creating a
Mozilla-specific policy I'd like to take another crack at solving it in the
BRs.
[1] https://cabforum.org/pipermail/public/2017-July/011774.html
[2]
https://cabforum.org/2017/07/26/ballot-202-underscore-wildcard-characters/
> Thanks,
> Peter
>
>
Kurt Roeckx
Jan 25, 2019, 4:13:44 AM1/25/19
to mozilla-dev-s...@lists.mozilla.org
On 2019-01-24 20:19, Tim Hollebeek wrote:
> I think the assertion that the commonName has anything to do with what the
> user would type and expect to see is unsupported by any of the relevant
> standards, and as Rob noted, having it be different from the SAN strings is
> not in compliance with the Baseline Requirements.
The BR do not say anything about it.
> I think the assertion that the commonName has anything to do with what the
> user would type and expect to see is unsupported by any of the relevant
> standards, and as Rob noted, having it be different from the SAN strings is
> not in compliance with the Baseline Requirements.
> It's also deprecated. If anything, it should cease to exist.
> Requiring translation to a U-label by the CA adds a lot of additional complexity
> with no benefit.
certificate, it's really just calling a function. On the other hand,
when reading a certificate you have to guess what they did.
And if it's really to complex, just remove the CN, or is that too
complex too?
> What users type and see are issues that are best left to Application Software
> Suppliers (browsers).
should instead add complexity?
Kurt
Nick Lamb
Jan 25, 2019, 8:03:44 AM1/25/19
to dev-secur...@lists.mozilla.org, Kurt Roeckx
On Thu, 24 Jan 2019 10:04:00 +0100
In Firefox (our most direct concern here on m.d.s.policy) of course CN
is entirely ignored for matching certificates in the Web PKI.
However many other clients exist, and we know most of them continue to
parse CN as you might have done twenty years ago trying to find some IP
address or DNS name in the human readable text. In some cases they
either don't understand SANs, or they prioritise matching CN over SANs.
This is a bad idea (if you are reading this and have responsibility for
the name matching algorithm in either a client or library I implore you
to go look at this again) but it's out there today and isn't going
away in the immediate future.
Concrete example: Until relatively recently Python's SSL/TLS
implementation, including in the very popular "Requests" library, would
match a Unicode hostname string against CN or SANs, even though that's
not correct behaviour. When a user asks to connect to 瞺瞹砡.example
the Python code correctly determines that it needs the DNS name
xn--b6yb42a.example to find the IP address but it still expects the
certificate to match 瞺瞹砡.example not xn--b6yb42a.example. This is of
course impossible for SANs by definition, and that impossibility was
helpful in persuading developers that their understanding of what
needed to happen here couldn't be correct.
I (as a relying party) would prefer that failure modes that fall out of
this sort of error aren't fatal to security. CAs that write SANs as
IA5-Strings with A-labels into CN fail safely here, whereas those which
try to conjure U-labels for a Unicode String risk tricking some of this
bad parser code into accepting a certificate for one name as valid for
a similar but different name or blowing up the parser itself (I haven't
seen examples where UCS-2 string data ends up written to a NUL-byte
terminated C string but I would not be surprised if it happens)
For compatibility reasons omitting CN altogether is not usually a good
plan, so to me that leaves writing the A-labels as the best option. I
believe Let's Encrypt currently has experiments ongoing as to how to
opt out of writing CN, but there's no intent to actually stop doing it
by default.
Second, a philosophical response:
The purpose of the Subject DN is to identify the Subject to a Relying
Party and we want it to be clear exactly which Subject we're
identifying. It is difficult, and maybe impossible, for a Certificate
Authority to specify how the user's input will be handled or how
exactly a name will be displayed in every possible user agent software.
On the other hand, the DNS A-labels, though unfamiliar to a human and
unwieldy to think about, have the advantage that they're definitely
identifying the specific thing we validated, not anything with a
different but similar name.
The reason it's hard for the CA to reason about Unicode names is that
not only do you have all of IDNA-2003, IDNA-2008, TR#46 but also
browsers have lots of counter measures (and the exact counter measures
deployed in famous brand browsers have changed over time) for the
problem of confusable DNS names. A browser may choose to write an IDN
in Punycode to avoid confusing users into believing the IDN is actually
some distinct name that merely looks similar.
My preferred outcome here would be for CAs to just voluntarily
choose not to write U-labels into CN AND for user agents to stop trying
to parse CN instead of just handling SANs. I think that's easier and
safer for basically everybody. But I don't feel strongly enough about
it that I feel we want "Incident Reports" for every scenario where this
didn't happen.
I do feel strongly enough about it that if a incident does happen and
the proximate cause was "We write U-labels into CN and that tripped a
bug" there's a good chance I will do the Nelson Muntz laugh and no
chance I'll have sympathy for the CA this happened to.
Nick.
> Will you fill something in in the commonName? I think what is
> expected in the commonName is what the user would type and expect to
> see, I don't think the commonName should contain
> xn--gau-7ka.siemens.de. If you have a commonName, I would expect that
> it contains gauß.siemens.de. And if you create a commonName then, you
> are required to check that it matches the xn--gau-7ka.siemens.de in
> the SAN.
I have two responses to this, first the practical one:
> expected in the commonName is what the user would type and expect to
> see, I don't think the commonName should contain
> xn--gau-7ka.siemens.de. If you have a commonName, I would expect that
> it contains gauß.siemens.de. And if you create a commonName then, you
> are required to check that it matches the xn--gau-7ka.siemens.de in
> the SAN.
In Firefox (our most direct concern here on m.d.s.policy) of course CN
is entirely ignored for matching certificates in the Web PKI.
However many other clients exist, and we know most of them continue to
parse CN as you might have done twenty years ago trying to find some IP
address or DNS name in the human readable text. In some cases they
either don't understand SANs, or they prioritise matching CN over SANs.
This is a bad idea (if you are reading this and have responsibility for
the name matching algorithm in either a client or library I implore you
to go look at this again) but it's out there today and isn't going
away in the immediate future.
Concrete example: Until relatively recently Python's SSL/TLS
implementation, including in the very popular "Requests" library, would
match a Unicode hostname string against CN or SANs, even though that's
not correct behaviour. When a user asks to connect to 瞺瞹砡.example
the Python code correctly determines that it needs the DNS name
xn--b6yb42a.example to find the IP address but it still expects the
certificate to match 瞺瞹砡.example not xn--b6yb42a.example. This is of
course impossible for SANs by definition, and that impossibility was
helpful in persuading developers that their understanding of what
needed to happen here couldn't be correct.
I (as a relying party) would prefer that failure modes that fall out of
this sort of error aren't fatal to security. CAs that write SANs as
IA5-Strings with A-labels into CN fail safely here, whereas those which
try to conjure U-labels for a Unicode String risk tricking some of this
bad parser code into accepting a certificate for one name as valid for
a similar but different name or blowing up the parser itself (I haven't
seen examples where UCS-2 string data ends up written to a NUL-byte
terminated C string but I would not be surprised if it happens)
For compatibility reasons omitting CN altogether is not usually a good
plan, so to me that leaves writing the A-labels as the best option. I
believe Let's Encrypt currently has experiments ongoing as to how to
opt out of writing CN, but there's no intent to actually stop doing it
by default.
Second, a philosophical response:
The purpose of the Subject DN is to identify the Subject to a Relying
Party and we want it to be clear exactly which Subject we're
identifying. It is difficult, and maybe impossible, for a Certificate
Authority to specify how the user's input will be handled or how
exactly a name will be displayed in every possible user agent software.
On the other hand, the DNS A-labels, though unfamiliar to a human and
unwieldy to think about, have the advantage that they're definitely
identifying the specific thing we validated, not anything with a
different but similar name.
The reason it's hard for the CA to reason about Unicode names is that
not only do you have all of IDNA-2003, IDNA-2008, TR#46 but also
browsers have lots of counter measures (and the exact counter measures
deployed in famous brand browsers have changed over time) for the
problem of confusable DNS names. A browser may choose to write an IDN
in Punycode to avoid confusing users into believing the IDN is actually
some distinct name that merely looks similar.
My preferred outcome here would be for CAs to just voluntarily
choose not to write U-labels into CN AND for user agents to stop trying
to parse CN instead of just handling SANs. I think that's easier and
safer for basically everybody. But I don't feel strongly enough about
it that I feel we want "Incident Reports" for every scenario where this
didn't happen.
I do feel strongly enough about it that if a incident does happen and
the proximate cause was "We write U-labels into CN and that tripped a
bug" there's a good chance I will do the Nelson Muntz laugh and no
chance I'll have sympathy for the CA this happened to.
Nick.
Tim Hollebeek
Jan 25, 2019, 10:06:19 AM1/25/19
to Kurt Roeckx, mozilla-dev-s...@lists.mozilla.org
> On 2019-01-24 20:19, Tim Hollebeek wrote:
> > I think the assertion that the commonName has anything to do with what
> > the user would type and expect to see is unsupported by any of the
> > relevant standards, and as Rob noted, having it be different from the
> > SAN strings is not in compliance with the Baseline Requirements.
>
> > the user would type and expect to see is unsupported by any of the
> > relevant standards, and as Rob noted, having it be different from the
> > SAN strings is not in compliance with the Baseline Requirements.
>
> The BR do not say anything about it.
Rob already quoted it: "If present, this field MUST contain a single IP
address
or Fully-Qualified Domain Name that is one of the values contained in the
Certificate's subjectAltName extension".
or Fully-Qualified Domain Name that is one of the values contained in the
The only reason it's allowed at all is because certain legacy software
implementations would choke if it were missing.
> > Requiring translation to a U-label by the CA adds a lot of additional
> > complexity with no benefit.
>
> I have no idea what is so complex about that. When generating the
> certificate, it's really just calling a function. On the other hand, when
reading
> a certificate you have to guess what they did.
Given that it has no benefit at all, any complexity is too much. As I
> certificate, it's really just calling a function. On the other hand, when
reading
> a certificate you have to guess what they did.
mentioned
above, its existence is merely a workaround for a bug in obsolete software.
> And if it's really to complex, just remove the CN, or is that too complex
too?
> > What users type and see are issues that are best left to Application
> > Software Suppliers (browsers).
>
> So you're saying all the other software that deals with certificates
should
> instead add complexity?
What they actually do is to ignore this obsolete field, and process the
should
> instead add complexity?
subjectAltNames. There's no additional complexity for them because
they already are doing the conversion of IDN names.
-Tim
Corey Bonnell
Jan 25, 2019, 10:14:52 AM1/25/19
to mozilla-dev-s...@lists.mozilla.org
The fact that particular CA implementations outsource the conversion of U-labels to A-labels in IDNs to Applicants does not mean that CAs do no conversion. The conversion is being done, but not by the CA software itself. Many CAs have merely elected that the conversion step be done by Applicants. This does not excuse the CA from checking that such conversion was done correctly.
As such, RFC 5280-compliant CA implementations must check Applicant-supplied input (namely, the IDNs) for correctness with RFC 3490. Failure to do so is a failure to properly validate user-supplied input and risks the potential of outputting IDNA 2003-violating names in certificates.
As such, RFC 5280-compliant CA implementations must check Applicant-supplied input (namely, the IDNs) for correctness with RFC 3490. Failure to do so is a failure to properly validate user-supplied input and risks the potential of outputting IDNA 2003-violating names in certificates.
Mirro
Jan 25, 2019, 10:15:26 AM1/25/19
to mozilla-dev-s...@lists.mozilla.org
在 2019年1月25日星期五 UTC+8上午3:19:42，Tim Hollebeek写道：
It seems like that the commonName should be one of the values of the dNSNames in the SAN to comply with the requirements of BR, though the different values are for the same domain name and the U-label reads more easily.
Can BR add an exception for the Non-English domain names? Will this lead to some risks that I didn't think of?
In my opinion, a subscriber will need more time to manage them and it is easier to make mistakes if he has serveral certificates with both unreadable commonName and SAN.
Can BR add an exception for the Non-English domain names? Will this lead to some risks that I didn't think of?
In my opinion, a subscriber will need more time to manage them and it is easier to make mistakes if he has serveral certificates with both unreadable commonName and SAN.
Jakob Bohm
Jan 25, 2019, 12:47:10 PM1/25/19
to mozilla-dev-s...@lists.mozilla.org
On 25/01/2019 16:06, Tim Hollebeek wrote:
>
>> On 2019-01-24 20:19, Tim Hollebeek wrote:
>>> I think the assertion that the commonName has anything to do with what
>>> the user would type and expect to see is unsupported by any of the
>>> relevant standards, and as Rob noted, having it be different from the
>>> SAN strings is not in compliance with the Baseline Requirements.
>>
>> The BR do not say anything about it.
>
> Rob already quoted it: "If present, this field MUST contain a single IP
> address
> or Fully-Qualified Domain Name that is one of the values contained in the
> Certificate's subjectAltName extension".
>
> The only reason it's allowed at all is because certain legacy software
> implementations would choke if it were missing.
>
>>> Requiring translation to a U-label by the CA adds a lot of additional
>>> complexity with no benefit.
>>
>> I have no idea what is so complex about that. When generating the
>> certificate, it's really just calling a function. On the other hand, when
> reading
>> a certificate you have to guess what they did.
>
> Given that it has no benefit at all, any complexity is too much. As I
> mentioned
> above, its existence is merely a workaround for a bug in obsolete software.
>
Not as much a bug, as a previous specification. In other words,
>
>> On 2019-01-24 20:19, Tim Hollebeek wrote:
>>> I think the assertion that the commonName has anything to do with what
>>> the user would type and expect to see is unsupported by any of the
>>> relevant standards, and as Rob noted, having it be different from the
>>> SAN strings is not in compliance with the Baseline Requirements.
>>
>> The BR do not say anything about it.
>
> Rob already quoted it: "If present, this field MUST contain a single IP
> address
> or Fully-Qualified Domain Name that is one of the values contained in the
> Certificate's subjectAltName extension".
>
> The only reason it's allowed at all is because certain legacy software
> implementations would choke if it were missing.
>
>>> Requiring translation to a U-label by the CA adds a lot of additional
>>> complexity with no benefit.
>>
>> I have no idea what is so complex about that. When generating the
>> certificate, it's really just calling a function. On the other hand, when
> reading
>> a certificate you have to guess what they did.
>
> Given that it has no benefit at all, any complexity is too much. As I
> mentioned
> above, its existence is merely a workaround for a bug in obsolete software.
>
backwards compatibility with old systems and software predating the full
migration to SAN-only checking in modern clients.
As with all backwards compatibility, it is about interoperating with
systems that followed the common standards and practices of their time, as
they were.
While the Python library mentioned apparently failed to match any valid
IDNA SAN value to any actual IDNA host name, the much more common case
is software that will process the A-label as an ASCII string and compare
it to either the CN or the list of SAN values.
One such example is GNU Wget, which is sometimes used to bootstrap the
downloading of updated client software (by typing/pasting a known URL).
GNU Wget was notably slow in implementing SAN support, doing only the
matching of host name to CN. For some compile options, SAN checking of
host names was implemented as recently as the year 2014.
For this and other cases this old, putting the A-label in CN (if the
subscriber chosen "most important to match name" is a DNSname) or
putting the IP address in CN (if the most important to match name is an
IPname).
In either case, I suspect (but have no data) that using the lower case
(ASCII lower case) name form will be the most compatible choice. If the
subscriber does not specify which name is most important, choose the
first DNS/IP name in the subscriber input, unless a later name is a
wildcard that also matched that first name. Ideally, the subscriber
would indicate all desired choices directly in the CSR, but in practice,
most subscribers will use broken scripts to generate the CSR, not a
carefully crafted filled in template.
Example, if the subscriber fills out the human readable order form like
this:
www.example.com
chat.example.com
example.com
detteerenprøve.example.com
www.example.net
example.net
*.eXample.com
*.examPle.nEt
192.0.2.3
the best choice is probably CN=*.example.com which is one of the SANs
and is a wildcard covering the first SAN (www.example.com). The BRs
do not require a specific choice among the 9 SANs that would go in the
certificate (all of which must of cause be validated). The user entered
U-label detteerenprøve.example.com must of cause be converted to A-label
xn--detteerenprve-lnb.example.com before checking and encoding.
This way, out of the correct uses of the certificate, only the
example.net names and the IP address would not be accepted by older software.
The clients of cause usually checks only CN or only SAN, it's the CA that
deals with the complexity of trying to please everyone without harming
anyone.
>> And if it's really to complex, just remove the CN, or is that too complex
> too?
>
> See above.
>
>>> What users type and see are issues that are best left to Application
>>> Software Suppliers (browsers).
>>
>> So you're saying all the other software that deals with certificates
> should
>> instead add complexity?
>
> What they actually do is to ignore this obsolete field, and process the
> subjectAltNames. There's no additional complexity for them because
> they already are doing the conversion of IDN names.
>
> -Tim
>
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
Buschart, Rufus
Jan 25, 2019, 1:24:07 PM1/25/19
to mozilla-dev-s...@lists.mozilla.org
Hello Jakob!
> -----Ursprüngliche Nachricht-----
> Von: dev-security-policy <dev-security-...@lists.mozilla.org> Im Auftrag von Jakob Bohm via dev-security-policy
> Gesendet: Freitag, 25. Januar 2019 18:47
And - ceterum censeo - there is no way a CA can tell for sure if xn--gau-7ka.siemens.de is just a weird server name or the IDNA2008 translation of gauß.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.b...@siemens.com
> -----Ursprüngliche Nachricht-----
> Von: dev-security-policy <dev-security-...@lists.mozilla.org> Im Auftrag von Jakob Bohm via dev-security-policy
> Gesendet: Freitag, 25. Januar 2019 18:47
>
> Example, if the subscriber fills out the human readable order form like
> this:
> www.example.com
> chat.example.com
> example.com
> detteerenprøve.example.com
> www.example.net
> example.net
> *.eXample.com
> *.examPle.nEt
> 192.0.2.3
> the best choice is probably CN=*.example.com which is one of the SANs and is a wildcard covering the first SAN (www.example.com).
> The BRs do not require a specific choice among the 9 SANs that would go in the certificate (all of which must of cause be validated).
> The user entered U-label detteerenprøve.example.com must of cause be converted to A-label xn--detteerenprve-lnb.example.com
> before checking and encoding.
If a CA receives such a list and creates the CSR for the customer (how does the CA this without access to the customers private key?), they have of course to perform an IDNA translation from U-label to A-label. And as we have learned the BRGs (indirectly) enforce the use of IDNA2003. But if the CA receives a filled in CSR they don't perform (not even indirectly) an IDNA translation and has no obligation to check if the entries are valid IDNA2003 A-label.
> Example, if the subscriber fills out the human readable order form like
> this:
> www.example.com
> chat.example.com
> example.com
> detteerenprøve.example.com
> www.example.net
> example.net
> *.eXample.com
> *.examPle.nEt
> 192.0.2.3
> the best choice is probably CN=*.example.com which is one of the SANs and is a wildcard covering the first SAN (www.example.com).
> The BRs do not require a specific choice among the 9 SANs that would go in the certificate (all of which must of cause be validated).
> The user entered U-label detteerenprøve.example.com must of cause be converted to A-label xn--detteerenprve-lnb.example.com
> before checking and encoding.
And - ceterum censeo - there is no way a CA can tell for sure if xn--gau-7ka.siemens.de is just a weird server name or the IDNA2008 translation of gauß.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.b...@siemens.com
Ryan Sleevi
Jan 25, 2019, 1:40:39 PM1/25/19
to Buschart, Rufus, mozilla-dev-s...@lists.mozilla.org
On Fri, Jan 25, 2019 at 1:24 PM Buschart, Rufus via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> If a CA receives such a list and creates the CSR for the customer (how
> does the CA this without access to the customers private key?), they have
> of course to perform an IDNA translation from U-label to A-label. And as we
> have learned the BRGs (indirectly) enforce the use of IDNA2003. But if the
> CA receives a filled in CSR they don't perform (not even indirectly) an
> IDNA translation and has no obligation to check if the entries are valid
> IDNA2003 A-label.
>
> And - ceterum censeo - there is no way a CA can tell for sure if
> xn--gau-7ka.siemens.de is just a weird server name or the IDNA2008
> translation of gauß.siemens.de <http://gauss.siemens.de> .
dev-secur...@lists.mozilla.org> wrote:
> If a CA receives such a list and creates the CSR for the customer (how
> does the CA this without access to the customers private key?), they have
> of course to perform an IDNA translation from U-label to A-label. And as we
> have learned the BRGs (indirectly) enforce the use of IDNA2003. But if the
> CA receives a filled in CSR they don't perform (not even indirectly) an
> IDNA translation and has no obligation to check if the entries are valid
> IDNA2003 A-label.
>
> And - ceterum censeo - there is no way a CA can tell for sure if
> xn--gau-7ka.siemens.de is just a weird server name or the IDNA2008
>
I mean, it's using an ACE label. That's where Ballot 202 would have
clarified and required more explicit validation of the ACE labels to
address the SHOULD NOT from https://tools.ietf.org/html/rfc3490#section-5 to
a MUST NOT.
The CA can perform ToASCII(ToUnicode(label)) == label to validate.
Buschart, Rufus
Jan 25, 2019, 2:01:09 PM1/25/19
to ry...@sleevi.com, mozilla-dev-s...@lists.mozilla.org
> Von: Ryan Sleevi <ry...@sleevi.com>
>
> The CA can perform ToASCII(ToUnicode(label)) == label to validate.
Sorry to be picky, but this check only proofs that a label is a valid IDNA label but not that it is _not_ a weird server name.
> The CA can perform ToASCII(ToUnicode(label)) == label to validate.
Peter Bowen
Jan 25, 2019, 2:15:54 PM1/25/19
to Ryan Sleevi, Buschart, Rufus, mozilla-dev-s...@lists.mozilla.org
On Fri, Jan 25, 2019 at 10:40 AM Ryan Sleevi via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
> I mean, it's using an ACE label. That's where Ballot 202 would have
> clarified and required more explicit validation of the ACE labels to
> address the SHOULD NOT from https://tools.ietf.org/html/rfc3490#section-5
> to
> a MUST NOT.
>
dev-secur...@lists.mozilla.org> wrote:
> I mean, it's using an ACE label. That's where Ballot 202 would have
> clarified and required more explicit validation of the ACE labels to
> address the SHOULD NOT from https://tools.ietf.org/html/rfc3490#section-5
> to
> a MUST NOT.
>
> The CA can perform ToASCII(ToUnicode(label)) == label to validate.
>
Ballot 202 explicitly required that ToUnicode(label) works (i.e. is valid
>
Punycode). ToASCII() has a number of different parameters and different
clients use different parameter values. I don't think the BRs should
require that CAs use a specific combination because that would effectively
mean that certain clients would not be able to use TLS with IDNs.
Thanks,
Peter
Ryan Sleevi
Jan 25, 2019, 2:18:27 PM1/25/19
to Buschart, Rufus, ry...@sleevi.com, mozilla-dev-s...@lists.mozilla.org
On Fri, Jan 25, 2019 at 2:01 PM Buschart, Rufus <rufus.b...@siemens.com>
wrote:
> > Von: Ryan Sleevi <ry...@sleevi.com>
> >
> > The CA can perform ToASCII(ToUnicode(label)) == label to validate.
>
What's not clear to me is why that distinction is relevant, particularly on
the validation side of things. IDNA-aware software will, by virtue of being
IDNA-aware, treat it as an A-label if it's a valid ACE label with the ACE
prefix, and, correspondingly, transform into a U-Label if they see it as
appropriate. From the discussion you were having with Jakob, it's not clear
the relevance of that point about 'weird hostname' vs 'U-label' - perhaps I
missed something?
wrote:
> > Von: Ryan Sleevi <ry...@sleevi.com>
> >
> > The CA can perform ToASCII(ToUnicode(label)) == label to validate.
>
> Sorry to be picky, but this check only proofs that a label is a valid IDNA
> label but not that it is _not_ a weird server name.
>
Picky is good! Obviously I'm very picky ;)
> label but not that it is _not_ a weird server name.
>
What's not clear to me is why that distinction is relevant, particularly on
the validation side of things. IDNA-aware software will, by virtue of being
IDNA-aware, treat it as an A-label if it's a valid ACE label with the ACE
prefix, and, correspondingly, transform into a U-Label if they see it as
appropriate. From the discussion you were having with Jakob, it's not clear
the relevance of that point about 'weird hostname' vs 'U-label' - perhaps I
missed something?
Jakob Bohm
Jan 25, 2019, 2:47:39 PM1/25/19
to mozilla-dev-s...@lists.mozilla.org
On 25/01/2019 19:23, Buschart, Rufus wrote:
> Hello Jakob!
>
>> -----Ursprüngliche Nachricht-----
>> Von: dev-security-policy <dev-security-...@lists.mozilla.org> Im Auftrag von Jakob Bohm via dev-security-policy
>> Gesendet: Freitag, 25. Januar 2019 18:47
>>
>> Example, if the subscriber fills out the human readable order form like
>> this:
>> www.example.com
>> chat.example.com
>> example.com
>> detteerenprøve.example.com
>> www.example.net
>> example.net
>> *.eXample.com
>> *.examPle.nEt
>> 192.0.2.3
>> the best choice is probably CN=*.example.com which is one of the SANs and is a wildcard covering the first SAN (www.example.com).
>> The BRs do not require a specific choice among the 9 SANs that would go in the certificate (all of which must of cause be validated).
>> The user entered U-label detteerenprøve.example.com must of cause be converted to A-label xn--detteerenprve-lnb.example.com
>> before checking and encoding.
>
> If a CA receives such a list and creates the CSR for the customer (how does the CA this without access to the customers private key?), they have of course to perform an IDNA translation from U-label to A-label. And as we have learned the BRGs (indirectly) enforce the use of IDNA2003. But if the CA receives a filled in CSR they don't perform (not even indirectly) an IDNA translation and has no obligation to check if the entries are valid IDNA2003 A-label.
>
I was not suggesting that the CA creates the CSR.
> Hello Jakob!
>
>> -----Ursprüngliche Nachricht-----
>> Von: dev-security-policy <dev-security-...@lists.mozilla.org> Im Auftrag von Jakob Bohm via dev-security-policy
>> Gesendet: Freitag, 25. Januar 2019 18:47
>>
>> Example, if the subscriber fills out the human readable order form like
>> this:
>> www.example.com
>> chat.example.com
>> example.com
>> detteerenprøve.example.com
>> www.example.net
>> example.net
>> *.eXample.com
>> *.examPle.nEt
>> 192.0.2.3
>> the best choice is probably CN=*.example.com which is one of the SANs and is a wildcard covering the first SAN (www.example.com).
>> The BRs do not require a specific choice among the 9 SANs that would go in the certificate (all of which must of cause be validated).
>> The user entered U-label detteerenprøve.example.com must of cause be converted to A-label xn--detteerenprve-lnb.example.com
>> before checking and encoding.
>
> If a CA receives such a list and creates the CSR for the customer (how does the CA this without access to the customers private key?), they have of course to perform an IDNA translation from U-label to A-label. And as we have learned the BRGs (indirectly) enforce the use of IDNA2003. But if the CA receives a filled in CSR they don't perform (not even indirectly) an IDNA translation and has no obligation to check if the entries are valid IDNA2003 A-label.
>
I was simply suggesting the common practice of the CA using the CSR
mostly as a "proof of possession" of the private key, but not as a
precise specification of the desired certificate contents.
For example, a CSR may (due to old tools or human error) contain
additional subject DN elements (such as eMailAddress). Of cause the
CSR can't be completely different from the requested certificate, as
that would be open to a man-in-the-middle attack where an attacker
submits the victim's CSR with a completely unrelated order.
Buschart, Rufus
Jan 30, 2019, 10:11:06 AM1/30/19
to mozilla-dev-s...@lists.mozilla.org
> Von: Ryan Sleevi <ry...@sleevi.com>
>> On Fri, Jan 25, 2019 at 2:01 PM Buschart, Rufus <mailto:rufus.b...@siemens.com> wrote:
>>> Von: Ryan Sleevi <mailto:ry...@sleevi.com>
1) MUST a CA software be IDNA aware?
2) SHOULD a CA software be IDNA aware?
Regarding 1: Ballot 202 wanted to make IDNA awareness a strict requirement for any CA. Ballot 202 failed, therefor it should be clear, that a CA can choose whether to be IDNA aware or not.
Regarding 2: Due to bullet 1 this is a business decision of any CA and I believe there are good reasons simply to be ignorant towards IDNA naming syntax, because you can't tell if this is just a weird host name or an A-label.
==> As a conclusion I believe any bug that was opened due to the issuance of certificates that include hostnames which could be read as an A-label should be rejected, as long as the A-label was validated (and all other rules of the BRGs, etc. are followed).
/Rufus
>> On Fri, Jan 25, 2019 at 2:01 PM Buschart, Rufus <mailto:rufus.b...@siemens.com> wrote:
>>> Von: Ryan Sleevi <mailto:ry...@sleevi.com>
>>>
>>> The CA can perform ToASCII(ToUnicode(label)) == label to validate.
>>
>> Sorry to be picky, but this check only proofs that a label is a valid IDNA label but not that it is _not_ a weird server name.
>
> Picky is good! Obviously I'm very picky ;)
>
> What's not clear to me is why that distinction is relevant, particularly on the validation side of things. IDNA-aware software will,
> by virtue of being IDNA-aware, treat it as an A-label if it's a valid ACE label with the ACE prefix, and, correspondingly, transform
> into a U-Label if they see it as appropriate. From the discussion you were having with Jakob, it's not clear the relevance of that
> point about 'weird hostname' vs 'U-label' - perhaps I missed something?
At the end, it all comes down to the question, whether a CA software has to be IDNA aware or not. This question can be divided in two separate sub-questions:
>>> The CA can perform ToASCII(ToUnicode(label)) == label to validate.
>>
>> Sorry to be picky, but this check only proofs that a label is a valid IDNA label but not that it is _not_ a weird server name.
>
> Picky is good! Obviously I'm very picky ;)
>
> What's not clear to me is why that distinction is relevant, particularly on the validation side of things. IDNA-aware software will,
> by virtue of being IDNA-aware, treat it as an A-label if it's a valid ACE label with the ACE prefix, and, correspondingly, transform
> into a U-Label if they see it as appropriate. From the discussion you were having with Jakob, it's not clear the relevance of that
> point about 'weird hostname' vs 'U-label' - perhaps I missed something?
1) MUST a CA software be IDNA aware?
2) SHOULD a CA software be IDNA aware?
Regarding 1: Ballot 202 wanted to make IDNA awareness a strict requirement for any CA. Ballot 202 failed, therefor it should be clear, that a CA can choose whether to be IDNA aware or not.
Regarding 2: Due to bullet 1 this is a business decision of any CA and I believe there are good reasons simply to be ignorant towards IDNA naming syntax, because you can't tell if this is just a weird host name or an A-label.
==> As a conclusion I believe any bug that was opened due to the issuance of certificates that include hostnames which could be read as an A-label should be rejected, as long as the A-label was validated (and all other rules of the BRGs, etc. are followed).
/Rufus
Wayne Thayer
Feb 4, 2019, 6:53:18 PM2/4/19
to mozilla-dev-s...@lists.mozilla.org
Thanks everyone for your input on this topic.
As a result of this discussion, I have concluded that this is not a clear
violation of Mozilla policy. I've closed the DFN bug as INVALID, and I am
planning to propose a ballot to the CAB Forum to clarify this requirement.
- Wayne
>
As a result of this discussion, I have concluded that this is not a clear
violation of Mozilla policy. I've closed the DFN bug as INVALID, and I am
planning to propose a ballot to the CAB Forum to clarify this requirement.
- Wayne
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
>
0 new messages