On Fri, Apr 6, 2018 at 3:09 PM, Peter Bowen <[email protected]> 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
