On 10/12/2018 18:09, Ryan Sleevi wrote: > On Mon, Dec 10, 2018 at 6:16 AM Buschart, Rufus via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Hello! >> >> It would be helpful, if the CA/B or Mozilla could publish a document on >> its web pages to which we can redirect our customers, if they have >> technical questions about this underscore issue. Right now, I can only tell >> them, that they are forbidden because the ballot to explicitly allow them >> failed, but not really why. Especially since the first result in Google for >> "underscore domain name" is a StackOverflow article ( >> https://stackoverflow.com/a/2183140/1426535) stating that it is >> technically perfectly okay and also RFC 5280 says "These characters >> [underscore and at-sign] often appear in Internet addresses. Such >> addresses MUST be encoded using an ASN.1 type that supports them." >> > > There's definitely been a lot of back and forth on this topic. It's unclear > if you're looking for a clearer statement about why they're forbidden or > where they're forbidden. >
It is clear that Rufus is looking for a link to the deprecation ballot, rather than the old (failed) non-deprecation ballot. > If the question is where they are forbidden, > https://tools.ietf.org/html/rfc5280#section-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]. Note that while uppercase and lowercase letters are >> allowed in domain names, no significance is attached to the case. In >> addition, while the string " " is a legal domain name, subjectAltName >> extensions with a dNSName of " " MUST NOT be used. Finally, the use >> of the DNS representation for Internet mail addresses >> (subscriber.example.com instead of subscri...@example.com) MUST NOT >> be used; such identities are to be encoded as rfc822Name. Rules for >> encoding internationalized domain names are specified in Section 7.2. > The huge mess comes from the fact that this requirement of not using the underscore character (which is actually used in some RFC-specified DNS names labels, though for special purposes) was buried in a complicated reference to two old RFCs, each of which in turn describe that particular restriction in a complicated and indirect way. Furthermore, Section 4.2.1.6 of RFC5280 applies only to SubjectAltNames, not to DNS names placed directly in the Subject Distinguished Name in the certificate. Thus this particular restriction on DNS names to which certificates can be issued only became effective as a side effect of deprecating TLS certificates without SubjectAltNames. This made it completely unclear to most people that DNS labels with underscores were not permitted in certificates. Thus the restriction was not widely known outside the CA/root program discussion groups until the rapid sunset was announced in November. > > If the question is "why", then the answer is "Because the preferred name > syntax forbids them" > If the question is "Why does the preferred name syntax forbid them", that > is answered in RFC 1035, Section 2.3.1 > > https://tools.ietf.org/html/rfc1035#section-2.3.1 > >> The DNS specifications attempt to be as general as possible in the rules >> for constructing domain names. The idea is that the name of any >> existing object can be expressed as a domain name with minimal changes. > > > > However, when assigning a domain name for an object, the prudent user >> will select a name which satisfies both the rules of the domain system >> and any existing rules for the object, whether these rules are published >> or implied by existing programs. > > > > For example, when naming a mail domain, the user should satisfy both the >> rules of this memo and those in RFC-822. When creating a new host name, >> the old rules for HOSTS.TXT should be followed. This avoids problems >> when old software is converted to use domain names. > > > > [ABNF omitted here] > > Note that this ABNF is one of only two places expressing the restriction that is now being vigorously enforced 30 years later. And that ABNF isn't even applicable due to RFC1123. > > Note that while upper and lower case letters are allowed in domain >> names, no significance is attached to the case. That is, two names with >> the same spelling but different case are to be treated as if identical. > > > > The labels must follow the rules for ARPANET host names. They must >> start with a letter, end with a letter or digit, and have as interior >> characters only letters, digits, and hyphen. There are also some >> restrictions on the length. Labels must be 63 characters or less. > And this paragraph is the second place, which is also not entirely applicable due to RFC1123. The prohibition of "_" is expressed solely by not mentioning it as permitted. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
