On Mon, Apr 2, 2018 at 4:36 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > While Entrust happens to do this, as a relying party, I dislike frequent > updates to CP/CPS documents just for such formal changes. > > This creates a huge loophole. The CP/CPS is the master set of policies the TSP agrees to be bound by and audited against. If a TSP doesn't include a new subCA certificate in the scope of their CP/CPS, then from an audit perspective there is effectively no policy that applies to the subCA. Similarly, if the TSP claims to implement a new policy but doesn't include it in their CP/CPS, then the audit will not cover it (unless it's a BR requirement that has made it into the BR audit criteria). This is because the CP/CPS is a lengthy legal document which relying > parties are "supposed to" read and understand. Thus each such needless > change generates a huge wave of millions of relying parties being > supposed to obtain and read through that document, a complete waste of > our time as relying parties. > > I think you're confusing the Relying Party Agreement with the CP/CPS. Even so, you've pointed out that it is absurd to use this as an argument against regular CP/CPS updates. TSPs are now required to maintain change logs in their CP/CPS. Would not a quick glance at that meet your needs? It is much more reasonable, from a relying party perspective, for such > informational details to be in a parallel document and/or be postponed > until a scheduled annual or rarer document update (Yes I am aware of the > BR that such needless updates be done annually for no reason at all). > > How would you distinguish between details and material changes? I would argue that a new subCA certificate is more than an informational detail. The point of the BR requirement is to create some documentation indicating that a TSP is regularly reviewing and updating their CP/CPS. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
