On Mon, 2017-07-03 at 20:47 -0400, Ryan Sleevi wrote: > On Mon, Jul 3, 2017 at 11:53 AM, Kai Engert <k...@kuix.de> 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
Ok. Should we go that path, then I'd prefer if the new file format lived in its own repository, and that the conversion would be done as a manual step, and the conversion results (certdata.txt for NSS, something else for Firefox EV data etc.) get checked in to the NSS and Firefox repositories, together with version information about the source. This would enable us to compare the converted results and review them for correctness. > Right. And JSON can't have comments. So we'd lose substantially in > expressiveness. I agree with Rob's comment that comments could be added as attributes, if necessary. But ideally, everything that's necessary as a comment could just be added a real attributes. The tool to add new entries could produce the various human readable values that humans want to see, like the extracted subject/issuer names, fingerprints. It would be good if the tool offered a consistency check, to verify that all derived attributes match the embedded certificates. (Or simpler, just regenerate them.) > "Artifact" = generated file run as part of a build process, and then > checked back in. Thanks for the explanation. > > > 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. My response was based on my interpretation of Gerv's suggestion, which I understood as follows: - certdata.txt remains the master, keeps maintained and published with NSS - we define a new file format that's accepted as the standard for several root stores - we convert certdata.txt to that interchange format - we publish the conversion result (the Artifact) My comment meant, if certdata.txt is the master, and if certdata.txt is supposed to be the master source for the complete set of CA trust/distrust information, then it would also be the master place to store any EV attributes. As a consequence, adding such EV attributes to the Firefox code, if required, would require an additional conversion process, from certdata.txt, to the subsets that the Firefox code needs to embed. > 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. Understood. I was commenting on the consequence it would have for EV and Firefox embedded code. > 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. Correct. If we defined certdata.txt as the master source for all data, we'd have to carry all attributes that Firefox needs. I don't see a problem with that, however, it would require full agreement from the Firefox developers, that certdata.txt is indeed the master location, and that the Firefox code must never fork this information, but only ever pick up converted snapshots from certdata.txt. Not sure if this could be enforced. > 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. Well, the invented partial distrust mechanisms are the status quo, and it seems this group hasn't been able to identify better practical solutions yet. Why not document the status quo in a structured way, if it allows other consumers to benefit? Maybe projects like OpenSSL would start to implement these rules, too, if they were clearly documented? > 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" I think so far this discussion was about "How can we document decisions about partial CA distrust?". Can't this technical specification issue remain completely separate from the process of finding answers to the question "How should the trust list adjusted to react to CA incidents" ? I believe your point is, today's partial distrust rules were arbitrary decisions, and in the future, any kind of completely different arbitrary rules might be decided. I don't think that's a problem. As long as we define some identifier for each specific distrust rule (parameterized e.g. by cutoff date), and have some wiki page that clearly explains the rules for each such category, we still empower third party consumers to obtain this information more easily. Kai _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
