On 24/1/2019 10:47 π.μ., Buschart, Rufus via dev-security-policy wrote:
Good morning!

I would like to sharpen my argument from below a little bit: If a CA gets a 
request to issue a certificate for the domain xn--gau-7ka.siemens.de, how can 
the CA tell, that xn--gau-7ka is a punycode string in IDNA2008 and not only a 
very strange server name? At least I don't have a glass bowl to read the mind 
of my customers. Therefor I would say, it is perfectly okay to issue a 
certificate for xn--gau-7ka.siemens.de as long as you perform a successful 
domain validation for xn--gau-7ka.siemens.de.
By following this argument, you would also approve issuance of domain names that contain the underscore "_" character, right?

Dimitris.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

-----Ursprüngliche Nachricht-----
Von: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> Im 
Auftrag von Buschart, Rufus via dev-security-policy
Gesendet: Mittwoch, 23. Januar 2019 20:24
An: mozilla-dev-security-pol...@lists.mozilla.org
Betreff: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain 
names

Hello!

Von: Servercert-wg <mailto:servercert-wg-boun...@cabforum.org> Im
Auftrag von Wayne Thayer via Servercert-wg

On Mon, Jan 21, 2019 at 5:50 PM Jeremy Rowley via Servercert-wg 
<mailto:servercert...@cabforum.org> wrote:
We received a report for someone saying that certificates issued with puny-code 
are mis-issued if they use IDNA2008.
Considering a number of people probably received the same report, I figured we 
should raise and discuss the implications here.
ISSUES:
1. Does a CA have to check the puny-code provided by a customer for
compliance? Generally, we send the validation request to the puny-code domain 
(not the pre-conversation name). This confirms
control over the domain so is there a need to check this?
If we aren’t doing the conversion, are we actually an implementer in this case?
The BRs require 5280 compliance, so yes I think CAs need to ensure that 
certificates they sign conform to IDNA2003.
Where exactly in RFC5280 do you find the requirement that domains that follow 
IDNA2008 but not IDNA2003 are not permitted in a
certificate? If I understand chapter 7.3 of RFC2008 correctly, it describes how 
to process a domain that follows IDNA2003 (rfc3490) but
it does not forbid that a domain can be encoded in IDNA2008 (rfc5890 / 
rfc5891). It simply says nothing special about how to handle it.
Therefor I would interpret RFC5280 that in this case the domain name in 
punycode can (or better say MUST) be treated like any other
domain name.

Excerpt from the bug mentioned by Jürgen:
Question: Are ACE-labels not encoded as IDNA 2003 in certificates a misissuance 
under the Baseline Requirements? Yes, we think
this is currently the case:
Baseline Requirements mandate conformance to exactly RFC 5280 and
don't reference/allow any updates, e.g., RFC 8399

Chapter 7.2 of RFC 5280 https://tools.ietf.org/html/rfc5280#page-97 states:
"Specifically, conforming implementations MUST perform the conversion operation 
specified in Section 4 of RFC 3490, with the
following clarifications: ...."
So, IDNs must be converted according to the rules of RFC 3490

We, as a CA, don't perform the conversion mentioned in RFC 5280. We 
receive/process ACE-labels only. This means that our system
is likely not meant by the wording "conforming implementations" of RFC 5280.
However, our systems have the technical means and generally the responsibility 
to check for correct input. So, we shall
check/enforce IDNA 2003 ACE-labels.

I don't share your opinion, that you MUST check if a domain is a valid IDNA2003 
domain, just because you could technically do so. I
think this leads on a very slippery road. With the same argument one could 
require a CA to scan every web server before the issuance
of a certificate (or even regularly while the certificate is valid) if the web 
server is distributing malware (BRGs chapter 9.6.3 sub bullet
8). And this is obviously not the duty of a CA. So I understand the spirit of 
RFC 5280 and the BRGs that a CA has to perform domain
validation on the ACE-label but not to enforce any additional syntax on top of 
validated dNSNames.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman,
President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus 
Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P.
Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: 
Berlin Charlottenburg, HRB 12300, Munich, HRB 6684;
WEEE-Reg.-No. DE 23691322

-----Ursprüngliche Nachricht-----
Von: dev-security-policy
<dev-security-policy-boun...@lists.mozilla.org> Im Auftrag von Jürgen
Brauckmann via dev-security-policy
Gesendet: Mittwoch, 23. Januar 2019 13:42
An: mozilla-dev-security-pol...@lists.mozilla.org
Betreff: Incident Report DFN-PKI: Non-IDNA2003 encoded international
domain names

We received a report about non-idna2003 encoded international domain names. 4 
certificates were affected and are revoked by
now.
Details can be found here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1522080

Please also take note of the ongoing discussion regarding this topic in the 
CA/B Forum's Server Certificate Working Group mailing list:
https://cabforum.org/pipermail/servercert-wg/2019-January/000520.html ff.

Thanks,
     Jürgen
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to