It clearly wasn't understood by everyone. That's why we had two ballots on it, one of them failing to address the issue. You can just look through the long discussions on the topic to see people didn't agree.
-----Original Message----- From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On Behalf Of Jakob Bohm via dev-security-policy Sent: Thursday, December 27, 2018 2:43 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Use cases of publicly-trusted certificates On 27/12/2018 18:03, Nick Lamb wrote: > On Thu, 27 Dec 2018 15:30:01 +0100 > Jakob Bohm via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > >> The problem here is that the prohibition lies in a complex legal >> reading of multiple documents, similar to a situation where a court >> rules that a set of laws has an (unexpected to many) legal >> consequence. > > I completely disagree. This prohibition was an obvious fact, well > known to (I had assumed prior to this present fever) everyone who > cared about the Internet's underlying infrastructure. > The group who most definitely were unaware of the very specific reading of RFC5280 is the subscribers using such host names in ways that passed all other requirements (including domain name validation). Not the people seeking to allow these names via ballot 202, similar to what was done for other RFC5280 deviations in ballots 75, 88 and 144. > The only species of technical people I ever ran into previously who > professed "ignorance" of the rule were the sort who see documents like > RFCs as descriptive rather than prescriptive and so their position > would be (as it seems yours is) "Whatever I can do is allowed". Hardly > a useful rule for the Web PKI. > You must be traveling in a rather limited bubble of PKIX experts, all of whom live and breathe the reading of RFC5280. Technical people outside that bubble may have easily misread the relevant paragraph in RFC5280 in various ways. Possible ways to overlook the ban on underscores: 1. Not chasing down the RFC1034/RFC1123 references but relying on previously learned rules for what can be in a DNS name. 2. Interpreting the wording in RFC5280 section 4.2.1.6 as simply requiring a canonical encoding of DNS names, thus not allowing e.g. the UTF-8 equivalent of an IDN or duplicate periods, then deferring that encoding job to a 3rd party PKI library. 3. Relying on practice established in certificates without the SAN extension, (thus not subject to section 4.2.1.6 rules) and then continuing without detailed review after it became mandatory to always include the SAN extension for end entities. 4. Trusting the word of others on how to interpret the rules, those others being the ones misreading the standards. > Descriptive documents certainly have their place - I greatly admire > Geoff Pullum's Cambridge Grammar of the English Language, and I do own > the more compact "Student's Introduction" book, both of which are > descriptive since of course a natural language is not defined by such > documents and can only be described by them (and imperfectly, exactly > what's going on in English remains an active area of research). > But that place is not here, the exact workings of DNS are prescribed, > in documents you've called a "complex legal reading of multiple documents" > but more familiarly as "a bunch of pretty readable RFCs on exactly > this topic". > The documents that prescribes the exact workings of DNS do not prohibit (only discourage) DNS names containing underscores. Web browser interfaces for URL parsing may not allow them, which would be a technical benefit for at least one usage of such certificates reported in the recent discussion. The complex reading comes in the understanding that a single sentence in RFC5280 elevates the recommendation in the DNS standards to an absolute requirement in PKIX, combined with the opinion that this particular effect of the wording is not another errata that should be corrected in any later update of the PKIX standard, and/or overridden by a BR clause. >> It would benefit the honesty of this discussion if the side that won >> in the CAB/F stops pretending that everybody else "should have known" >> that their victory was the only legally possible outcome and should >> never have acted otherwise. > > I would suggest it would more benefit the honesty of the discussion if > those who somehow convinced themselves of falsehood would accept this > was a serious flaw and resolve to do better in future, rather than > suppose that it was unavoidable and so we have to expect they'll keep > doing it. > > Consider it from my position. In one case I know Jakob made an error > but has learned a valuable lesson from it and won't be caught the same > way twice. In the other case Jakob is unreliable on simple matters of > fact and I shouldn't believe anything further he says. > That I disagree with you on certain questions of fact doesn't mean I'm unreliable, merely that you have not presented any persuasive arguments that you are not the one being wrong. I have accepted that a strict, legalistic reading of RFC5280 leads to the ban on underscores in subject alternative names. I merely dispute that this was obvious to every reader of those documents, even if they understood them to be binding technical standards. Hence why I consider the passing of ballot SC12 as similar to a supreme court ruling that a combination of laws constitutes an actually enforceable ban on some established practice (which someone obviously argued for). > >> Maybe because it is not publicly prohibited in general (the DNS >> standard only recommends against it, and other public standards >> require some such names for uses such as publishing certain public >> keys). The prohibition exists only in the certificate standard >> (PKIX) and maybe in the registration policies of TLDs (for TLD+1 >> names only). > > Nope. You are, as it seems others in your position have done before, > confusing restrictions on all names in DNS with restrictions on names > for _hosts_ in DNS. Lots of things can have underscores in their > names, and will continue to have underscores in their names, but hosts cannot. > Web PKI certs are issued for host names (and IP addresses, and as a > special case, TOR hidden services). > Can you point out where in the DNS standards the ban of underscores is a RFC2119 MUST rather than a SHOULD ? (The lowercase "must" near the end of RFC1034 section 3.5 is a specification of how to implement the should in the second paragraph of that section, and the "prudent user" practice described in the first paragraph of that section. Almost identical wording is found in RFC1035). > Imagine if, on the same basis, a CA were to insist that they'd > understood Texas to be a US state, and so they'd written C=TX on the > rationale that a "state" is essentially the same kind of thing as a > "country". > > I do not doubt they could find a few (mostly Texan) people to defend > this view, but it's obviously wrong, and when the City of Austin > Independent League of Skateboarders protests that they need to keep > getting certificates with C=TX for compatibility reasons we'd have a > good laugh and tell the CA to stop being so stupid, revoke these certs > and move on. > A better example is the pre-2015 issuing of .onion names, which do not exist in the IANA-rooted DNS. >> Also it isn't the "Web PKI". It is the "Public TLS PKI", which is >> not confined to Web Browsers surfing online shops and social >> networks, and hasn't been since at least the day TLS was made an IETF >> standard. > > It is _named_ the Web PKI. As you point out, it is lots of things, and > so "Web PKI" is not a good description but its name remains the Web > PKI anyway. > > The name for people from my country is "Britons". Again it's not a > good description, since some of them aren't from the island of Great > Britain as the country extends to adjacent islands too. Nevertheless > the name is "Britons". > I wrote this in opposition to someone seemingly insisting that the _name_ implied that all non-web uses are mistakes that should not be given any credence. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://clicktime.symantec.com/a/1/NvI8nVBXrGua0H_mUC6FhSYOxxn3GAjg_XLXNmbVXB0=?d=Tug3wiBvLVI0CccxMfKgxh2qZnxuKqdrvmlxx7SfUafIyVLpggZyNa2YvnkFmStxYAmKMw2hduxHGjtx1kmvLrUAqfl4P8H-PdRJyBEHq88o27yIftfQdga8WEvb0AzXVoR1TwL812ipWXhtlTDqYu9FGxJmXLGwh4n4_EUO3IX3DYxA9tFShluVJFmd3_JEBurArdJ6A6WRgZ9t33tJYH-hOGrPPBSs3sBuo49yuodFXuHVdU1xK2ylu2iRmK3CbCAoKeISzkVn2dII57K1LTEUJVUPhkaYNb_hkGl6yLzPobl_W990qI5dnuW9DA8ZBMK9u2HIG8T9VGabWIfcZDCZpWyByMcbCTUXtZ67YUEvmiiQYGbsAj18VwcD1mDr2EYARZepqcILKoryOAaj6_zPn6s1uQBQGWWkv1hB&u=https%3A%2F%2Fwww.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://clicktime.symantec.com/a/1/xge3klSg_iQMiHmsh9hZ8yCqd8oxS2EFRR1Sz99TuTw=?d=Tug3wiBvLVI0CccxMfKgxh2qZnxuKqdrvmlxx7SfUafIyVLpggZyNa2YvnkFmStxYAmKMw2hduxHGjtx1kmvLrUAqfl4P8H-PdRJyBEHq88o27yIftfQdga8WEvb0AzXVoR1TwL812ipWXhtlTDqYu9FGxJmXLGwh4n4_EUO3IX3DYxA9tFShluVJFmd3_JEBurArdJ6A6WRgZ9t33tJYH-hOGrPPBSs3sBuo49yuodFXuHVdU1xK2ylu2iRmK3CbCAoKeISzkVn2dII57K1LTEUJVUPhkaYNb_hkGl6yLzPobl_W990qI5dnuW9DA8ZBMK9u2HIG8T9VGabWIfcZDCZpWyByMcbCTUXtZ67YUEvmiiQYGbsAj18VwcD1mDr2EYARZepqcILKoryOAaj6_zPn6s1uQBQGWWkv1hB&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
