On Fri, Apr 6, 2018 at 3:09 PM, Peter Bowen <pzbo...@gmail.com> wrote:

>
> 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.
>
> My definition of a binding assertion is one that the auditor is obligated
to include in the scope of their next audit. How would that be the case
here? I'm interpreting this management assertion a new document that
Mozilla would need to process but that wouldn't provide any value over the
existing requirement that the TSP provide a CPS link (or choose 'same as
parent') in the CCADB record for the new subordinate CA certificate.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to