Gerv, I assume this applies equally to cross signing, but not to "Vanity" CAs that are set up and run by the CA on behalf of a customer. Is that accurate?
Doug > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign....@lists.mozilla.org] On Behalf Of > Gervase Markham via dev-security-policy > Sent: Tuesday, October 24, 2017 11:28 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Proposed policy change: require private pre-notification of 3rd party > subCAs > > One of the ways in which the number of organizations trusted to issue for > the WebPKI is extended is by an existing CA bestowing the power of issuance > upon a third party in the form of control of a non-technically-constrained > subCA. Examples of such are the Google and Apple subCAs under GeoTrust, > but there are others. > > Adding new organizations to the list of those trusted is a big deal, and > currently Mozilla has little pre-insight into and not much control over this > process. CAs may choose to do this for whoever they like, the CA then bears > primary responsibility for managing that customer, and as long as they are > able to file clean audits, things proceed as normal. > > Mozilla is considering a policy change whereby we require private pre- > notification of such delegations (or renewals of such delegations). > We would not undertake to necessarily do anything with such notifications, > but lack of action should not be considered permissive in an estoppel sense. > We would reserve the right to object either pre- or post-issuance of the > intermediate. (Once the intermediate is issued, of course, the CA has seven > days to put it in CCADB, and then the relationship would probably become > known unless the fields in the cert were misleading.) > > This may not be where we finally want to get to in terms of regulating such > delegations of trust, but it is a small step which brings a bit more > transparency while acknowledging the limited capacity of our team for > additional tasks. > > Comments are welcome. > > Gerv > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
