AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

2019-01-23 Thread Buschart, Rufus via dev-security-policy
Hello!

> Von: Servercert-wg  Im Auftrag von 
> Wayne Thayer via Servercert-wg
>
>> On Mon, Jan 21, 2019 at 5:50 PM Jeremy Rowley via Servercert-wg 
>>  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  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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list

Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

2019-01-23 Thread Jürgen Brauckmann via dev-security-policy
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