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

[Wayne Thayer via dev-security-policy]

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

On Wed, Jan 30, 2019 at 8:11 AM Buschart, Rufus via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > Von: Ryan Sleevi 
> >> On Fri, Jan 25, 2019 at 2:01 PM Buschart, Rufus  rufus.busch...@siemens.com> wrote:
> >>> Von: Ryan Sleevi 
> >>>
> >>> 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:
>
> 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
> ___
> 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]

> Von: Ryan Sleevi  
>> On Fri, Jan 25, 2019 at 2:01 PM Buschart, Rufus 
>>  wrote:
>>> Von: Ryan Sleevi  
>>> 
>>> 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:

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

[Jakob Bohm via dev-security-policy]

On 25/01/2019 19:23, Buschart, Rufus wrote:

Hello Jakob!


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

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.



Enjoy

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

[Ryan Sleevi via dev-security-policy]

On Fri, Jan 25, 2019 at 2:01 PM Buschart, Rufus 
wrote:

> > Von: Ryan Sleevi 
> >
> > 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?
___
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 Fri, Jan 25, 2019 at 10:40 AM Ryan Sleevi via dev-security-policy <
dev-security-policy@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
___
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]

> Von: Ryan Sleevi  
> 
> 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.

With best regards,
Rufus Buschart

___
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

[Ryan Sleevi via dev-security-policy]

On Fri, Jan 25, 2019 at 1:24 PM Buschart, Rufus via dev-security-policy <
dev-security-policy@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  .
>

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.
___
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 Jakob!

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

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



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

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

[Jakob Bohm via dev-security-policy]

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


Enjoy

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

[Mirro via dev-security-policy]

在 2019年1月25日星期五 UTC+8上午3:19:42，Tim Hollebeek写道：
> 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

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.
___
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]

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

> 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



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

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

[Kurt Roeckx via dev-security-policy]

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.


It's also deprecated.  If anything, it should cease to exist.


I agree with that.


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.


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?



Kurt
___
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: 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

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

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

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

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

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

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

[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