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 <ha...@hboeck.de>
> > Gesendet: Donnerstag, 24. Januar 2019 12:36
> >
> > On Thu, 24 Jan 2019 11:14:11 +0000 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
> >
> >  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 <https://tools.ietf.org/html/rfc5280#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

dev-security-policy mailing list

Reply via email to