Hi Kai, On 30/06/17 17:38, Kai Engert wrote: > given that today we don't have a single place where all of Mozilla's > certificate > trust decisions can be found, introducing that would be a helpful.
I'm glad you see the value in my goal :-) > I think the new format should be as complete as possible, including both trust > and distrust information, including EV and description of rules for partial > distrust. I agree, as long as we can stay away from defining a format of arbitrary complexity. > It would be good if the new format made it very clear that there are distrust > entries, and that trust for some CAs is only partial. The latter could make it > easier for list consumers to identify the partially restricted CA. E.g. some > might decide to rather not trust a restricted CA at all, if the consumer is > technically unable to implement the restricting checks. Yes, indeed. > Regarding the question how we create new entries for certdata.txt today, we > currently use the NSS tool "addbuiltin". It takes a certificate as input, and > can create both positive trust or distrust lines in the current file format, > that we simply appended to the certdata.txt file. Ah, OK. So you would not be against the idea of using a tool to maintain the list in the future? > Regarding which file format should be used for the new master trust list. > Unless > we want to change the way how NSS works, it will probably be helpful to > continue > to use the certdata.txt file format, even if it's just used as an intermediate > in a double conversion. I certainly think we should continue to maintain the store in that format. The question is whether that format is the canonical format, or a derivative format. My feeling was that if we want to be able to add these new forms of restriction, EV status and so on, we should define a new format. Ryan seems to think we may be able to do this within the existing certdata.txt format. > Instead of requiring everything to be a single file, maybe it could even work > to > use an archive file (e.g. zip), that contains all information in easily > consumable pieces, which would make it unnecessary to serialize and > deserialize > the certificates while working with the list, and allows maintainers to use > tools that work with the certificates directly. I think that runs the greater risk of people creating systems which just trust every certificate in the bundle... > With this approach, we could also declare that the master location for this > trust list is somewhere outside of NSS (in a separate repository). If we did > that, the primary location could simply be its own HG/GIT repository, with all > the individual files. Releases of Mozilla trust list could be an archive file > that gets published with a checksum file/signature. We could do this with any approach. Are you interested in the idea of making the trust list an independently-maintained item, which is just pulled into NSS each time an NSS release is done? Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
