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. > > 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. 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. > If you're speaking to this side-effect being placed in 20 years ago, yes, sure, then it's a side-effect, and the industry has had nearly twenty years to contemplate the implications. The use of commonName within the context of TLS was very much a 'hack', emerging both from the lack of X.509v3 (and it's generic extension mechanism) and a repurposing of an existing OID in the absence of the X.500 Global DIT (with would have otherwise set the formatting restrictions). But it is inaccurate and revisionist to suggest that this was a restriction on DNS names expressed through certificates - as the underlying restriction itself comes from the host name form. That is, 5280 is restating existing policy, not introducing new policy, in the hope that people would understand, rather than entrench deeper into their misunderstanding. 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. > This is equally and demonstrably wrong. This discussion goes back years, as do the relevant standards discussions. I understand why there may be a vested personal interest in this narrative, but it's not an accurate one. The discussions over Ballot 202 - which themselves go back some time - and the ultimate resolution provided clear statement about the present expectations. > > [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. > This is an interesting argument to make, and while it sounds compelling, is rather demonstrably weak. It's a poor suggestion that the legitimacy of a requirement is based on the number of times or places it is specified, and similarly to suggest that somehow it's not relevant for the discussion, when the requirement calls out explicitly both 1034 and 1123 to draw attention to the fact that 1123 modified 1034. The weakest part of this argument is that it can be perfectly applied to arguing that neither BER nor DER make sense. That's because restrictions/requirements on encoding BER are only expressed in one place (X.690), and because the requirements of DER supersede (but integrate) those of BER, we can say the requirements on BER aren't even applicable due to DER. > > 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. > Here, we've moved from "isn't even applicable" to "not entirely applicable", a subtle shift in the broad statements. While it's true that 1123 modifies 1034, 5280 is at pains to explicitly call that out, so it hardly supports the argument that this is somehow new and novel. And it's interesting that the choice is that because it's a positive statement (permitted characters), not negative statement (prohibited), it's somehow more difficult. I'm curious, would the same lament apply to string types (which are defined in terms of their permitted characters), protocols like IP (defined in terms of their permitted semantics), or things like ASN.1 (defined in terms of permitted values)? The reality is that the arguments in favor of permitting it have always been weak, and it's always been clear that it was not permitted. The argument constantly being advanced seems to circle around a few things: 1) I shouldn't have to read multiple specifications to implement complex systems - A poor argument, given that CAs have seemingly managed 'OCSP' or 'RSA keys' (both separate specifications) on the implementation side, and seem to have no problem producing overlapping CP/CPS (and RP agreement and Subscriber agreements and a host of other documents) that somehow are meant to define their systems 2) I don't understand why I should have to follow the specification - An inquisitive and questioning mind is a good thing, but obstinate intransigence is hardly that 3) It only told me what I was allowed to do, not what I wasn't allowed to do - An approach that relies on understanding everything explicitly prohibited is not a good approach for running critical Internet security systems. A blacklist does not address security in the way that a whitelist does. Unless it explicitly says something is permitted, the assumption should be it's prohibited. If you even have to question - "It might mean this" - it's something to be discussed publicly and clarified 4) OK, I acknowledge it was wrong, but now people are counting on me to keep doing it - The requirements on the Subscriber Agreement, and in the BRs, exist for a reason. Since the beginning, the certificate ecosystem is one that has expected agility - if something is misleading to RPs, it MUST be revoked. It's the fundamental tradeoff of the PKI, which, similar to Kerberos, allows severing of the RP<->CA online conversation for attestations, but requires that the Subscriber<->CA channel be reliable (or, in Kerberos, that the User<->KDC channel is reliable, allowing the severing of the Server<->KDC channel) There's zero point in trying to litigate this. It does not change the fact that it was not permitted and has never been, and more importantly, reveals an approach to security that's fundamentally incompatible with the Internet scale. That's not to say no ambiguity exists whatsoever in these documents - we should strive to clarify that whenever possible - but there's a vast gulf between reasonable and unreasonable interpretations. If anything, these areas of confusion are only revealed through greater transparency - whether of certificates or practices - and those affected by this issue, whether CAs or Subscribers, should instead be focused on how to bring about greater transparency in policies and practices. By doing that, areas of reasonable confusion can be identifed, and meaningful transition plans can be applied. But suggestions that this was somehow "hurried", when it was discussed for years, is just factually and demonstrably wrong. And regardless of whether customers of certain CAs understood it, the CAs themselves were expected to, and the fault lies with them. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
