On Wednesday, June 28, 2017 at 5:29:19 PM UTC-4, Gervase Markham wrote: > Well, the fact that we now use Git, I suspect, means anyone could plug > in a modern CI 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 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. > 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. > 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. 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? 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. 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
