On Mon, Jul 3, 2017 at 11:53 AM, Kai Engert <[email protected]> wrote: > > > I suspect, means anyone could plug > > > in a modern CI > > CI meaning Continuous Integration ? >
Yes. Gerv's proposal rests on the idea of having a file committed that explains it in human-readable and machine-readable (simultaneously) form, and then have a continuous integration build translate that into something consumable by NSS, and then commit that generated file back into the tree (as I understand it). For example, the resulting certdata.txt or certdata.c > 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. > Agreed > > 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. > That's what I was asking about. > There's the technicaly possibility of having commit hooks. But I'm not > sure I > like that approach. > I agree. > 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. > Right. And JSON can't have comments. So we'd lose substantially in expressiveness. > > > 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? > "Artifact" = generated file run as part of a build process, and then checked back in. > > 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. > I'm not sure I fully understand your response. The suggestion was that if there's some 'other format' that leads interoperability to downstream consumers, it 'could' be a path to take certdata.txt and have a tool that can generate that 'other format' from certdata.txt. The purpose of this thought experiment was to find what, if any, limitations exist in certdata.txt. You've highlighted a very apt and meaningful one, in theory - which is that EV data is a Mozilla Firefox (and exclusively Firefox) concept, while trust records are an aspect of the root store, hence, the dual expression between Mozilla Firefox source and NSS source. If we wanted to make "EV" a portion of NSS (which makes no sense for, say, Thunderbird), we could certainly express that - but it means carrying around unneeded and unused attributes for other NSS consumers. > > > 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. > I don't disagree we can - on a technical level. But I don't agree that the ontology of invented partial distrust holds, nor is it terribly useful to try to expect us to generalize distrust for the various ways in which CAs fail the community. That said, even when thinking about the concepts, the fact that the goal is presently woefully underspecified means we cannot have a good objective discussion about why "Apply the WoSign policy" is better or worse than a notion of "Distrust certificates after this date" - or perhaps even a more complex policy, like "Distrust X certificates after A date, Y certificates after B date, Z certificates after C date, unless conditions M, N, O are also satisfied" _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
