RE: Proposed policy change: require private pre-notification of 3rd party subCAs
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
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> 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
RE: Proposed policy change: require private pre-notification of 3rd party subCAs
Assuming the rule applies only to externally run third parties, I think it's an excellent idea, but perhaps it should be a public pre-notification? As you mentioned, the relationship will become transparent through CCDAB submission and the audit report, so what's the advantage of keeping it private? One of the biggest issues with external Sub CAs is they don't go through the root embedment process. Having a public "review" period where the intent to cross-sign is known gives the community transparency into the operation and participation into the process. This process could help a CA from making a bad cross-signing mistake. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@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
Re: Proposed policy change: require private pre-notification of 3rd party subCAs
Hi Doug, On 24/10/17 16:43, Doug Beattie wrote: > I assume this applies equally to cross signing, Yes. > but not to "Vanity" CAs that are set up and run by the CA on behalf of a > customer. If you have physical control of the intermediate and control of issuance, it doesn't apply. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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
Re: Proposed policy change: require private pre-notification of 3rd party subCAs
I think this would be of great benefit to the community. 1) It provides meaningful opportunity to ensure that the Mozilla-specific program requirements are being met. The spate of misissuances discussed in the past few months have revealed an unfortunately common trend of CAs not staying aware of changes. 2) It helps ensure decisions Mozilla has taken to protect users - such as OneCRL or removal of trust - are not unilaterally bypassed and that remediation steps are followed. 3) It helps ensure that proper policies are followed prior to issuance - such as the correct audit reports, key generation ceremonies, etc - have been followed prior to any signatures being created. On Tue, Oct 24, 2017 at 11:28 AM Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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
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
