On Fri, Sep 1, 2017 at 2:07 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> RFC2818 postdates real world https by several years. The original de > facto standard by Netscape/Mozilla used the commonName semantics, which > survived for more than a decade in commonly used software (GNU wget > added SAN support sometime in 2011 for example). Respectfully, you're conflating two different things. You're suggesting support for _only_ common names versus support for subjectAltNames. You are correct to highlight the publication of 2818 happened in 2000, with work beginning in 98. However, you're not correct to suggest the SAN wasn't supported in the original implementations. You are also correct to highlight some implementations ignored 2818 and/or didn't implement support for SAN. However, I don't believe that distinction is relevant to your underlying discussion of nameConstraints or their applicability, no more than a discussion of macOS's lack of support until macOS 10.9 (if memory serves correctly) I realize we're ratholing on trivia here, and perhaps that was a goal, but I think it's important to note that your original statement of fact was inaccurate, and has remained inaccurate, and to the extent that mistatement affects the subsequent design, bears highlighting. The application of nameConstraints to subjectAltName has been aligned, and the use of subjectAltName in preference to commonName has been documented for a considerable amount of time. The application of dNSName nameConstraints to commonNames is, while a note of historical practice for a small number of (widely deployed) clients, is equally not necessary as same clients move towards the deprecation or removal of commonName support. That is, put differently, if we're talking about how systems will/should change, I would argue that it's not relevant to argue how systems previously changed, because the only thing that matters is what _new_ changes will be implemented. You can see this in my explanation about why changing the semantics of nameConstraints (without any other signal) is a fundamentally flawed and problematic idea, and you can see this in a discussion about why constraining commonNames (when new clients don't, won't, or shouldn't support commonNames) is equally a flawed and problematic idea. > So, from the get-go with the standards, it was possible to name constrain >> DNS. Unless you were referencing certificates prior to them being bound to >> domain names, but I can't see how that would be relevant, since the >> context >> is about DNS names. >> >> > Point was that RFC2818 (and RFC2459 which it references for SAN usage) > changed the established interpretation of WebPKI certificates from the > established Mozilla standard. And that this is an obvious precedent to > making such changes. > I'm sorry, this is simply factually false. > The primary problem is the need to not weaken security for code that > starts looking at new (or previously unused) name types after existing > PKI restricted CAs have (obviously) not mentioned the "new" type(s) as > "deny all" entries in their name restrictions. > > The secondary problem is not to burden such restricted CAs with > additional audit or other compliance requirements when such "new" name > types are added to standards such as the CAB/F BRs and the Mozilla root > program polices. I gave multiple suggestions on how to avoid both of those. > Indeed, I am just trying to see those very requirements from the > perspective of the already deployed PKI and its subscribers being the > "existing users" for which interop needs to be ensured. Unfortunately, I do not believe you are succeeding in doing so through proposing semantic changes. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
