Re: Update on transition of the Verizon roots and issuance of SHA1 certificates
Bonjour, Le lundi 9 janvier 2017 18:02:57 UTC+1, Jeremy Rowley a écrit : > Not many websites, but all of the Belgium ID cards would end up being > revoked. Not exactly. The "Belgium Root CAx" CA certificates issued by Cybertrust would be revoked, but since these CAs also have self-signed certificates, Belgium ID cards will still have a valid chain up to these self-signed "Belgium Root CAx" certificates. > Although Belgium is only issuing client certs, the issuing CA is not > technically constrained, meaning a BR, Network security, and standard > WebTrust audit is required. We are currently waiting for the results of the > audit report. And maybe the opinion report from a Qualified Auditor regarding the private key generation of these subordinate CAs. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Update on transition of the Verizon roots and issuance of SHA1 certificates
I'll go through those in the next day or so and fix the CPS and audit settings. Ben Wilson, JD, CISA, CISSP DigiCert VP Compliance -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Rob Stradling Sent: Monday, January 9, 2017 10:02 AM To: Jeremy Rowley ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Update on transition of the Verizon roots and issuance of SHA1 certificates On 09/01/17 16:35, Jeremy Rowley wrote: > Hi Rob - thanks for following up. > > The Belgium root was granted an extension by the browsers until > January 15th to complete the audit and January 31st to submit the > audit report. We are still told they are hosted by Verizon and, > considering the audit progress, I have no reason to doubt this. Jeremy, thanks for that update. Given that you're still anticipating not needing to revoke the Belgian government CAs... Please could you also confirm whether or not the "Same as Parent" tickboxes have been set correctly? Thanks. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ 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: Update on transition of the Verizon roots and issuance of SHA1 certificates
It probably should not be same as parent. Ben will update it. -Original Message- From: Rob Stradling [mailto:rob.stradl...@comodo.com] Sent: Monday, January 9, 2017 10:02 AM To: Jeremy Rowley ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Update on transition of the Verizon roots and issuance of SHA1 certificates On 09/01/17 16:35, Jeremy Rowley wrote: > Hi Rob - thanks for following up. > > The Belgium root was granted an extension by the browsers until > January 15th to complete the audit and January 31st to submit the > audit report. We are still told they are hosted by Verizon and, > considering the audit progress, I have no reason to doubt this. Jeremy, thanks for that update. Given that you're still anticipating not needing to revoke the Belgian government CAs... Please could you also confirm whether or not the "Same as Parent" tickboxes have been set correctly? Thanks. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online 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: Update on transition of the Verizon roots and issuance of SHA1 certificates
On 09/01/17 16:35, Jeremy Rowley wrote: Hi Rob - thanks for following up. The Belgium root was granted an extension by the browsers until January 15th to complete the audit and January 31st to submit the audit report. We are still told they are hosted by Verizon and, considering the audit progress, I have no reason to doubt this. Jeremy, thanks for that update. Given that you're still anticipating not needing to revoke the Belgian government CAs... Please could you also confirm whether or not the "Same as Parent" tickboxes have been set correctly? Thanks. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Update on transition of the Verizon roots and issuance of SHA1 certificates
Not many websites, but all of the Belgium ID cards would end up being revoked. Although Belgium is only issuing client certs, the issuing CA is not technically constrained, meaning a BR, Network security, and standard WebTrust audit is required. We are currently waiting for the results of the audit report. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Kurt Roeckx Sent: Monday, January 9, 2017 9:54 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Update on transition of the Verizon roots and issuance of SHA1 certificates On 2017-01-09 17:28, Rob Stradling wrote: > On 03/11/16 19:34, Jeremy Rowley wrote: > > > Hi Jeremy. > >> 7. The Belgium government is our biggest challenge in migrating >> Verizon customers. With over 20 issuing CAs, Belgium has the largest >> outstanding non-compliant infrastructure. The operators have also >> claimed that revoking their issuing CAs is illegal (in Belgium). The >> government is using the issuing CA for creating personal >> identification (e-ID) cards throughout the country. The Belgium >> government has dictated that they set the rules, not us. Although the >> Belgium government does not have an audit yet, Verizon has >> represented that the issuing CAs are hosted in the Verizon >> infrastructure and are potentially covered by the Verizon audit. > > I've noticed that some of the Belgian government CAs have been > disclosed to the CCADB with the CP/CPS and Audit fields marked as > "Same as Parent", whereas the CP/CPS and Audit fields for the rest of > those CAs have not yet been filled in. Note that the Belgium root CA's information is available at: http://repository.eid.belgium.be/index.php?lang=en As far as I know, most of the certificates are for (client) authentication and signatures as used by the government itself and some websites that make use of it. Those should already be set up to trust that root for client authentication. I think I also found some websites, but most actually use a different CA. So it seems unlikely that many public websites would get broken by revoking it. Kurt ___ 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: Update on transition of the Verizon roots and issuance of SHA1 certificates
On 2017-01-09 17:28, Rob Stradling wrote: On 03/11/16 19:34, Jeremy Rowley wrote: Hi Jeremy. 7. The Belgium government is our biggest challenge in migrating Verizon customers. With over 20 issuing CAs, Belgium has the largest outstanding non-compliant infrastructure. The operators have also claimed that revoking their issuing CAs is illegal (in Belgium). The government is using the issuing CA for creating personal identification (e-ID) cards throughout the country. The Belgium government has dictated that they set the rules, not us. Although the Belgium government does not have an audit yet, Verizon has represented that the issuing CAs are hosted in the Verizon infrastructure and are potentially covered by the Verizon audit. I've noticed that some of the Belgian government CAs have been disclosed to the CCADB with the CP/CPS and Audit fields marked as "Same as Parent", whereas the CP/CPS and Audit fields for the rest of those CAs have not yet been filled in. Note that the Belgium root CA's information is available at: http://repository.eid.belgium.be/index.php?lang=en As far as I know, most of the certificates are for (client) authentication and signatures as used by the government itself and some websites that make use of it. Those should already be set up to trust that root for client authentication. I think I also found some websites, but most actually use a different CA. So it seems unlikely that many public websites would get broken by revoking it. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Update on transition of the Verizon roots and issuance of SHA1 certificates
Hi Rob - thanks for following up. The Belgium root was granted an extension by the browsers until January 15th to complete the audit and January 31st to submit the audit report. We are still told they are hosted by Verizon and, considering the audit progress, I have no reason to doubt this. -Original Message- From: Rob Stradling [mailto:rob.stradl...@comodo.com] Sent: Monday, January 9, 2017 9:28 AM To: Jeremy Rowley ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Update on transition of the Verizon roots and issuance of SHA1 certificates On 03/11/16 19:34, Jeremy Rowley wrote: Hi Jeremy. > 7. The Belgium government is our biggest challenge in migrating Verizon customers. With over 20 issuing CAs, Belgium has the largest outstanding non-compliant infrastructure. The operators have also claimed that revoking their issuing CAs is illegal (in Belgium). The government is using the issuing CA for creating personal identification (e-ID) cards throughout the country. The Belgium government has dictated that they set the rules, not us. Although the Belgium government does not have an audit yet, Verizon has represented that the issuing CAs are hosted in the Verizon infrastructure and are potentially covered by the Verizon audit. I've noticed that some of the Belgian government CAs have been disclosed to the CCADB with the CP/CPS and Audit fields marked as "Same as Parent", whereas the CP/CPS and Audit fields for the rest of those CAs have not yet been filled in. If it's true that all of "the issuing CAs are hosted in the Verizon infrastructure and are potentially covered by the Verizon audit", then it would seem reasonable to expect to see the CP/CPS and Audit details for all of the Belgian government CAs set identically. Right? Using the data on crt.sh (from which https://crt.sh/mozilla-disclosures is produced), I've summarized the current Belgian government CA disclosures in this spreadsheet: https://docs.google.com/spreadsheets/d/1K4DEjqKvC5r_aiUGDYvbJBPVSOm8E6MO6RJQ oj9zbrY/edit?usp=sharing Were the "Same as Parent" tickboxes ticked correctly, or in error? > We've asked Verizon to provide an updated audit report showing coverage of the Belgium issuing CAs by December 1, 2016. If the report is not delivered by December 1, 2016, we plan to immediately revoke the issuing CAs. I note that you did not "immediately revoke" the issuing CAs on December 1, 2016. Does this mean that Verizon did provide "an updated audit report showing coverage of the Belgium issuing CAs" to DigiCert? > If, for whatever reason, we are unable to revoke the issuing CAs at that time, we would certainly not object to the browsers distrusting the issuing CAs issued to Belgium. Are you able to complete the Belgian government CA disclosures yet (either by revoking the issuing CAs or by updating the CP/CPS and Audit details as appropriate)? Thanks. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online 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: Update on transition of the Verizon roots and issuance of SHA1 certificates
On 03/11/16 19:34, Jeremy Rowley wrote: Hi Jeremy. 7. The Belgium government is our biggest challenge in migrating Verizon customers. With over 20 issuing CAs, Belgium has the largest outstanding non-compliant infrastructure. The operators have also claimed that revoking their issuing CAs is illegal (in Belgium). The government is using the issuing CA for creating personal identification (e-ID) cards throughout the country. The Belgium government has dictated that they set the rules, not us. Although the Belgium government does not have an audit yet, Verizon has represented that the issuing CAs are hosted in the Verizon infrastructure and are potentially covered by the Verizon audit. I've noticed that some of the Belgian government CAs have been disclosed to the CCADB with the CP/CPS and Audit fields marked as "Same as Parent", whereas the CP/CPS and Audit fields for the rest of those CAs have not yet been filled in. If it's true that all of "the issuing CAs are hosted in the Verizon infrastructure and are potentially covered by the Verizon audit", then it would seem reasonable to expect to see the CP/CPS and Audit details for all of the Belgian government CAs set identically. Right? Using the data on crt.sh (from which https://crt.sh/mozilla-disclosures is produced), I've summarized the current Belgian government CA disclosures in this spreadsheet: https://docs.google.com/spreadsheets/d/1K4DEjqKvC5r_aiUGDYvbJBPVSOm8E6MO6RJQoj9zbrY/edit?usp=sharing Were the "Same as Parent" tickboxes ticked correctly, or in error? We've asked Verizon to provide an updated audit report showing coverage of the Belgium issuing CAs by December 1, 2016. If the report is not delivered by December 1, 2016, we plan to immediately revoke the issuing CAs. I note that you did not "immediately revoke" the issuing CAs on December 1, 2016. Does this mean that Verizon did provide "an updated audit report showing coverage of the Belgium issuing CAs" to DigiCert? If, for whatever reason, we are unable to revoke the issuing CAs at that time, we would certainly not object to the browsers distrusting the issuing CAs issued to Belgium. Are you able to complete the Belgian government CA disclosures yet (either by revoking the issuing CAs or by updating the CP/CPS and Audit details as appropriate)? Thanks. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Update on transition of the Verizon roots and issuance of SHA1 certificates
This looks like a very accurate representation of the data protection European regulations. I have the same view. Not so easy to implement but if it is implemented correctly, I think very few people will disagree with the essence of this regulation. Dimitris. -- Sent from my mobile device. Pls excuse brevity and typos > On 5 Nov 2016, at 11:50, Nick Lamb wrote: > >> On Friday, 4 November 2016 19:37:07 UTC, Jeremy Rowley wrote: >> We also like the public disclosures CT requires as its been essential in >> identifying issuing CAs and non-compliances. That's probably not a surprise >> as we've always strongly supported CT. I do see the need for name redaction >> though as lots of the certificates are issued to individuals, and the >> European government freaks out whenever there is the potential disclosure of >> PII. > > Unlike with DNS names / IP addresses in the Web PKI, I could still be > persuaded that redacting personal information about individual human > subscribers would make sense. > > Nevertheless I think it's valuable to understand that European regulations in > this area ("Data Protection" is the usual English term) are not intended to > altogether prohibit the disclosure of PII. The regulations are instead > focused on ensuring that subjects know what is held about them, that they're > told how it will be used and why, that the data used is adequate yet not > excessive for that purpose, and that they can get any mistakes fixed. > > So Data Protection could permit unredacted CT logging if it served some > legitimate purpose, particularly one that's in the subject's best interest > such as deterring identity fraud or protecting the integrity of the > certificate ecosystem they're using, and if subscribers were told about this > before they request the certificate. > ___ > 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: Update on transition of the Verizon roots and issuance of SHA1 certificates
On Friday, 4 November 2016 19:37:07 UTC, Jeremy Rowley wrote: > We also like the public disclosures CT requires as its been essential in > identifying issuing CAs and non-compliances. That's probably not a surprise > as we've always strongly supported CT. I do see the need for name redaction > though as lots of the certificates are issued to individuals, and the > European government freaks out whenever there is the potential disclosure of > PII. Unlike with DNS names / IP addresses in the Web PKI, I could still be persuaded that redacting personal information about individual human subscribers would make sense. Nevertheless I think it's valuable to understand that European regulations in this area ("Data Protection" is the usual English term) are not intended to altogether prohibit the disclosure of PII. The regulations are instead focused on ensuring that subjects know what is held about them, that they're told how it will be used and why, that the data used is adequate yet not excessive for that purpose, and that they can get any mistakes fixed. So Data Protection could permit unredacted CT logging if it served some legitimate purpose, particularly one that's in the subject's best interest such as deterring identity fraud or protecting the integrity of the certificate ecosystem they're using, and if subscribers were told about this before they request the certificate. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Update on transition of the Verizon roots and issuance of SHA1 certificates
The Belgian CAs are publicly disclosed at http://certs.eid.belgium.be/. (I'm in the process of inputting them into the Mozilla database.) -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Jeremy Rowley Sent: Friday, November 4, 2016 1:36 PM To: Peter Bowen Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: RE: Update on transition of the Verizon roots and issuance of SHA1 certificates Thanks Peter for the questions. The answers are listed below: First, a couple of questions about DigiCert itself. The press release at https://thomabravo.com/2015/10/22/thoma-bravo-completes-acquisition-of-major ity-stake-in-digicert/ says that Thoma Bravo acquired a majority stake in DigiCert in October 2015. Looking at the current portfolio (https://thomabravo.com/portfolio/all/current/), I don't see any other CAs, but can you confirm that (a) they still own a majority & controlling share of DigiCert and (b) that Thoma Bravo does not own a majority or controlling share (directly or indirectly) of any other CA? [JR] Yes - Thoma Bravo owns a controlling interest in DigiCert. However, I can't say exactly which companies are owned by Thoma Bravo. That information isn't shared with us other than as disclosed publicly on their website. I do not think they own another CA though. What is the relationship between Cyber Secure Asia (https://www.cybersecureasia.com/about-cyber-secure-asia-csa/newsroom) and DigiCert? Are they a subsidiary, a subordinate CA, a reseller or something else? It is hard to tell, as they talk about DigiCert all over their site but also say something about being a subsidiary of CyberTrust Japan (which might be part of DigiCert?) [JR] They are a reseller. They don't control an issuing CA. > About a year ago in > July, DigiCert closed an agreement with Verizon where DigiCert took > ownership of three publicly-trusted Verizon root certificates. These > certificates are the Verizon Global Root CA, the Baltimore CyberTrust > Root CA, and the Verizon Root CA. According to https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport, DigiCert currently has 10 roots in the Mozilla trust anchor list. These include eight with "DigiCert Inc" in the organization name attribute, one with "Baltimore" in the organization name attribute, and one with "CyberTrust, Inc" in the organization name attribute. The removed CA report (https://mozillacaprogram.secure.force.com/CA/RemovedCACertificateReport) lists one root as belonging to DigiCert. This has "GTE Corporation" in the organization name attribute. [JR] We acquired this root with the transaction. The root is not publicly trusted and was removed from the root store prior to the acquisition. You list three root certificates in your email. Which of the DigiCert certificates in the Mozilla root reports map to the three you list? [JR] All DigiCert roots and all issuing CAs chained to the DIgiCert root are owned and operated by DIgiCert. The DigiCert roots have never cross-signed another CA. There is a one-way trust between the Verizon roots and DigiCert where Verizon cross-signed for ubiquity. All of them have the potential to chain back to Verizon, but we usually turn this off by default. You talk about taking ownership of three "root certificates". Did you also take ownership and control of all copies of the associated private keys? Did you take control of other CAs and private keys (e.g. subordinate CAs) or just the three listed above? [JR] Over the last year, we took physical possession of the private keys of two roots. This possession was limited to the root certificates and did not include issuing CAs chained to the roots. The final root (the Cybertrust Global root) should be transferred into our infrastructure this month. Contractually, we needed to keep the root in Europe for a while after the acquisition. > After watching the > issuance of wildcard EV certs, non-compliant subordinate CAs, and > certs with poor profiles, we made a conscious decision to purchase > these roots with the intention of migrating them to more complaint > system. We felt that helping these CAs get to the point of regular > audits and best practices would raise the quality of the entire industry. So would just revoking them. [JR] True, but we weren't aware of any browser plans to revoke the Verizon root certificates. Nothing was publicly announced, and we felt that the Baltimore root was essential in the ecosystem because of the companies it supports. We thought moving the roots into DigiCert resolve previous concerns about the issuance processes and lack of profile control without the browsers needing to take a drastic measure that would distrust several prominent certificate authorities. > Unfortunately, the age of the > roots and l
RE: Update on transition of the Verizon roots and issuance of SHA1 certificates
Thanks Peter for the questions. The answers are listed below: First, a couple of questions about DigiCert itself. The press release at https://thomabravo.com/2015/10/22/thoma-bravo-completes-acquisition-of-majority-stake-in-digicert/ says that Thoma Bravo acquired a majority stake in DigiCert in October 2015. Looking at the current portfolio (https://thomabravo.com/portfolio/all/current/), I don't see any other CAs, but can you confirm that (a) they still own a majority & controlling share of DigiCert and (b) that Thoma Bravo does not own a majority or controlling share (directly or indirectly) of any other CA? [JR] Yes - Thoma Bravo owns a controlling interest in DigiCert. However, I can't say exactly which companies are owned by Thoma Bravo. That information isn't shared with us other than as disclosed publicly on their website. I do not think they own another CA though. What is the relationship between Cyber Secure Asia (https://www.cybersecureasia.com/about-cyber-secure-asia-csa/newsroom) and DigiCert? Are they a subsidiary, a subordinate CA, a reseller or something else? It is hard to tell, as they talk about DigiCert all over their site but also say something about being a subsidiary of CyberTrust Japan (which might be part of DigiCert?) [JR] They are a reseller. They don't control an issuing CA. > About a year ago in > July, DigiCert closed an agreement with Verizon where DigiCert took > ownership of three publicly-trusted Verizon root certificates. These > certificates are the Verizon Global Root CA, the Baltimore CyberTrust > Root CA, and the Verizon Root CA. According to https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport, DigiCert currently has 10 roots in the Mozilla trust anchor list. These include eight with "DigiCert Inc" in the organization name attribute, one with "Baltimore" in the organization name attribute, and one with "CyberTrust, Inc" in the organization name attribute. The removed CA report (https://mozillacaprogram.secure.force.com/CA/RemovedCACertificateReport) lists one root as belonging to DigiCert. This has "GTE Corporation" in the organization name attribute. [JR] We acquired this root with the transaction. The root is not publicly trusted and was removed from the root store prior to the acquisition. You list three root certificates in your email. Which of the DigiCert certificates in the Mozilla root reports map to the three you list? [JR] All DigiCert roots and all issuing CAs chained to the DIgiCert root are owned and operated by DIgiCert. The DigiCert roots have never cross-signed another CA. There is a one-way trust between the Verizon roots and DigiCert where Verizon cross-signed for ubiquity. All of them have the potential to chain back to Verizon, but we usually turn this off by default. You talk about taking ownership of three "root certificates". Did you also take ownership and control of all copies of the associated private keys? Did you take control of other CAs and private keys (e.g. subordinate CAs) or just the three listed above? [JR] Over the last year, we took physical possession of the private keys of two roots. This possession was limited to the root certificates and did not include issuing CAs chained to the roots. The final root (the Cybertrust Global root) should be transferred into our infrastructure this month. Contractually, we needed to keep the root in Europe for a while after the acquisition. > After watching the > issuance of wildcard EV certs, non-compliant subordinate CAs, and > certs with poor profiles, we made a conscious decision to purchase > these roots with the intention of migrating them to more complaint > system. We felt that helping these CAs get to the point of regular > audits and best practices would raise the quality of the entire industry. So would just revoking them. [JR] True, but we weren't aware of any browser plans to revoke the Verizon root certificates. Nothing was publicly announced, and we felt that the Baltimore root was essential in the ecosystem because of the companies it supports. We thought moving the roots into DigiCert resolve previous concerns about the issuance processes and lack of profile control without the browsers needing to take a drastic measure that would distrust several prominent certificate authorities. > Unfortunately, the age of the > roots and large number of cross-signs led to a lot of missing > paperwork and certain issues in identifying which CAs were covered by > audits. Prior to closing we believed there were approximately five > technically constrained sub CAs and around 20 unconstrained sub CAs. > Turns out there were actually more than 200, each with various levels > of compliance. Most of these Sub CAs operated under the Baltimore Cybertrust > root, which was created in 2000. > To their credit, Verizon revoked 48 of the issuing CAs prior to > DigiCert's acquisition of the roots. Given this huge variance, ho
Re: Update on transition of the Verizon roots and issuance of SHA1 certificates
Hi Jeremy, Thanks for posting this. Mozilla had been concerned for some time about the level of BR compliance of the Verizon-controlled PKI and their seeming difficulties in bringing their many sub-CAs into compliance. When DigiCert approached us when researching the potential acquisition, they asked us if we were planning any immediate action against Verizon. We told them we were concerned, but nothing immediate was planned. They told us of their plan to take over ownership of these root hierarchies and clean them up. When considering what to do in issues relating to the web PKI, we are always balancing the potential disruption to users of stopping an activity with the risk of allowing it to continue. We could have just un-trusted the Verizon-controlled roots, but the disruption from that would have been significant. DigiCert's offer to improve things seemed like a good way forward to us. Therefore, once the purchase completed, we told DigiCert they could have some time to bring these hierarchies into BR compliance. Jeremy's post explains how they have been doing that, and the timeline for completing their plan. As a consequence of this promise, and DigiCert's generally robust response when it happens, Mozilla does not currently intend to follow up the fact that a number of the independently-operated sub-CAs under these roots have issued small numbers of SHA-1 certs. That doesn't mean we will overlook every BR or policy violation, and we expect DigiCert and its partners to operate these roots in full compliance once the transition is finished early next year. This is not to say that people shouldn't give feedback on the DigiCert plan or suggest ways to improve it. Please do. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Update on transition of the Verizon roots and issuance of SHA1 certificates
I'm not sure exactly what you are asking. These sub CAs are cross-signs with other entities. DigiCert controls the root, but not the issuing CAs. Except for the ones I listed, they are all WebTrust or ETSI audited so we trust them. They are primarily government, large corporations, and other CAs. Most are transferring away from DigiCert or moving to a solution where we host the private keys and certificates. There are some who insist on operating their own root and cross-sign for ubiquity. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Han Yuwei Sent: Thursday, November 3, 2016 6:14 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Update on transition of the Verizon roots and issuance of SHA1 certificates 在 2016年11月4日星期五 UTC+8上午3:52:23,Jeremy Rowley写道: > Resent without a signature > > > > Hi everyone, > > > > This email is intended to gather public and browser feedback on how we are > handling the transitioning Verizon's customers to DigiCert and share with > everyone the plan for when all non-DigiCert hosted sub CAs will be fully > compliant with the BRs and network security guidelines. Primarily, this > letter addresses when all issuing CAs previously held by Verizon will be > covered by an unqualified audit and how we are responding to the sub CAs that > issued SHA1 certificates. We are looking forward to the browser and public > feedback on how to handle the non-compliant cross-signs and insight on how > the public views our transition progress and planned completion dates. > > > > Background > > Prior to presenting the plan for remediation, I thought I'd share a bit about > our progress with migrating Verizon customers. About a year ago in July, > DigiCert closed an agreement with Verizon where DigiCert took ownership of > three publicly-trusted Verizon root certificates. These certificates are the > Verizon Global Root CA, the Baltimore CyberTrust Root CA, and the Verizon > Root CA. There were many reasons the acquisition made sense, including > acquisition of a root that had cross-signed DigiCert for many years. The > ubiquity of the Verizon roots is wide-spread, which meant a lot of CAs like > to cross-sign with them. Another significant reason for the acquisition was > an attempt to improve the CA industry. After watching the issuance of > wildcard EV certs, non-compliant subordinate CAs, and certs with poor > profiles, we made a conscious decision to purchase these roots with the > intention of migrating them to more complaint system. We felt that helping > these CAs get to the point of regular audits and best practices would raise > the quality of the entire industry. > > > > Prior to the acquisition, we were made aware of several potential > non-compliances by Verizon's customers. We worked closely with Verizon to > clean up many of the Sub CAs, including revoking CAs that would never be > compliant with the requirements and attempting to technically constrain > others. Sub CAs were revoked because they either didn't have an audit, were > unresponsive to communication, or couldn't control their issuance. Verizon > was a great partner and took a very proactive approach in removing CAs that > were not actively working towards compliance. Unfortunately, the age of the > roots and large number of cross-signs led to a lot of missing paperwork and > certain issues in identifying which CAs were covered by audits. Prior to > closing we believed there were approximately five technically constrained sub > CAs and around 20 unconstrained sub CAs. Turns out there were actually more > than 200, each with various levels of compliance. Most of these Sub CAs > operated under the Baltimore Cybertrust root, which was created in 2000. > > > > To their credit, Verizon revoked 48 of the issuing CAs prior to DigiCert's > acquisition of the roots. Unfortunately, this left around 150 for our small > team to work through. Although the endeavor was daunting, Ben Wilson and > others worked to gather audit reports, email customers about compliance > dates, monitor certificates issued, and revoke non-compliant customers. > Verizon was very good at assisting us in these efforts. This information is > now recorded in the Mozilla database and continuously updated as the > information changes. > > > > Transition Process > > After our operational acquisition of the roots (which occurred the last part > of September, 2015), we identified 15 expired issuing CAs, 70 revoked sub > CAs, 131 audited sub CAs, and 36 where the status was unknown. Since then, > we've revoked 25
Re: Update on transition of the Verizon roots and issuance of SHA1 certificates
On Thu, Nov 3, 2016 at 11:28 AM, Jeremy Rowley wrote: > This email is intended to gather public and browser feedback on how we are > handling the transitioning Verizon's customers to DigiCert and share with > everyone the plan for when all non-DigiCert hosted sub CAs will be fully > compliant with the BRs and network security guidelines. Primarily, this > letter addresses when all issuing CAs previously held by Verizon will be > covered by an unqualified audit and how we are responding to the sub CAs > that issued SHA1 certificates. We are looking forward to the browser and > public feedback on how to handle the non-compliant cross-signs and insight > on how the public views our transition progress and planned completion > dates. Jeremy, Thank you for addressing this non-compliance head on. While it probably would have been better to raise this when you became aware of it, it is good that DigiCert brought this to the group proactively rather than waiting for a discussion on "should we dump these roots". I have a bunch of questions, through out the document. First, a couple of questions about DigiCert itself. The press release at https://thomabravo.com/2015/10/22/thoma-bravo-completes-acquisition-of-majority-stake-in-digicert/ says that Thoma Bravo acquired a majority stake in DigiCert in October 2015. Looking at the current portfolio (https://thomabravo.com/portfolio/all/current/), I don't see any other CAs, but can you confirm that (a) they still own a majority & controlling share of DigiCert and (b) that Thoma Bravo does not own a majority or controlling share (directly or indirectly) of any other CA? What is the relationship between Cyber Secure Asia (https://www.cybersecureasia.com/about-cyber-secure-asia-csa/newsroom) and DigiCert? Are they a subsidiary, a subordinate CA, a reseller or something else? It is hard to tell, as they talk about DigiCert all over their site but also say something about being a subsidiary of CyberTrust Japan (which might be part of DigiCert?) > About a year ago in > July, DigiCert closed an agreement with Verizon where DigiCert took > ownership of three publicly-trusted Verizon root certificates. These > certificates are the Verizon Global Root CA, the Baltimore CyberTrust Root > CA, and the Verizon Root CA. According to https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport, DigiCert currently has 10 roots in the Mozilla trust anchor list. These include eight with "DigiCert Inc" in the organization name attribute, one with "Baltimore" in the organization name attribute, and one with "CyberTrust, Inc" in the organization name attribute. The removed CA report (https://mozillacaprogram.secure.force.com/CA/RemovedCACertificateReport) lists one root as belonging to DigiCert. This has "GTE Corporation" in the organization name attribute. You list three root certificates in your email. Which of the DigiCert certificates in the Mozilla root reports map to the three you list? You talk about taking ownership of three "root certificates". Did you also take ownership and control of all copies of the associated private keys? Did you take control of other CAs and private keys (e.g. subordinate CAs) or just the three listed above? > After watching the > issuance of wildcard EV certs, non-compliant subordinate CAs, and certs with > poor profiles, we made a conscious decision to purchase these roots with the > intention of migrating them to more complaint system. We felt that helping > these CAs get to the point of regular audits and best practices would raise > the quality of the entire industry. So would just revoking them. > Unfortunately, the age of the > roots and large number of cross-signs led to a lot of missing paperwork and > certain issues in identifying which CAs were covered by audits. Prior to > closing we believed there were approximately five technically constrained > sub CAs and around 20 unconstrained sub CAs. Turns out there were actually > more than 200, each with various levels of compliance. Most of these Sub CAs > operated under the Baltimore Cybertrust root, which was created in 2000. > To their credit, Verizon revoked 48 of the issuing CAs prior to DigiCert's > acquisition of the roots. Given this huge variance, how sure are you that you have identified all the CA certificates issued by these roots? Did all of the CA certificates include zero path length constraints or are there possibly whole trees of CAs out there that are unknown? > After our operational acquisition of the roots (which occurred the last part > of September, 2015), we identified 15 expired issuing CAs, 70 revoked sub > CAs, 131 audited sub CAs, and 36 where the status was unknown. Since then, > we've revoked 25 issuing CAs and assisted others with technical constraints, > exodus from the Omniroot cross-signing program, or obtaining audits. What is "Omniroot"? How many of these are operated by DigiCert and how many are operated by unaffiliated third pa
Re: Update on transition of the Verizon roots and issuance of SHA1 certificates
在 2016年11月4日星期五 UTC+8上午3:52:23,Jeremy Rowley写道: > Resent without a signature > > > > Hi everyone, > > > > This email is intended to gather public and browser feedback on how we are > handling the transitioning Verizon's customers to DigiCert and share with > everyone the plan for when all non-DigiCert hosted sub CAs will be fully > compliant with the BRs and network security guidelines. Primarily, this > letter addresses when all issuing CAs previously held by Verizon will be > covered by an unqualified audit and how we are responding to the sub CAs that > issued SHA1 certificates. We are looking forward to the browser and public > feedback on how to handle the non-compliant cross-signs and insight on how > the public views our transition progress and planned completion dates. > > > > Background > > Prior to presenting the plan for remediation, I thought I'd share a bit about > our progress with migrating Verizon customers. About a year ago in July, > DigiCert closed an agreement with Verizon where DigiCert took ownership of > three publicly-trusted Verizon root certificates. These certificates are the > Verizon Global Root CA, the Baltimore CyberTrust Root CA, and the Verizon > Root CA. There were many reasons the acquisition made sense, including > acquisition of a root that had cross-signed DigiCert for many years. The > ubiquity of the Verizon roots is wide-spread, which meant a lot of CAs like > to cross-sign with them. Another significant reason for the acquisition was > an attempt to improve the CA industry. After watching the issuance of > wildcard EV certs, non-compliant subordinate CAs, and certs with poor > profiles, we made a conscious decision to purchase these roots with the > intention of migrating them to more complaint system. We felt that helping > these CAs get to the point of regular audits and best practices would raise > the quality of the entire industry. > > > > Prior to the acquisition, we were made aware of several potential > non-compliances by Verizon's customers. We worked closely with Verizon to > clean up many of the Sub CAs, including revoking CAs that would never be > compliant with the requirements and attempting to technically constrain > others. Sub CAs were revoked because they either didn't have an audit, were > unresponsive to communication, or couldn't control their issuance. Verizon > was a great partner and took a very proactive approach in removing CAs that > were not actively working towards compliance. Unfortunately, the age of the > roots and large number of cross-signs led to a lot of missing paperwork and > certain issues in identifying which CAs were covered by audits. Prior to > closing we believed there were approximately five technically constrained sub > CAs and around 20 unconstrained sub CAs. Turns out there were actually more > than 200, each with various levels of compliance. Most of these Sub CAs > operated under the Baltimore Cybertrust root, which was created in 2000. > > > > To their credit, Verizon revoked 48 of the issuing CAs prior to DigiCert's > acquisition of the roots. Unfortunately, this left around 150 for our small > team to work through. Although the endeavor was daunting, Ben Wilson and > others worked to gather audit reports, email customers about compliance > dates, monitor certificates issued, and revoke non-compliant customers. > Verizon was very good at assisting us in these efforts. This information is > now recorded in the Mozilla database and continuously updated as the > information changes. > > > > Transition Process > > After our operational acquisition of the roots (which occurred the last part > of September, 2015), we identified 15 expired issuing CAs, 70 revoked sub > CAs, 131 audited sub CAs, and 36 where the status was unknown. Since then, > we've revoked 25 issuing CAs and assisted others with technical constraints, > exodus from the Omniroot cross-signing program, or obtaining audits. Of the > existing sub CAs, about half remain operational and are either audited or > technically constrained. The other half are either winding down or have been > revoked. All revoked certificates were disclosed to Mozilla via Salesforce > and should be part of OneCRL. > > > > Issuing CAs > > There are only a handful of non-audited sub CAs remaining (see > https://crt.sh/mozilla-disclosures#disclosureincomplete). We have a plan for > each of them that we'd like to share with you. We welcome both browser and > public feedback. This is, of course, simply a proposal on how to finish the > transition and provide transparency into where we are at. We are certainly > willing to modify the plan as needed to further online security and meet the > requirements of the root store operators. > > > > The seven companies listed below are responsible for the remaining unaudited > sub CAs: > > > > 1. ABB has three unaudited issuing CAs. ABB didn't under
Update on transition of the Verizon roots and issuance of SHA1 certificates
Resent without a signature Hi everyone, This email is intended to gather public and browser feedback on how we are handling the transitioning Verizon's customers to DigiCert and share with everyone the plan for when all non-DigiCert hosted sub CAs will be fully compliant with the BRs and network security guidelines. Primarily, this letter addresses when all issuing CAs previously held by Verizon will be covered by an unqualified audit and how we are responding to the sub CAs that issued SHA1 certificates. We are looking forward to the browser and public feedback on how to handle the non-compliant cross-signs and insight on how the public views our transition progress and planned completion dates. Background Prior to presenting the plan for remediation, I thought I'd share a bit about our progress with migrating Verizon customers. About a year ago in July, DigiCert closed an agreement with Verizon where DigiCert took ownership of three publicly-trusted Verizon root certificates. These certificates are the Verizon Global Root CA, the Baltimore CyberTrust Root CA, and the Verizon Root CA. There were many reasons the acquisition made sense, including acquisition of a root that had cross-signed DigiCert for many years. The ubiquity of the Verizon roots is wide-spread, which meant a lot of CAs like to cross-sign with them. Another significant reason for the acquisition was an attempt to improve the CA industry. After watching the issuance of wildcard EV certs, non-compliant subordinate CAs, and certs with poor profiles, we made a conscious decision to purchase these roots with the intention of migrating them to more complaint system. We felt that helping these CAs get to the point of regular audits and best practices would raise the quality of the entire industry. Prior to the acquisition, we were made aware of several potential non-compliances by Verizon's customers. We worked closely with Verizon to clean up many of the Sub CAs, including revoking CAs that would never be compliant with the requirements and attempting to technically constrain others. Sub CAs were revoked because they either didn't have an audit, were unresponsive to communication, or couldn't control their issuance. Verizon was a great partner and took a very proactive approach in removing CAs that were not actively working towards compliance. Unfortunately, the age of the roots and large number of cross-signs led to a lot of missing paperwork and certain issues in identifying which CAs were covered by audits. Prior to closing we believed there were approximately five technically constrained sub CAs and around 20 unconstrained sub CAs. Turns out there were actually more than 200, each with various levels of compliance. Most of these Sub CAs operated under the Baltimo re Cybertrust root, which was created in 2000. To their credit, Verizon revoked 48 of the issuing CAs prior to DigiCert's acquisition of the roots. Unfortunately, this left around 150 for our small team to work through. Although the endeavor was daunting, Ben Wilson and others worked to gather audit reports, email customers about compliance dates, monitor certificates issued, and revoke non-compliant customers. Verizon was very good at assisting us in these efforts. This information is now recorded in the Mozilla database and continuously updated as the information changes. Transition Process After our operational acquisition of the roots (which occurred the last part of September, 2015), we identified 15 expired issuing CAs, 70 revoked sub CAs, 131 audited sub CAs, and 36 where the status was unknown. Since then, we've revoked 25 issuing CAs and assisted others with technical constraints, exodus from the Omniroot cross-signing program, or obtaining audits. Of the existing sub CAs, about half remain operational and are either audited or technically constrained. The other half are either winding down or have been revoked. All revoked certificates were disclosed to Mozilla via Salesforce and should be part of OneCRL. Issuing CAs There are only a handful of non-audited sub CAs remaining (see https://crt.sh/mozilla-disclosures#disclosureincomplete). We have a plan for each of them that we'd like to share with you. We welcome both browser and public feedback. This is, of course, simply a proposal on how to finish the transition and provide transparency into where we are at. We are certainly willing to modify the plan as needed to further online security and meet the requirements of the root store operators. The seven companies listed below are responsible for the remaining unaudited sub CAs: 1. ABB has three unaudited issuing CAs. ABB didn't undergo an audit earlier this year on the assumption that their sub CAs were technically constrained. Unfortunately, the constraints weren't properly implemented, a fact that escaped notice until Rob Stradling's excellent tool exposed a deficiency
Update on transition of the Verizon roots and issuance of SHA1 certificates
Hi everyone, This email is intended to gather public and browser feedback on how we are handling the transitioning Verizon's customers to DigiCert and share with everyone the plan for when all non-DigiCert hosted sub CAs will be fully compliant with the BRs and network security guidelines. Primarily, this letter addresses when all issuing CAs previously held by Verizon will be covered by an unqualified audit and how we are responding to the sub CAs that issued SHA1 certificates. We are looking forward to the browser and public feedback on how to handle the non-compliant cross-signs and insight on how the public views our transition progress and planned completion dates. Background Prior to presenting the plan for remediation, I thought I'd share a bit about our progress with migrating Verizon customers. About a year ago in July, DigiCert closed an agreement with Verizon where DigiCert took ownership of three publicly-trusted Verizon root certificates. These certificates are the Verizon Global Root CA, the Baltimore CyberTrust Root CA, and the Verizon Root CA. There were many reasons the acquisition made sense, including acquisition of a root that had cross-signed DigiCert for many years. The ubiquity of the Verizon roots is wide-spread, which meant a lot of CAs like to cross-sign with them. Another significant reason for the acquisition was an attempt to improve the CA industry. After watching the issuance of wildcard EV certs, non-compliant subordinate CAs, and certs with poor profiles, we made a conscious decision to purchase these roots with the intention of migrating them to more complaint system. We felt that helping these CAs get to the point of regular audits and best practices would raise the quality of the entire industry. Prior to the acquisition, we were made aware of several potential non-compliances by Verizon's customers. We worked closely with Verizon to clean up many of the Sub CAs, including revoking CAs that would never be compliant with the requirements and attempting to technically constrain others. Sub CAs were revoked because they either didn't have an audit, were unresponsive to communication, or couldn't control their issuance. Verizon was a great partner and took a very proactive approach in removing CAs that were not actively working towards compliance. Unfortunately, the age of the roots and large number of cross-signs led to a lot of missing paperwork and certain issues in identifying which CAs were covered by audits. Prior to closing we believed there were approximately five technically constrained sub CAs and around 20 unconstrained sub CAs. Turns out there were actually more than 200, each with various levels of compliance. Most of these Sub CAs operated under the Baltimore Cybertrust root, which was created in 2000. To their credit, Verizon revoked 48 of the issuing CAs prior to DigiCert's acquisition of the roots. Unfortunately, this left around 150 for our small team to work through. Although the endeavor was daunting, Ben Wilson and others worked to gather audit reports, email customers about compliance dates, monitor certificates issued, and revoke non-compliant customers. Verizon was very good at assisting us in these efforts. This information is now recorded in the Mozilla database and continuously updated as the information changes. Transition Process After our operational acquisition of the roots (which occurred the last part of September, 2015), we identified 15 expired issuing CAs, 70 revoked sub CAs, 131 audited sub CAs, and 36 where the status was unknown. Since then, we've revoked 25 issuing CAs and assisted others with technical constraints, exodus from the Omniroot cross-signing program, or obtaining audits. Of the existing sub CAs, about half remain operational and are either audited or technically constrained. The other half are either winding down or have been revoked. All revoked certificates were disclosed to Mozilla via Salesforce and should be part of OneCRL. Issuing CAs There are only a handful of non-audited sub CAs remaining (see https://crt.sh/mozilla-disclosures#disclosureincomplete). We have a plan for each of them that we'd like to share with you. We welcome both browser and public feedback. This is, of course, simply a proposal on how to finish the transition and provide transparency into where we are at. We are certainly willing to modify the plan as needed to further online security and meet the requirements of the root store operators. The seven companies listed below are responsible for the remaining unaudited sub CAs: 1. ABB has three unaudited issuing CAs. ABB didn't undergo an audit earlier this year on the assumption that their sub CAs were technically constrained. Unfortunately, the constraints weren't properly implemented, a fact that escaped notice until Rob Stradling's excellent tool exposed a deficiency a few months ago in how Verizon issuance process. Although Verizon r