On Mon, Apr 2, 2018 at 5:15 PM, Wayne Thayer via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > 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).
A CP is an optional document and may be maintained by an entity other than the CA. For example there may be a common policy that applies to all CAs that have a path to a certain anchor. So including the CA list in a CP is not useful. I also don't think that the CPS is the right place to list the CAs. The CPS of a CA is an attribute of the CA, but the CAs are not an attribute of a CPS. This is why I strongly suggest that the CA make a signed binding statement that a new subCA will follow CPS X and that the new subCA will be included in the next audit. It gets the relationship correct. Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
