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. 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. 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 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. That is, the choice for how host names are expressed (A/AAAA, for example) are derived from the syntax restrictions from HOSTS.TXT, which traces through to the rules of ARPANET host names. The answer for "Why" is thus "To ensure backwards compatibility with existing applications, and ensure an unambiguous representation". What I mean by "unambiguous" is, for example, the discussion about case sensitivity. A DNS label is 8-byte clean, but a hostname uses the LDH rule. If Client A interpreted "eXaMpLe.CoM" differently than Client B did - for example, Client A used the existing HOSTS.TXT/ARPANET syntax and got one host, while Client B used a case-sensitive algorithm - you could end up with client confusion and incompatibility. This isn't theoretical either - the IDNA 2003/2008/transitional issues have shown real confusion that can arise with competing encodings. You can find more about the terminology in https://tools.ietf.org/html/rfc7719 if you want, but hopefully that clarifies the "Why" - it has **always** been forbidden, just like it has * *always** been forbidden to encode email addresses in DNS, and instead require they use the RFC 822 syntax. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
