[cabfpub] Ballot 202 - Underscore and Wildcard Characters
Erwann.Abalea at docusign.com
Fri Jul 21 07:19:11 MST 2017
Le 20 juil. 2017 à 23:13, Peter Bowen <pzb at amzn.com<mailto:pzb at amzn.com>> a écrit :
On Jul 20, 2017, at 11:02 AM, Erwann Abalea <Erwann.Abalea at docusign.com<mailto:Erwann.Abalea at docusign.com>> wrote:
Le 20 juil. 2017 à 16:52, Ryan Sleevi <sleevi at google.com<mailto:sleevi at google.com>> a écrit :
On Thu, Jul 20, 2017 at 10:16 AM, Erwann Abalea
<Erwann.Abalea at docusign.com<mailto:Erwann.Abalea at docusign.com>> wrote:
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<http://tls.xxxxxxx.com> »
- provide certificates for names that are not internet routable, such as «
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 22.214.171.124.11 is used).
Text in 126.96.36.199.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<http://valid.gov> », or « in--valid.co.uk<http://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<http://domain.com>).
Is that the intention of the ballot to disallow CAs to provide certificates
for such domains?
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.
You’re right, they’re not fake A-labels, but R-LDH labels.
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:
Such certificates would then be considered as misissued.
This is basically the same query as before but without “trusted”, right?
It returns only names where the R-LDH labels is right below the TLD. Previous query returned all names containing an R-LDH label.
So this query returns domain names that have been registered.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public