On Tue, Jun 27, 2017 at 9:58 AM Gervase Markham via dev-security-policy < [email protected]> wrote:
> On 27/06/17 04:16, Rob Stradling wrote: > > If the aim is to replace certdata.txt, authroot.stl, etc, with this new > > format, then I'm more interested. > > I can't speak for other providers, but if such a spec existed, I would > be pushing for Mozilla to maintain our root store in that format, and > auto-generate certdata.txt (and perhaps ExtendedValidation.cpp) on > checkin for legacy uses. > 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. 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. However, the NSS developer would rightfully point out the complexity involved in this - such as what language or tools should be used to translate this form into the native code. Perl or Python (part of MozBuild) may be acceptable to the Mozilla developer, but challenging for the NSS developer. A native tool integrated into the build system (as signtool is for updating the chk tool) presents a whole host of challenges for cross-compilers. 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. 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. 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), as well as to explore the constraints and limits of the NSS (and related) build systems, since the combination of those two factors will determine whether this is just another complex transition (as changing certdata.c to be generated and not checked in was) with limited applicability. > Gerv > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
