I referred to your comment that "you perform a successful domain validation". My point, which you seem to understand and agree, is that there are additional rules than just DNS validation.

Dimitris.


On 24/1/2019 12:21 μ.μ., Buschart, Rufus wrote:
Hello Dimitris,

of course not, because the underscore is not part of the syntax for a hostname 
acc. RFC 1034, chapter 3.5. whereas xn--gau-7ka.siemens.de is a perfectly valid 
hostname.

With best regards,
Rufus Buschart

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

www.siemens.com/ingenuityforlife

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

-----Ursprüngliche Nachricht-----
Von: Dimitris Zacharopoulos <ji...@it.auth.gr>
Gesendet: Donnerstag, 24. Januar 2019 11:16
An: Buschart, Rufus (GS IT HR 7 4) <rufus.busch...@siemens.com>; 
mozilla-dev-security-pol...@lists.mozilla.org
Betreff: Re: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international 
domain names

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

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

Dimitris.

With best regards,
Rufus Buschart

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

www.siemens.com/ingenuityforlife

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

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

Hello!

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

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

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

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

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

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

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

www.siemens.com/ingenuityforlife

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

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

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

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

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



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

Reply via email to