On 28/06/17 15:08, Ryan Sleevi wrote: > It already (effectively) requires a tool to make sure it's done right, AIUI :)
Well, we should ask Kai what methods he uses to maintain it right now, and whether he uses 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? > 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. >> 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? >> 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. Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
