Ben, I think Gerv addressed Doug's concern and indicated that situation wouldn't fall under this policy. If that's not accurate, it'd be worth an on-list clarification.
On Tue, Oct 24, 2017 at 9:01 AM, Ben Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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 > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
