[cabfpub] Ballot 202 - Underscore and Wildcard Characters

[Peter Bowen]

> On Jul 20, 2017, at 11:02 AM, Erwann Abalea <Erwann.Abalea at docusign.com> wrote:
> 
> 
>> Le 20 juil. 2017 à 16:52, Ryan Sleevi <sleevi at google.com> a écrit :
>> 
>> 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).
> 
> I was just reading it.
> 
> So valid names will be composed only of:
> - LDH labels that are correct A-labels (the (2) box)
> - NR-LDH labels (the box on top right)
> - a subset of NON-LDH labels: only the underscore will be authorized and only where an hyphen can be present; will « xn__something » be authorized?

I read it as xn__something is allowed as it does not contain hyphens at all, so it is clearly not a Reserved LDH Label.

> Using censys.io and the following expression returns some currently valid certificates that contain a fake A-label while being valid names:
> parsed.extensions.subject_alt_name.dns_names:/(.*\.)?[^xX][^nN]--.*/ and tags: “trusted"

Using the 5890 terminology, I believe this search finds Reserved LDH Labels that are not XN-labels.  A “fake A-label” is one starting with xn-- but not containing a punycode string.	Detecting fake A-label via regex is super hard, as it looks correct.  The numbers found by this censys query are very close to what I found in  CT logs.  You can see the CA totals on the right; Censys is showing 20 while I found 13 in CT.  Either number is a super small portion of the millions of trusted certificates.

> With the following expression, there’s a list of registered domains that contain a double hyphen at 3rd and 4th position while not starting with xn:
> parsed.extensions.subject_alt_name.dns_names:/(.*\.)?[^xX][^nN]--[a-zA-Z0-9-]*\.[a-zA-Z]+/
> 
> Such certificates would then be considered as misissued.

This is basically the same query as before but without “trusted”, right?

>> 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].")
>> 
> 
> The names returned by the upper-mentioned requests only contain valid LDH labels.
> 
> On the other hand, the proposed ballot would clearly rule out a lot of currently valid certificates that shouldn’t exist (containing a label starting with an underscore).
>