> Le 20 juil. 2017 à 16:52, Ryan Sleevi <[email protected]> a écrit : > > On Thu, Jul 20, 2017 at 10:16 AM, Erwann Abalea > <[email protected]> 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? 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" 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. > 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). _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
