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.

dev-security-policy mailing list

Reply via email to