RE: Proposed policy change: require private pre-notification of 3rd party subCAs

[Ben Wilson via dev-security-policy]

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 
Cc: Doug Beattie ; Gervase Markham 
; 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 
 > 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  >;
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  



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

[Eric Mill via dev-security-policy]

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 ;
> 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 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Incident Report : GoDaddy certificates with ROCA Fingerprint

[Daymion Reynolds via dev-security-policy]

Godaddy LLC first became aware of possible ROCA vulnerability exposure on 
Monday October 16th 2017 at 9:30am. The following are the steps we took for 
detection, revocation, and the permanent fix of certificate provisioning:

•   Monday October 16th 2017 AZ, first became aware of the ROCA 
vulnerability.  We downloaded and modified the open source detection tool to 
audit 100% of the non-revoked and non-expired certs we had issued.  
•   Early am Wednesday October 18th AZ we had our complete list of 7 certs 
with the ROCA defect. We verified the results and proceeded to start the 
revocation process. While cert revocation was in progress we started 
researching the long-term detection and prevention of the weak CSR 
vulnerability. 
•   Early am Wednesday October 18th Rob Stradling released a list of certs 
with the vulnerability. 2/7 we revoked were on the list. 
https://misissued.com/batch/28/ 
•   Thursday October 19th by 2:02am AZ, we completed the 7 cert 
revocations. Revocations included customer outreach to advise the customer of 
the vulnerability.
•   Thursday October 19th AZ, two CSRs were submitted for commonNames 
“scada2.emsglobal.net” & “scada.emsglobal.net” and were issued. Each request 
had used the vulnerable keys for CSR generation.  We revoked the certs again on 
Thursday October 19th AZ. During this period, we reached out to the customer to 
educate them regarding the vulnerability and informing them they needed to 
generate a new keypair from an unimpacted device.  Customer was unreachable. 
Friday October 20thAZ,  another cert was issued for commonName 
“scada.emsglobal.net” using a CSR generated with a weak key. We then took 
measures to prevent future certs from being issued to the same common name and 
revoked the cert on October 20th 2017 AZ. 
commonName   crt.sh-link
scada.emsglobal.net  https://crt.sh/?id=3084867 

scada.emsglobal.net  https://crt.sh/?id=238721704   

scada.emsglobal.net  https://crt.sh/?id=238721807

scada2.emsglobal.net https://crt.sh/?id=238720969

scada2.emsglobal.net https://crt.sh/?id=238721559

•   Saturday October 21st 2017 AZ & Sunday October 22nd 2017 AZ, we scanned 
our cert store and identified 0 vulnerable certs. 
•   Monday October 23, 2017 AZ, we have deployed a permanent fix to prevent 
future CSRs generated using weak keys from being submitted. Post scanning of 
the environment concluded 0 certificates at risk. 
 
Below is a complete list of certs under GoDaddy management impacted by this 
vulnerability. 

Alias  crt.sh-link
alarms.realtimeautomation.net  https://crt.sh/?id=33966207 

scada.emsglobal.nethttps://crt.sh/?id=3084867
   https://crt.sh/?id=238721704   
   https://crt.sh/?id=238721807 

www.essicorp-scada.com https://crt.sh/?id=238720405 

marlboro.bonavistaenergy.com   https://crt.sh/?id=238720743 

scada2.emsglobal.net   https://crt.sh/?id=238720969
   https://crt.sh/?id=238721559 

www.jointboardclearscada.com   https://crt.sh/?id=238721242 

*.forgenergy.com   https://crt.sh/?id=238721435 

 
Regards,
Daymion Reynolds
GoDaddy PKI
___
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

[Jeremy Rowley via dev-security-policy]

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 ;
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

[Gervase Markham via dev-security-policy]

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

[Doug Beattie via dev-security-policy]

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

[Ryan Sleevi via dev-security-policy]

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

[Gervase Markham via dev-security-policy]

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