I echo Doug's concerns. I can see this process as being useful/helpful where the private key is off-premises, but for vanity CAs where the operator of the root CA maintains control of the private key the same as it does for all other issuing CAs, I think this would introduce unnecessary additional steps.
-----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert....@lists.mozilla.org] On Behalf Of Doug Beattie via dev-security-policy Sent: Tuesday, October 24, 2017 9:44 AM To: Gervase Markham <g...@mozilla.org>; mozilla-dev-security-pol...@lists.mozilla.org Subject: RE: Proposed policy change: require private pre-notification of 3rd party subCAs 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
