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

[Wayne Thayer via dev-security-policy]

On Thu, Jan 24, 2019 at 8:17 AM Peter Bowen via dev-security-policy <
dev-security-policy@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  >."
> 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')
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?
>
> It appears that you proposed [1] an acceptable solution to the concerns
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
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Tim Hollebeek via dev-security-policy]

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 
> On Behalf Of Kurt Roeckx via dev-security-policy
> Sent: Thursday, January 24, 2019 4:04 AM
> To: mozilla-dev-security-pol...@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.
> 
> 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
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/36Cdb8NdVuWoSCnRVsmajRE7Vc?u=https
> %3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Buschart, Rufus via dev-security-policy]

Hi Kurt!

> -Ursprüngliche Nachricht-
> Von: dev-security-policy  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?

> 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Peter Bowen via dev-security-policy]

On Thu, Jan 24, 2019 at 7:36 AM Kurt Roeckx via dev-security-policy <
dev-security-policy@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=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
U-label. That direction is identical for both.   So you can try each of the
SANs and see if it decides to the CN.

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

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

[Kurt Roeckx via dev-security-policy]

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



Kurt

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

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

[Peter Bowen via dev-security-policy]

On Thu, Jan 24, 2019 at 4:17 AM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hello
>
> > -Ursprüngliche Nachricht-
> > Von: Hanno Böck 
> > Gesendet: Donnerstag, 24. Januar 2019 12:36
> >
> > On Thu, 24 Jan 2019 11:14:11 + Buschart, Rufus 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:
>
>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.
>

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 ."
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Rob Stradling via dev-security-policy]

On 24/01/2019 14:09, Kurt Roeckx via dev-security-policy 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).
> 
> 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.


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=cablint,x509lint,zlint

x509lint agrees with your opinion (unsurprisingly!), but both cablint 
and zlint complain.

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

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

[Kurt Roeckx via dev-security-policy]

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 
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Buschart, Rufus via dev-security-policy]

Hello

> -Ursprüngliche Nachricht-
> Von: Hanno Böck 
> Gesendet: Donnerstag, 24. Januar 2019 12:36
> 
> On Thu, 24 Jan 2019 11:14:11 +
> "Buschart, Rufus via dev-security-policy"
>  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:

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

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

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

[Hanno Böck via dev-security-policy]

On Thu, 24 Jan 2019 11:14:11 +
"Buschart, Rufus via dev-security-policy"
 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.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Buschart, Rufus via dev-security-policy]

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.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 
> Gesendet: Donnerstag, 24. Januar 2019 11:52
> An: Buschart, Rufus (GS IT HR 7 4) ; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Betreff: Re: AW: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded 
> international domain names
> 
> 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 
> >> Gesendet: Donnerstag, 24. Januar 2019 11:16
> >> An: Buschart, Rufus (GS IT HR 7 4) ;
> >> 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
>   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  Im
> > Auftrag von Wayne Thayer via Servercert-wg
> >
> >> On Mon, Jan 21, 2019 at 5:50 PM Jeremy 

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

[Rob Stradling via dev-security-policy]

On 24/01/2019 09:04, Kurt Roeckx via dev-security-policy 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.
> 
> 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.

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 
> the xn--gau-7ka.siemens.de in the SAN.
> 
> 
> Kurt

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

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

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

[Dimitris Zacharopoulos via dev-security-policy]

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 
Gesendet: Donnerstag, 24. Januar 2019 11:16
An: Buschart, Rufus (GS IT HR 7 4) ; 
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
 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  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 

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

[Buschart, Rufus via dev-security-policy]

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.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 Kurt Roeckx via dev-security-policy
> Gesendet: Donnerstag, 24. Januar 2019 10:04
> An: mozilla-dev-security-pol...@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:
> > 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 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
> ___
> 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

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

[Buschart, Rufus via dev-security-policy]

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 
> Gesendet: Donnerstag, 24. Januar 2019 11:16
> An: Buschart, Rufus (GS IT HR 7 4) ; 
> 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
> >>  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  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

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

[Dimitris Zacharopoulos via dev-security-policy]

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

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

[Kurt Roeckx via dev-security-policy]

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 
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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Buschart, Rufus via dev-security-policy]

Good morning!

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

With best regards,
Rufus Buschart

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

www.siemens.com/ingenuityforlife

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

> -Ursprüngliche Nachricht-
> Von: dev-security-policy  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  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