On 27/06/17 10:35, Ryan Sleevi wrote: > If that is the goal, it may be useful to know what the proposed limitations > / dependencies are. For example, the translation of the txt to the c file > generated non-trivial concern among the NSS development team to support.
I propose it be part of the checkin process (using a CI tool or similar) rather than part of the build process. Therefore, there would be no new build-time dependencies for NSS developers. > For example, one possible suggestion is to adopt a scheme similar to, or > identical to, Microsoft's authroot.stl, which is PKCS#7, with attributes > for indicating age and expiration, and the ability to extend with > vendor-specific attributes as needed. One perspective would be to say that > Mozilla should just use this work. That's one option. I would prefer something which is both human and computer-readable, as certdata.txt (just about) is. > Yet if the goal is cross-vendor compatibility, one can argue that is the > best approach, as t changes the number of vendors implementing it to 2, > from the present 1, and thus achieves that goal. As you introduce the > concept of Apple, but which has historically been a non-participant here, > it makes it hard to design a system acceptable to them. Apple suggested they'd like to make this data available; my hope would be that if a format could be defined, they might be persuaded to adopt it. > Further, one could > reasonably argue that an authroot.stl approach would trouble Apple, much as > other non-SDO driven efforts have, due to IP concerns in the space. > Presumably, such collaboration would need to occur somewhere with > appropriate IP protections. Like, really? Developing a set of JSON name-value pairs to encode some fairly simple structured data has potential IP issues? What kind of mad world do we live in? > These criticisms are not meant to suggest I disagree with your goal, merely > that it seems there would be a number of challenges in achieving your goal > that discussion on m.d.s.p. would not resolve. The way to address these > challenges seems to involve getting firm commitments and collaboration with > other vendors (since that is your primary goal), Well, if there was some chance of someone taking on the work - which perhaps there seems to be, based on other replies - then that would be a good next step. But there's no point in me having those discussions if there's no-one willing to do the work. Hence my original question. Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
