I’ll leave Jeremy’s comments as DigiCert’s most recent.
From: Eric Mill [mailto:e...@konklone.com] Sent: Tuesday, October 24, 2017 2:34 PM To: Ben Wilson <ben.wil...@digicert.com> Cc: Doug Beattie <doug.beat...@globalsign.com>; 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 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 <mailto: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 <mailto:dev-security-policy-bounces%2Bben> =digicert....@lists.mozilla.org <mailto: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 <mailto:g...@mozilla.org> >; mozilla-dev-security-pol...@lists.mozilla.org <mailto: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- > <mailto:dev-security-policy-> > bounces+doug.beattie=globalsign....@lists.mozilla.org > <mailto: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 > <mailto: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 > <mailto: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 <mailto: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 <mailto:dev-security-policy@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-security-policy -- konklone.com <https://konklone.com> | @konklone <https://twitter.com/konklone>
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
