[cabfpub] Ballot 202 - Underscore and Wildcard Characters

[Ryan Sleevi]

On Thu, Jul 20, 2017 at 10:16 AM, Erwann Abalea
<Erwann.Abalea at docusign.com> wrote:
> Bonjour,
>
> Looking back in time on the list for a reason to allow for underscore in
> SAN:dNSName, I found basically 2 potential reasons:
>  - allow things such as « _sip._tls.xxxxxxx.com »
>  - provide certificates for names that are not internet routable, such as «
> m_staging9.xxxxxxx.com »
>
> The first option is avoided here (and it’s fine), because this should go
> into an SRV-type entry (or in the SAN:URI for this example).
> The text of the proposed ballot opens the path to having underscores into
> the the « xxxxxx » portion. This path is closed later by the validation of
> domain authorization or control (except if method 3.2.2.4.11 is used).
>
>
> Text in 7.1.4.2.1 disallows FQDNs that contain a label within the class of
> R-LDH labels than don’t start with « xn-- ». IIUC, such domains are still
> allowed under some TLDs that don’t support IDNA (such as « in--valid.am », «
> in--valid.gov », or « in--valid.co.uk »). I just validated that Safari,
> Firefox, and Chrome (on MacOSX) are happy to connect to
> http://in--valid.mydomain.com (for a properly owned my domain.com).
> Is that the intention of the ballot to disallow CAs to provide certificates
> for such domains?

Yes.

See the terminology discussion in
https://tools.ietf.org/html/rfc5890#section-2.3.1 (as well as
Figure-1) . In effect, this prohibits CAs from issuing for Reserved
LDH Labels - except for those explicitly noted (IDNA).

The existing RFCs already prohibit issuance to non-LDH labels, by
virtue of RFC 5280 (4.2.1.6 - "When the subjectAltName extension
contains a domain name system label, the domain name MUST be stored in
the dNSName (an IA5String). The name MUST be in the "preferred name
syntax", as specified by Section 3.5 of [RFC1034] and as modified by
Section 2.1 of [RFC1123].")