On 18/12/2018 18:15, Ryan Sleevi wrote: > On Tue, Dec 18, 2018 at 8:19 AM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> 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. >> > > Thanks for sharing your interpretation. I don't think that is an accurate > summary, but it's useful to understand your perspective and how you > interpret things. >
Well he wanted that or another _single document_ that affected parties can read, rather than trying to dig through the RFCs and mailing lists themselves. > >>> 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. >> > > I find your summary interesting. I presume, then, that you feel that the > need to use DNS is buried in complicated references to old RFCs, much as it > would be how HTTP works or, for that matter, how ASN.1 works. It's > certainly true that, as we build complex systems, we stand on the shoulder > of giants, and as we build code and systems, we layer them. I think it's > rather misguided and ignorant to suggest that, because a document is > referenced by another document, it somehow becomes complicated, or that the > age matters. Were that the case, we'd presume the Baseline Requirements > would include everything from the IP specification to the ASN.1 > specification, and everything in between, and then lament at how anyone is > supposed to understand or maintain the salient bits of this 10,000 page > document. > The simple fact that the leading experts on the subject disagreed on the issue shows that the outcome wasn't obvious (the opposite outcome would not have been obvious either). It's the classic question if corner case behavior of a piece of code is a feature or a bug, except it was English-language documents, not C-language code. The wording and structure of RFC5280 (and its predecessor RFC2459) is such that it appears to state an encoding of DNS names, not a restriction to ARPANET host names. For a subscriber or relying party developing and deploying a system like the one described by pilgrim2223, everything after the 2nd paragraph of 4.2.1.6 would look like ASN.1/DER encoding details to be handled by the 3rd party TLS library, and such a subscriber would probably believe it when both a Google search and their CA tells them it is A-OK. Removing the "underscore mandatory" and "specific name X_Y mandatory" rules from deployed systems without introducing security holes takes more than the 1 month they have given that the annual Thanksgiving-to-NewYears lockdown has been mentioned in other global issues. (In fact this is the first subscriber/RP interfering BR effective date hitting the Xmas season since the SHA-1 deprecation). 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
