On Wed, 2017-06-28 at 15:08 -0700, Ryan Sleevi via dev-security-policy wrote: > On Wednesday, June 28, 2017 at 5:29:19 PM UTC-4, Gervase Markham wrote: > > Well, the fact that we now use Git,
NSS and the root store don't use Git, it uses HG/Mercurial. > > I suspect, means anyone could plug > > in a modern CI CI meaning Continuous Integration ? > > tool that did "Oh, you changed file X. Let me regenerate > > file Y and check it in alongside". Without really needing anyone's > > permission beyond checkin access. I'd prefer a bit more control. Any conversion script, which translates from a new high level file format, to a specific technical file format used by our software, could have bugs. If everything is automated, there's more risk that changes might not get reviewed, and bugs aren't identified. > I don't believe the state of NSS infrastructure is well-placed to support that > claim. I'd be curious for Kai's/Red Hat's feedback. I'm not sure I correctly understand this sentence, but if you're asking if we have such conversion magic, we don't. There's the technicaly possibility of having commit hooks. But I'm not sure I like that approach. > > Well, I don't do the actual maintenance of certdata.txt, but I assume > > (perhaps without evidence) that telling whoever does that "hey, you now > > need to use this tool to edit the canonical information store, instead > > of the text editor you have been using" might not go down well. It > > wouldn't if it were me. > > It already (effectively) requires a tool to make sure it's done right, AIUI :) > > But I think you're still conflating "text" vs "human readable", and I'm not > sure that they represent equivalents. That is, "human readable" introduces a > subjective element that can easily lead to ratholes about whether or not > something is "readable enough", or coming up with sufficient ontologies so > that it can "logically map" - just look at XML for the case study in this. > > You can have a JSON file, but that doesn't mean it's human-readable in the > least. > > That's why I'm pushing very hard on that. I wouldn't call our existing certdata.txt format easily human readable either. It's only human readable because our tool, which produces new entries, also adds human readable comments. It would be very difficult to notice if the text differes from the binary presentation (unless you write and execute a verification script that ensures everything matches). We currently achieve the matching (hopefully) by carefully reviewing changes. I would discourage a few things when introducing a JSON file format, like, avoid unnecessary changes in line wrapping or reordering, to make it easier to compare different revisions. > > No, because NSS consumers could choose to continue consuming the > > (autogenerated by the CI tool) certdata.txt. > > The CI tools don't check in artifacts. What does artifact mean in this context? > You're proposing giving some piece of infrastructure the access to generate > and check in files? I believe Mozilla may do that, but NSS does not, and the > infrastructure is separately maintained. > > > You want me to rank my goals in order of preference? :-) > > Moreso be more explicit in the goals. It's trying to figure out how 'much' > interoperability is being targeted here :) > > > 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? Are you suggesting that we should convert certdata.txt into a file format that others would prefer to consume? Yes, that's another option. But it wouldn't solve the idea to also store the Mozilla EV attributes in the common place. Firefox developers would have to start converting information found inside NSS to Firefox application code. > Which is all still a facet of the original question: Trying to determine what > your goals are / what the 'necessary' vs 'nice to have' features are :) > > > It's not a massive improvement if we are the only group using it. I > > think there is value to Mozilla even if MS and Apple don't get on board, > > because our root store gets more descriptive of reality, but that value > > alone might not be enough to convince someone like the two people who > > have expressed interest thusfar to take the time to work on the spec. I > > don't know. > > But why doesn't certdata.txt meet that already, then? It's a useful thought > experiment to find out what you see the delta as, so that we can understand > what are and are not acceptable solutions. > > > 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. I think Mozilla could and should try to. See my suggestion to use invented identifiers for describing each category of invented partial distrust. Kai > 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". > > (Which, for what it's worth, is what Microsoft does with the authroot.stl, > effectively) _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
