On Wednesday, June 28, 2017 at 7:39:37 PM UTC-4, Gervase Markham wrote: > Well, we should ask Kai what methods he uses to maintain it right now, > and whether he uses a tool.
For the recent name constraints, it was a tool. > > You can have a JSON file, but that doesn't mean it's human-readable in the > > least. > > You mean you can stick it all one one line? Or you can choose opaque key > and value names? Or something else? Well, the current certdata.txt is a text file. Do you believe it's human-readable, especially sans-comments? > > > The CI tools don't check in artifacts. You're proposing giving some piece > > of infrastructure the access to generate and check in files? > > I am led to understand this is a fairly common pattern these days. Please realize that this makes it impossible to effectively test changes, without running said tool. This is, again, why certdata.txt being generated is part of the build - so that when you change a file, it's reflected in the build and code and you can effectively test. Moving to a CI system undermines the ability to effectively contribute and test. That's why "machine-readable" is, in effect, a must-have. Whether or not "human-readable" is (and what constitutes human-readable) is the point of discussion, but if you check in the machine-readable form, then anyone can generate the human-readable form at any time. > > >> If Apple said "we are happy to use the MS format", I guess the next > >> thing I would do is find Kai or whoever maintains certdata.txt and say > >> "hey, it's not ideal, but what do you think, for the sake of everyone > >> using the same thing?". > > > > Thought experiment: Why not have certdata.txt generate a CI artifact that > > interoperates for other consumers to use? > > Because certdata.txt's format is not rich enough to support all the data > we would want to encode in a root store. We could consider extending it, > but why would we roll our own container format when there exist > perfectly good ones? Could you explain how you arrive at that conclusion? That may simply be a technical misunderstanding, as certdata.txt's format allows for the expression of arbitrary attributes (as recently added with the "Mozilla Root" attribute) in an appropriate form. Which may be why we're at cross-purposes here - the existing certdata.txt is already technically capable of expressing the constraints. However, it is a complex technical burden to express that in metadata, rather than in code - and that is true no matter what format you choose. If your understanding was based on a misunderstanding that "certdata.txt cannot be extended to support arbitrary metadata", then I can easily tell you that's not the case. It's a matter of changing NSS to, rather than express something simply and cleanly in code (relatively speaking), finding an ontology to express the constraint in a machine-readable (but not-code) format, and then code to parse that and apply in 100 lines what might take 5 lines in code. This is the same as the authroot.stl - both are quite robust, arbitrarily-extensible formats. The choice to not extend is not one about technical limitation, but about unreasonable return for the cost to implement. > > >> Mozilla's opinions on roots are defined by the sum total of: > >> > >> 1) certdata.txt > >> 2) ExtendedValidation.cpp > >> 3) The changes listed on > >> https://wiki.mozilla.org/CA/Additional_Trust_Changes > > > > 1 & 2 for sure. I don't believe #3 can or should be, certainly not > > effectively maintained. Certainly, Google cannot and would not be able to > > find an acceptable solution on #3, just looking at things like CT, without > > introducing otherwise meaningless ontologies such as "Follows > > implementation #37 for this root". > > There are seven items on the list in #3. The first one is item 2, above. > The second is not a root store modification, technically. The third, > fifth and sixth would be accommodated if the new format had a "notAfter" > field. The fourth and seventh would be accommodated if the new format > had a "name constraints" field. > > So putting all of #3, as it currently stands, into a new format seems > eminently doable. That doesn't mean every restriction we ever think of > could be covered, but the current ones (which are ones I can see us > using again in the future) could be. That takes a very Mozilla-centric view, but that doesn't align with, say, the goal of supporting Apple. For example, Apple has three CAs where only certain, previously disclosed (via CT) certificates are trusted - https://opensource.apple.com/source/security_certificates/security_certificates-55070.30.7/certificates/allowlist/ - CNNIC and WoSign. In a machine-readable form, either you put that in a unified file, or you come up with an ontology for expressing dependencies that stretches well beyond the sane bounds. Mozilla's solution to this was, unsurprisingly, with code ( see https://dxr.mozilla.org/mozilla-central/source/security/certverifier/CNNICHashWhitelist.inc ) - would you see that be expressed in the same file? Similarly, consider Google's implementation of CT requirements (for Symantec), or the recently removed whitelist for WoSign/StartCom - both implemented via code. So clearly, we get in situations where not all restrictions are expressible. From a purely pragmatic standpoint, I think it would be undesirable to bake those assumptions and logic into the code. Our goal with Chrome is to remove such transition code as quickly and efficiently as possible - there's no reason to burden a billion users with code 'just in case' a CA has issues again. Rather, we focus our limited time and engineering efforts on helping find solutions that avoid such issues in the first place, while recognizing the conceptual solution is what we may want to redeploy - and if so, we can introduce the specific code for the limited time. Put differently, rather than try to design and enshrine in code that CAs will fail and we should have methods X, Y, and Z to deal with it, it seems much more beneficial to try to avoid the failure in the first place. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
