info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Update on transition of the Verizon roots and issuance of SHA1 certificates
1,850 views
Skip to first unread message
Jeremy Rowley
Nov 3, 2016, 3:52:23 PM11/3/16
to mozilla-dev-s...@lists.mozilla.org
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 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 restricted domain names and IPv4 IP addresses, the CAs could still issue for the IPv6 space. Despite promptly replacing the certificates after discovering the gap, we haven't revoked the issuing CAs. Right now, ABB is actively working to transition its servers to the new, properly-constrained certificates. We expect the transition to complete by the end of December 2016. We are revoking the issuing CAs as the migration completes and expect all of the ABB non-compliant issuing CAs to be revoked on January 5th. No new certs are being issued from the faulty issuing CAs.
2. Similar to ABB, Verizon created two technically constrained issuing CAs for Bechtel. Like ABB, Verizon failed to restrict IPv6 issuance for each of the issuing CAs. Bechtel is actively migrating the remaining 785 certificates to properly constrained issuing CAs. The migration process will complete at the end of December, after which the non-conforming issuing CAs will be revoked. They are included in our January 5th revocation plan. This will also revoke the three issuing CAs created further down in the chain.
3. Dell also thought they were technically constrained. Similar to ABB and Bechtel, the restriction was inadequate. Fortunately, Dell isn't using the issuing CAs and doesn't require migration. We've previously revoked four issuing certificates (Bug 1279066) but missed one during the process. We plan to immediately revoke the remaining issuing CA and all CAs subordinate to the issuing CA.
4. While Certipost is hosted by Verizon's internal infrastructure, the Verizon WebTrust audit letter did not specifically identify the Certipost CAs as audited. DigiCert has been in the process of revoking these CAs but there is some confusion about the effects of the revocation. Apparently the certificates are used for air traffic control in Europe and there is a fear that revoking the intermediate may cause planes to fall out of the sky. After trying to sort out this mess and giving Certipost time to transition, we've decided to revoke the issuing certificates the last week of November. We believe there are over 400 outstanding certificates that will be affected.
5. Postecom refused an audit and decided to exit operation of a CA. We have not yet revoked their issuing CAs in order to give them time to migrate to a different CA infrastructure. They asked that we keep the issuing CAs active until December 31, 2016 to complete the migration. Although they have worked on migrating certs, Postecom still has 1185 certificates to migrate in the next two months. The issuing CAs are scheduled for revocation on January 5th.
6. Vodafone completed a Webtrust audit this year. Unfortunately, we found out that the audit has qualifications. The audit report hasn't issued yet but should later in November. Once the audit report issues, we will provide a copy of the report for evaluation. We've been told that the qualifications are related to the network security guidelines. They probably also include the SHA1 issuance, although we haven't been told that directly. Vodafone is currently designing and building a new CA infrastructure that will house all of their operations. To ensure compliance, we are requiring the new infrastructure to undergo a point-in-time audit in December. We are also requiring a full audit on their issuance processes at the start of next year. A full, non-qualified audit report is expected by March 31, 2016. Although this is well past the compliance date, we are sympathetic to Vodafone as they have been actively working towards compliance. They also have 4,580 public facing SSL certs makes revocation tricky. They issue a lot of client certificates from these sub CAs where revocation could have a potentially devastating effect on telecommunications. Because of the large impact of revocation and how hard Vodafone is working to migrate, we'd like permission for them to comply by March 31, 2017, assuming serious issues are not uncovered by the audit report and that the December and January audits pass unqualified.
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. 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. 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.
Resolving these remaining seven issues will, bring all Verizon's sub CAs into compliance with the audit requirements by March 31, 2017. As of January 2017, all sub CAs operated under the Verizon umbrella will have a non-qualified audit with the exception of Vodafone, which will have a non-qualified point-in-time audit by then.
SHA-1
Although by March 31, 2017, all former Verizon customers will comply with the audit portion of the BRs, experience has recently shown that strict compliance of profile requirements is more difficult to enforce. Such is the case of the SHA1 certificates issued by Nets Norway, Siemens, and Vodafone. Nets Norway and Siemens were both ETSI audited while Vodafone opted for a Webtrust audit.
Shortly after the Verizon transaction, we sent a statement to each CA announcing the acquisition and our expectation of strict compliance with the BRs and network security requirements. On January 27, 2016, we sent another email to all CAs that reiterated the need for strict adherence to standards and requirement for CAs to update their infrastructure as needed to maintain an unqualified audit. The specifically stated that issuance of internal name certificates and SHA1 certificates is strictly forbidden. Nets Norway, Vodafone, and Siemens all received a copy of this email.
As all the sub CAs should have been aware of the requirements in 2015, were reminded this year, and had audits of their infrastructure, we are very disappointed by the recently discovered SHA-1 issuance. We've contacted each of the sub CAs asking for an explanation on what happened and why their infrastructure wasn't sufficient to prevent SHA1 issuance.
Of the SHA1 cert issuers, Vodafone is the only sub CA that responded by providing a timeline for compliance, information about how they are migrating to new CA (which we already knew), and a plan going forward to undergo an audit and make sure technical constraints are active to prevent additional SHA1 certificates. Siemens replied that they are revoking the SHA1 certificates, that issuance was a mistake, and that they are taking action to prevent additional mis-issuance. However, the specifics of their plan are vague (other than providing operational training to prevent reoccurrence). For both Vodafone and Siemens, this is their first offense in mis-issuing a SHA1 certificate, and we'd ask for leniency. We do recognize that this is a serious concern and can revoke the issuing CAs if the action is decided necessary. For full disclosure, Siemens is transitioning away from the Verizon root certificate to another CA. We are only maintained the validity of their cross-sign in a good faith effort to help them complete the transition. We were planning to revoke the issuing CAs early next year (January 5th) once the transition is completed.
The final CA is Nets Norway. Unlike the other two issuing CAs, Nets Norway issued a SHA1 certificate earlier this year. Although Nets Norway promptly revoked the certificate and provided verbal assurances that SHA1 issuance would be restricted, the company obviously failed to take adequate measures. We informed Nets Norway that we are revoking their issuing CA later this month. We haven't revoked them yet because we wanted to complete the incident report first and allow public comment before finalizing the decision.
Our investigation of Verizon's, Postecom's, and Telecom Italia's issuance of a SHA1 certificate is ongoing. As mentioned above, Postecom is scheduled for revocation. Our plan for now is to keep the current revocation schedule for Postecom as the SHA1 issuance occurred twice during January. We haven't formed a plan for Verizon or Telecom Italia yet and are waiting to hear back from their representatives. Verizon issued a single certificate back in January. Telecom Italia issued three in early January and February. Each of these incidents were only recently discovered by DigCert. We've since added an active monitor to crt.sh to alert our compliance team if a SHA1 certificate issues.
Conclusion
Hopefully this helps explain the status of the Verizon transition and the recent SHA1 incidents. We are still collecting information from the three issuing sub CAs about what happened, but I hope this is enough to provide transparency and make a decision on how to proceed.
Despite the difficulties in bringing these customers into compliance, we still think the Verizon transaction was a good move from a compliance perspective. Helping these sub CAs identify problems and improve their processes has been an enlightening experience and given us insight on some of the difficulties other CAs may face in complying with the BRs. The process has been interesting exercise in helping others make remediation plans and trying to accelerate what feels like a slow-moving project. Despite the long nights, headaches, and frustrations, I think we've been successful in our original goal of improving the security ecosystem. I'm also very pleased that the end of the transition is almost here!
We appreciate your feedback and look forward to your comments.
Sincerely,
Jeremy
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 restricted domain names and IPv4 IP addresses, the CAs could still issue for the IPv6 space. Despite promptly replacing the certificates after discovering the gap, we haven't revoked the issuing CAs. Right now, ABB is actively working to transition its servers to the new, properly-constrained certificates. We expect the transition to complete by the end of December 2016. We are revoking the issuing CAs as the migration completes and expect all of the ABB non-compliant issuing CAs to be revoked on January 5th. No new certs are being issued from the faulty issuing CAs.
2. Similar to ABB, Verizon created two technically constrained issuing CAs for Bechtel. Like ABB, Verizon failed to restrict IPv6 issuance for each of the issuing CAs. Bechtel is actively migrating the remaining 785 certificates to properly constrained issuing CAs. The migration process will complete at the end of December, after which the non-conforming issuing CAs will be revoked. They are included in our January 5th revocation plan. This will also revoke the three issuing CAs created further down in the chain.
3. Dell also thought they were technically constrained. Similar to ABB and Bechtel, the restriction was inadequate. Fortunately, Dell isn't using the issuing CAs and doesn't require migration. We've previously revoked four issuing certificates (Bug 1279066) but missed one during the process. We plan to immediately revoke the remaining issuing CA and all CAs subordinate to the issuing CA.
4. While Certipost is hosted by Verizon's internal infrastructure, the Verizon WebTrust audit letter did not specifically identify the Certipost CAs as audited. DigiCert has been in the process of revoking these CAs but there is some confusion about the effects of the revocation. Apparently the certificates are used for air traffic control in Europe and there is a fear that revoking the intermediate may cause planes to fall out of the sky. After trying to sort out this mess and giving Certipost time to transition, we've decided to revoke the issuing certificates the last week of November. We believe there are over 400 outstanding certificates that will be affected.
5. Postecom refused an audit and decided to exit operation of a CA. We have not yet revoked their issuing CAs in order to give them time to migrate to a different CA infrastructure. They asked that we keep the issuing CAs active until December 31, 2016 to complete the migration. Although they have worked on migrating certs, Postecom still has 1185 certificates to migrate in the next two months. The issuing CAs are scheduled for revocation on January 5th.
6. Vodafone completed a Webtrust audit this year. Unfortunately, we found out that the audit has qualifications. The audit report hasn't issued yet but should later in November. Once the audit report issues, we will provide a copy of the report for evaluation. We've been told that the qualifications are related to the network security guidelines. They probably also include the SHA1 issuance, although we haven't been told that directly. Vodafone is currently designing and building a new CA infrastructure that will house all of their operations. To ensure compliance, we are requiring the new infrastructure to undergo a point-in-time audit in December. We are also requiring a full audit on their issuance processes at the start of next year. A full, non-qualified audit report is expected by March 31, 2016. Although this is well past the compliance date, we are sympathetic to Vodafone as they have been actively working towards compliance. They also have 4,580 public facing SSL certs makes revocation tricky. They issue a lot of client certificates from these sub CAs where revocation could have a potentially devastating effect on telecommunications. Because of the large impact of revocation and how hard Vodafone is working to migrate, we'd like permission for them to comply by March 31, 2017, assuming serious issues are not uncovered by the audit report and that the December and January audits pass unqualified.
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. 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. 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.
Resolving these remaining seven issues will, bring all Verizon's sub CAs into compliance with the audit requirements by March 31, 2017. As of January 2017, all sub CAs operated under the Verizon umbrella will have a non-qualified audit with the exception of Vodafone, which will have a non-qualified point-in-time audit by then.
SHA-1
Although by March 31, 2017, all former Verizon customers will comply with the audit portion of the BRs, experience has recently shown that strict compliance of profile requirements is more difficult to enforce. Such is the case of the SHA1 certificates issued by Nets Norway, Siemens, and Vodafone. Nets Norway and Siemens were both ETSI audited while Vodafone opted for a Webtrust audit.
Shortly after the Verizon transaction, we sent a statement to each CA announcing the acquisition and our expectation of strict compliance with the BRs and network security requirements. On January 27, 2016, we sent another email to all CAs that reiterated the need for strict adherence to standards and requirement for CAs to update their infrastructure as needed to maintain an unqualified audit. The specifically stated that issuance of internal name certificates and SHA1 certificates is strictly forbidden. Nets Norway, Vodafone, and Siemens all received a copy of this email.
As all the sub CAs should have been aware of the requirements in 2015, were reminded this year, and had audits of their infrastructure, we are very disappointed by the recently discovered SHA-1 issuance. We've contacted each of the sub CAs asking for an explanation on what happened and why their infrastructure wasn't sufficient to prevent SHA1 issuance.
Of the SHA1 cert issuers, Vodafone is the only sub CA that responded by providing a timeline for compliance, information about how they are migrating to new CA (which we already knew), and a plan going forward to undergo an audit and make sure technical constraints are active to prevent additional SHA1 certificates. Siemens replied that they are revoking the SHA1 certificates, that issuance was a mistake, and that they are taking action to prevent additional mis-issuance. However, the specifics of their plan are vague (other than providing operational training to prevent reoccurrence). For both Vodafone and Siemens, this is their first offense in mis-issuing a SHA1 certificate, and we'd ask for leniency. We do recognize that this is a serious concern and can revoke the issuing CAs if the action is decided necessary. For full disclosure, Siemens is transitioning away from the Verizon root certificate to another CA. We are only maintained the validity of their cross-sign in a good faith effort to help them complete the transition. We were planning to revoke the issuing CAs early next year (January 5th) once the transition is completed.
The final CA is Nets Norway. Unlike the other two issuing CAs, Nets Norway issued a SHA1 certificate earlier this year. Although Nets Norway promptly revoked the certificate and provided verbal assurances that SHA1 issuance would be restricted, the company obviously failed to take adequate measures. We informed Nets Norway that we are revoking their issuing CA later this month. We haven't revoked them yet because we wanted to complete the incident report first and allow public comment before finalizing the decision.
Our investigation of Verizon's, Postecom's, and Telecom Italia's issuance of a SHA1 certificate is ongoing. As mentioned above, Postecom is scheduled for revocation. Our plan for now is to keep the current revocation schedule for Postecom as the SHA1 issuance occurred twice during January. We haven't formed a plan for Verizon or Telecom Italia yet and are waiting to hear back from their representatives. Verizon issued a single certificate back in January. Telecom Italia issued three in early January and February. Each of these incidents were only recently discovered by DigCert. We've since added an active monitor to crt.sh to alert our compliance team if a SHA1 certificate issues.
Conclusion
Hopefully this helps explain the status of the Verizon transition and the recent SHA1 incidents. We are still collecting information from the three issuing sub CAs about what happened, but I hope this is enough to provide transparency and make a decision on how to proceed.
Despite the difficulties in bringing these customers into compliance, we still think the Verizon transaction was a good move from a compliance perspective. Helping these sub CAs identify problems and improve their processes has been an enlightening experience and given us insight on some of the difficulties other CAs may face in complying with the BRs. The process has been interesting exercise in helping others make remediation plans and trying to accelerate what feels like a slow-moving project. Despite the long nights, headaches, and frustrations, I think we've been successful in our original goal of improving the security ecosystem. I'm also very pleased that the end of the transition is almost here!
We appreciate your feedback and look forward to your comments.
Sincerely,
Jeremy
Han Yuwei
Nov 3, 2016, 8:13:58 PM11/3/16
to mozilla-dev-s...@lists.mozilla.org
在 2016年11月4日星期五 UTC+8上午3:52:23，Jeremy Rowley写道：
So did sub CAs have their dedicated CA team? And did Digicert supervise these sub CAs during the daily operation or 100% trust them doing well since they have WebTrust audit?
Peter Bowen
Nov 3, 2016, 10:54:26 PM11/3/16
to Jeremy Rowley, mozilla-dev-s...@lists.mozilla.org
On Thu, Nov 3, 2016 at 11:28 AM, Jeremy Rowley
<jeremy...@digicert.com> 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,
<jeremy...@digicert.com> 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.
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.
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.
> 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.
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.
How many of these are operated by DigiCert and how many are operated
by unaffiliated third parties? Kathleen added a field I requested to
the required disclosures of "Management Assertions By", but I think
the intent got lost. I meant it to be the legal entity that operates
that CA, so the answer to this question would be clear, but most are
filled by the name of the individual signing the assertion, which
isn't all that useful.
> The seven companies listed below are responsible for the remaining unaudited
> sub CAs:
private key and control decisions on what certificates get issued by
the CA?
> 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 restricted domain names and IPv4 IP addresses, the CAs could still
> issue for the IPv6 space. Despite promptly replacing the certificates after
> discovering the gap, we haven't revoked the issuing CAs. Right now, ABB is
> actively working to transition its servers to the new, properly-constrained
> certificates. We expect the transition to complete by the end of December
> 2016. We are revoking the issuing CAs as the migration completes and expect
> all of the ABB non-compliant issuing CAs to be revoked on January 5th. No
> new certs are being issued from the faulty issuing CAs.
means. Do the partially-constrained and the new technically
constrained CA certificates have the same subject distinguished name,
subject public key info, and/or subject key identifiers or are all
three different?
> 2. Similar to ABB, Verizon created two technically constrained issuing
> CAs for Bechtel. Like ABB, Verizon failed to restrict IPv6 issuance for each
> of the issuing CAs. Bechtel is actively migrating the remaining 785
> certificates to properly constrained issuing CAs. The migration process will
> complete at the end of December, after which the non-conforming issuing CAs
> will be revoked. They are included in our January 5th revocation plan. This
> will also revoke the three issuing CAs created further down in the chain.
> 3. Dell also thought they were technically constrained. Similar to ABB
> and Bechtel, the restriction was inadequate. Fortunately, Dell isn't using
> the issuing CAs and doesn't require migration. We've previously revoked four
> issuing certificates (Bug 1279066) but missed one during the process. We
> plan to immediately revoke the remaining issuing CA and all CAs subordinate
> to the issuing CA.
> 4. While Certipost is hosted by Verizon's internal infrastructure, the
> Verizon WebTrust audit letter did not specifically identify the Certipost
> CAs as audited. DigiCert has been in the process of revoking these CAs but
> there is some confusion about the effects of the revocation. Apparently the
> certificates are used for air traffic control in Europe and there is a fear
> that revoking the intermediate may cause planes to fall out of the sky.
> After trying to sort out this mess and giving Certipost time to transition,
> we've decided to revoke the issuing certificates the last week of November.
> We believe there are over 400 outstanding certificates that will be
> affected.
DigiCert now hosts this or did Verizon retain some CA infrastructure?
Either way, what control does Certipost have over the CA private key?
Assuming Verizon still controls the key, why is it not in their audit
reports?
> 5. Postecom refused an audit and decided to exit operation of a CA. We
> have not yet revoked their issuing CAs in order to give them time to migrate
> to a different CA infrastructure. They asked that we keep the issuing CAs
> active until December 31, 2016 to complete the migration. Although they have
> worked on migrating certs, Postecom still has 1185 certificates to migrate
> in the next two months. The issuing CAs are scheduled for revocation on
> January 5th.
still signing certificates using these CA private keys or are they in
a CRL/OCSP-only mode?
> 6. Vodafone completed a Webtrust audit this year. Unfortunately, we
> found out that the audit has qualifications. The audit report hasn't issued
> yet but should later in November.
criteria sets)?
> Once the audit report issues, we will
> provide a copy of the report for evaluation. We've been told that the
> qualifications are related to the network security guidelines. They probably
> also include the SHA1 issuance, although we haven't been told that directly.
would not be unique in ending up with a qualified audit due to the
network security guidelines. However the scope of non-compliance
could be much greater than that of other non-compliant CAs.
> Vodafone is currently designing and building a new CA infrastructure that
> will house all of their operations. To ensure compliance, we are requiring
> the new infrastructure to undergo a point-in-time audit in December. We are
> also requiring a full audit on their issuance processes at the start of next
> year. A full, non-qualified audit report is expected by March 31, 2016.
period of time report is 60 days; assuming they start operation on
December 1, the earliest end of period would be January 31, but I
suspect it will be later than that. I would suggest that they follow
the rules as if they were a brand new CA and get a period of time
audit that has a period of at least 60 days and ends within 90 days of
issuing their first public certificate. They then have 90 days to
publish the report.
> Although this is well past the compliance date, we are sympathetic to
> Vodafone as they have been actively working towards compliance. They also
> have 4,580 public facing SSL certs makes revocation tricky. They issue a lot
> of client certificates from these sub CAs where revocation could have a
> potentially devastating effect on telecommunications. Because of the large
> impact of revocation and how hard Vodafone is working to migrate, we'd like
> permission for them to comply by March 31, 2017, assuming serious issues are
> not uncovered by the audit report and that the December and January audits
> pass unqualified.
CA infrastructure", isn't clear how this helps their current CAs. Are
they still signing new certificates with their current infrastructure?
> 7. The Belgium government is our biggest challenge [...]
> Verizon has represented that the issuing CAs are hosted in the Verizon
> infrastructure and are potentially covered by the Verizon audit. 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. 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.
When you say "Verizon infrastructure", does this mean DigiCert now
> infrastructure and are potentially covered by the Verizon audit. 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. 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.
hosts this or did Verizon retain some CA infrastructure? Either way,
what control does the Belgium goverment have over the CA private keys?
> The final CA is Nets Norway. Unlike the other two issuing CAs, Nets Norway
> issued a SHA1 certificate earlier this year. Although Nets Norway promptly
> revoked the certificate and provided verbal assurances that SHA1 issuance
> would be restricted, the company obviously failed to take adequate measures.
> We informed Nets Norway that we are revoking their issuing CA later this
> month. We haven't revoked them yet because we wanted to complete the
> incident report first and allow public comment before finalizing the
> decision.
> Our investigation of Verizon's, Postecom's, and Telecom Italia's issuance of
> a SHA1 certificate is ongoing. As mentioned above, Postecom is scheduled for
> revocation. Our plan for now is to keep the current revocation schedule for
> Postecom as the SHA1 issuance occurred twice during January. We haven't
> formed a plan for Verizon or Telecom Italia yet and are waiting to hear back
> from their representatives. Verizon issued a single certificate back in
> January. Telecom Italia issued three in early January and February. Each of
> these incidents were only recently discovered by DigCert. We've since added
> an active monitor to crt.sh to alert our compliance team if a SHA1
> certificate issues.
either to public logs or logs readable only by DigiCert in order to
help assure compliance?
> Despite the difficulties in bringing these customers into compliance, we
> still think the Verizon transaction was a good move from a compliance
> perspective. Helping these sub CAs identify problems and improve their
> processes has been an enlightening experience and given us insight on some
> of the difficulties other CAs may face in complying with the BRs.
thing learned that might be relevant to other policy discussions (such
as CT mandates).
Thanks,
Peter
Gervase Markham
Nov 4, 2016, 12:50:23 PM11/4/16
to mozilla-dev-s...@lists.mozilla.org
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
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
Jeremy Rowley
Nov 4, 2016, 3:37:07 PM11/4/16
to Peter Bowen, mozilla-dev-s...@lists.mozilla.org
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, 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?
[JR] Although we have done everything we can to find these CAs, I'm not honestly sure how anyone would ever know if all the issuing CA certificates were accurately identified. We've looked through issuing records and are monitoring the CT logs, crt.sh, censys.io, as well as our own web crawler to see if any turn up. Our and Google's CT logs are how we originally identified may of the 200 issuing CAs.
> 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"?
[JR] The brand name assigned by Verizon to their external cross-signing program.
How many of these are operated by DigiCert and how many are operated by unaffiliated third parties? Kathleen added a field I requested to the required disclosures of "Management Assertions By", but I think the intent got lost. I meant it to be the legal entity that operates that CA, so the answer to this question would be clear, but most are filled by the name of the individual signing the assertion, which isn't all that useful.
[JR] The number operated by unaffiliated third parties is quickly diminishing as CAs transfer into a hosted solution or to another provided. I think the field is unclear on what was supposed to be logged. The CAs covered by DigiCert's audit are hosted by DigiCert. Everything else is external, although several of them are hosted by Verizon.
> The seven companies listed below are responsible for the remaining
> unaudited sub CAs:
To be clear, when you say "responsible", do you mean they hold the private key and control decisions on what certificates get issued by the CA?
[JR] Yes. They are external sub CAs where the keys and validation is controlled by the company named in the certificate. The easiest way to identify which issuing CAs are controlled by DigiCert and which are external is with the Mozilla Salesforce list. Any CAs we operate are covered by our audit.
> 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 restricted domain names and IPv4 IP
> addresses, the CAs could still issue for the IPv6 space. Despite
> promptly replacing the certificates after discovering the gap, we
> haven't revoked the issuing CAs. Right now, ABB is actively working to
> transition its servers to the new, properly-constrained certificates.
> We expect the transition to complete by the end of December 2016. We
> are revoking the issuing CAs as the migration completes and expect all
> of the ABB non-compliant issuing CAs to be revoked on January 5th. No new certs are being issued from the faulty issuing CAs.
When you say you "replaced the certificates" it is not clear what this means. Do the partially-constrained and the new technically constrained CA certificates have the same subject distinguished name, subject public key info, and/or subject key identifiers or are all three different?
[JR] Different keys but same subject info. We've essentially created new issuing CAs and are revoking the ones created by Verizon.
> 2. Similar to ABB, Verizon created two technically constrained issuing
> CAs for Bechtel. Like ABB, Verizon failed to restrict IPv6 issuance
> for each of the issuing CAs. Bechtel is actively migrating the
> remaining 785 certificates to properly constrained issuing CAs. The
> migration process will complete at the end of December, after which
> the non-conforming issuing CAs will be revoked. They are included in
> our January 5th revocation plan. This will also revoke the three issuing CAs created further down in the chain.
Same question as for ABB.
[JR] Same answer.
> 3. Dell also thought they were technically constrained. Similar to ABB
> and Bechtel, the restriction was inadequate. Fortunately, Dell isn't
> using the issuing CAs and doesn't require migration. We've previously
> revoked four issuing certificates (Bug 1279066) but missed one during
> the process. We plan to immediately revoke the remaining issuing CA
> and all CAs subordinate to the issuing CA.
This seems very straight forward. No questions.
> 4. While Certipost is hosted by Verizon's internal infrastructure, the
> Verizon WebTrust audit letter did not specifically identify the
> Certipost CAs as audited. DigiCert has been in the process of revoking
> these CAs but there is some confusion about the effects of the
> revocation. Apparently the certificates are used for air traffic
> control in Europe and there is a fear that revoking the intermediate may cause planes to fall out of the sky.
> After trying to sort out this mess and giving Certipost time to
> transition, we've decided to revoke the issuing certificates the last week of November.
> We believe there are over 400 outstanding certificates that will be
> affected.
When you say "Verizon's internal infrastructure", does this mean DigiCert now hosts this or did Verizon retain some CA infrastructure?
Either way, what control does Certipost have over the CA private key?
Assuming Verizon still controls the key, why is it not in their audit reports?
[JR] Verizon still has a CA infrastructure that hosts issuing CAs for their customers that refused to migrate or are still migrating to DigiCert or another CA. The infrastructure also hosts keys and certs Verizon uses internally for certificates. We took control of the root certificates and have spent the last year transitioning CAs to DigiCert's hosted CA solution or bringing them into compliance with the BRs and root program policies. The certificates hosted by Verizon are being revoked as the migrations complete. All issuing CAs hosted by Verizon are theoretically covered by the Verizon audits. However, Verizon's auditors still use the "old school" style audit reports where only the roots are listed. Verizon has had another audit, and we've asked that the new audit report list each issuing CA individually so we can better identify which are hosted by Verizon and which are operated externally.
> 5. Postecom refused an audit and decided to exit operation of a CA. We
> have not yet revoked their issuing CAs in order to give them time to
> migrate to a different CA infrastructure. They asked that we keep the
> issuing CAs active until December 31, 2016 to complete the migration.
> Although they have worked on migrating certs, Postecom still has 1185
> certificates to migrate in the next two months. The issuing CAs are
> scheduled for revocation on January 5th.
When you say "keep the issuing CAs active", does this mean they are still signing certificates using these CA private keys or are they in a CRL/OCSP-only mode?
[JR] Supposedly in CRL/OCSP mode, but we know they have issued a few certificates this year. Of course, all certs will cease functioning on Jan 5th when we revoke the issuing CA.
> 6. Vodafone completed a Webtrust audit this year. Unfortunately, we
> found out that the audit has qualifications. The audit report hasn't
> issued yet but should later in November.
Has Vodafone ever previously had a WebTrust audit (using any of the criteria sets)?
[JR] We don't know. The documentation is very bad.. I'm not even sure Vodafone was told they needed an audit until we took over. The requirements caught them by surprise.
> Once the audit report issues, we will
> provide a copy of the report for evaluation. We've been told that the
> qualifications are related to the network security guidelines. They
> probably also include the SHA1 issuance, although we haven't been told that directly.
As discussed at the CA/Browser Forum meeting a few weeks ago, they would not be unique in ending up with a qualified audit due to the network security guidelines. However the scope of non-compliance could be much greater than that of other non-compliant CAs.
[JR] Agreed. We are awaiting the audit report to evaluate. We don't know the exact qualifications yet and plan to adjust the plan based on what is revealed in the report.
> Vodafone is currently designing and building a new CA infrastructure
> that will house all of their operations. To ensure compliance, we are
> requiring the new infrastructure to undergo a point-in-time audit in
> December. We are also requiring a full audit on their issuance
> processes at the start of next year. A full, non-qualified audit report is expected by March 31, 2016.
This seems a little aggressive. The minimum period for a WebTrust period of time report is 60 days; assuming they start operation on December 1, the earliest end of period would be January 31, but I suspect it will be later than that. I would suggest that they follow the rules as if they were a brand new CA and get a period of time audit that has a period of at least 60 days and ends within 90 days of issuing their first public certificate. They then have 90 days to publish the report.
[JR] Yes. We wanted a very aggressive plan as Vodafone is currently out of compliance. However, we're happy to give them more leeway if everyone agrees. Vodafone has been very responsive and easy to work with. Unfortunately, Vodafone received little to no information about the CAB Forum requirements prior to the acquisition and were caught by surprise when we told them they needed a BR and network security guideline audit. I think they had a standard audit prior to that, but there isn't enough documentation to tell. Vodafone also recently overhauled their CA staff and infrastructure, which has delayed compliance slightly.
> Although this is well past the compliance date, we are sympathetic to
> Vodafone as they have been actively working towards compliance. They
> also have 4,580 public facing SSL certs makes revocation tricky. They
> issue a lot of client certificates from these sub CAs where revocation
> could have a potentially devastating effect on telecommunications.
> Because of the large impact of revocation and how hard Vodafone is
> working to migrate, we'd like permission for them to comply by March
> 31, 2017, assuming serious issues are not uncovered by the audit
> report and that the December and January audits pass unqualified.
Given that the point in time audit and subsequent audit are for "new CA infrastructure", isn't clear how this helps their current CAs. Are they still signing new certificates with their current infrastructure?
[JR] Yes, Vodafone is still issuing certificates. They plan to transfer the entire operations over to the new infrastructure later this year. Although the point in time audit is for new CAs, we thought the audit would be appropriate because 1) this is a new infrastructure and, although existing certificates are included, the operations are essentially a new CA with a new team 2) the audit will show Vodafone's progress towards compliance, and 3) the audit will identify Vodafone's progress in remediating any qualifications in their existing audit. We do feel Vodafone deserves some lee-way considering they were unaware of the requirements until after the acquisition.
> 7. The Belgium government is our biggest challenge [...]
> Verizon has represented that the issuing CAs are hosted in the Verizon
> infrastructure and are potentially covered by the Verizon audit. 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. 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.
When you say "Verizon infrastructure", does this mean DigiCert now hosts this or did Verizon retain some CA infrastructure? Either way, what control does the Belgium goverment have over the CA private keys?
[JR] Verizon retains their own infrastructure that hosts the Verizon issuing CAs. DigiCert took over the roots in an audited and documented process. We don't know if Belgium controls their issuing CA's private keys or if the keys are hosted in Verizon's infrastructure. We've been told that Verizon has these keys but have yet to receive evidence of this arrangement. The continued confusion about where the issuing CAs are hosted is why we want to revoke the Belgium root on December 1, 2016 if a full audit covering the issuing CAs isn't provided.
> The final CA is Nets Norway. Unlike the other two issuing CAs, Nets
> Norway issued a SHA1 certificate earlier this year. Although Nets
> Norway promptly revoked the certificate and provided verbal assurances
> that SHA1 issuance would be restricted, the company obviously failed to take adequate measures.
> We informed Nets Norway that we are revoking their issuing CA later
> this month. We haven't revoked them yet because we wanted to complete
> the incident report first and allow public comment before finalizing
> the decision.
This seems like a reasonable plan for Nets Norway.
[JR] Thanks. We're thinking the last week of November to give them time to migrate. If any additional non-compliances are discovered, we plan to revoke immediately.
> Our investigation of Verizon's, Postecom's, and Telecom Italia's
> issuance of a SHA1 certificate is ongoing. As mentioned above,
> Postecom is scheduled for revocation. Our plan for now is to keep the
> current revocation schedule for Postecom as the SHA1 issuance occurred
> twice during January. We haven't formed a plan for Verizon or Telecom
> Italia yet and are waiting to hear back from their representatives.
> Verizon issued a single certificate back in January. Telecom Italia
> issued three in early January and February. Each of these incidents
> were only recently discovered by DigCert. We've since added an active
> monitor to crt.sh to alert our compliance team if a SHA1 certificate issues.
Has DigiCert considered requiring CT logging for subordinate CAs, either to public logs or logs readable only by DigiCert in order to help assure compliance?
[JR] Yes. That is being discussed right now. We are trying to figure out the best way to do that. Some of these customers are using CA software which does not currently support CT logging and would need to have a solution for this in the near term.
> Despite the difficulties in bringing these customers into compliance,
> we still think the Verizon transaction was a good move from a
> compliance perspective. Helping these sub CAs identify problems and
> improve their processes has been an enlightening experience and given
> us insight on some of the difficulties other CAs may face in complying with the BRs.
Please share any feedback on how the BRs can be improved and also any thing learned that might be relevant to other policy discussions (such as CT mandates).
[JR] Thanks Peter. We really like the BRs and network security guidelines, even more so after this exercise. Certificates are not the primary business for most of these sub CAs. As such, the companies don't closely follow the risks and industry discussions. The BRs and network security guidelines give us a good standard that CAs can use as a measuring stick for compliance.
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.
Sincerely,
Jeremy
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 parties? Kathleen added a field I requested to the required disclosures of "Management Assertions By", but I think the intent got lost. I meant it to be the legal entity that operates that CA, so the answer to this question would be clear, but most are filled by the name of the individual signing the assertion, which isn't all that useful.
> The seven companies listed below are responsible for the remaining
> unaudited sub CAs:
To be clear, when you say "responsible", do you mean they hold the private key and control decisions on what certificates get issued by the CA?
> 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 restricted domain names and IPv4 IP
> addresses, the CAs could still issue for the IPv6 space. Despite
> promptly replacing the certificates after discovering the gap, we
> haven't revoked the issuing CAs. Right now, ABB is actively working to
> transition its servers to the new, properly-constrained certificates.
> We expect the transition to complete by the end of December 2016. We
> are revoking the issuing CAs as the migration completes and expect all
> of the ABB non-compliant issuing CAs to be revoked on January 5th. No new certs are being issued from the faulty issuing CAs.
When you say you "replaced the certificates" it is not clear what this means. Do the partially-constrained and the new technically constrained CA certificates have the same subject distinguished name, subject public key info, and/or subject key identifiers or are all three different?
> 2. Similar to ABB, Verizon created two technically constrained issuing
> CAs for Bechtel. Like ABB, Verizon failed to restrict IPv6 issuance
> for each of the issuing CAs. Bechtel is actively migrating the
> remaining 785 certificates to properly constrained issuing CAs. The
> migration process will complete at the end of December, after which
> the non-conforming issuing CAs will be revoked. They are included in
> our January 5th revocation plan. This will also revoke the three issuing CAs created further down in the chain.
Same question as for ABB.
> 3. Dell also thought they were technically constrained. Similar to ABB
> and Bechtel, the restriction was inadequate. Fortunately, Dell isn't
> using the issuing CAs and doesn't require migration. We've previously
> revoked four issuing certificates (Bug 1279066) but missed one during
> the process. We plan to immediately revoke the remaining issuing CA
> and all CAs subordinate to the issuing CA.
This seems very straight forward. No questions.
> 4. While Certipost is hosted by Verizon's internal infrastructure, the
> Verizon WebTrust audit letter did not specifically identify the
> Certipost CAs as audited. DigiCert has been in the process of revoking
> these CAs but there is some confusion about the effects of the
> revocation. Apparently the certificates are used for air traffic
> control in Europe and there is a fear that revoking the intermediate may cause planes to fall out of the sky.
> After trying to sort out this mess and giving Certipost time to
> transition, we've decided to revoke the issuing certificates the last week of November.
> We believe there are over 400 outstanding certificates that will be
> affected.
When you say "Verizon's internal infrastructure", does this mean DigiCert now hosts this or did Verizon retain some CA infrastructure?
Either way, what control does Certipost have over the CA private key?
Assuming Verizon still controls the key, why is it not in their audit reports?
> 5. Postecom refused an audit and decided to exit operation of a CA. We
> have not yet revoked their issuing CAs in order to give them time to
> migrate to a different CA infrastructure. They asked that we keep the
> issuing CAs active until December 31, 2016 to complete the migration.
> Although they have worked on migrating certs, Postecom still has 1185
> certificates to migrate in the next two months. The issuing CAs are
> scheduled for revocation on January 5th.
When you say "keep the issuing CAs active", does this mean they are still signing certificates using these CA private keys or are they in a CRL/OCSP-only mode?
> 6. Vodafone completed a Webtrust audit this year. Unfortunately, we
> found out that the audit has qualifications. The audit report hasn't
> issued yet but should later in November.
Has Vodafone ever previously had a WebTrust audit (using any of the criteria sets)?
> Once the audit report issues, we will
> provide a copy of the report for evaluation. We've been told that the
> qualifications are related to the network security guidelines. They
> probably also include the SHA1 issuance, although we haven't been told that directly.
As discussed at the CA/Browser Forum meeting a few weeks ago, they would not be unique in ending up with a qualified audit due to the network security guidelines. However the scope of non-compliance could be much greater than that of other non-compliant CAs.
> Vodafone is currently designing and building a new CA infrastructure
> that will house all of their operations. To ensure compliance, we are
> requiring the new infrastructure to undergo a point-in-time audit in
> December. We are also requiring a full audit on their issuance
> processes at the start of next year. A full, non-qualified audit report is expected by March 31, 2016.
This seems a little aggressive. The minimum period for a WebTrust period of time report is 60 days; assuming they start operation on December 1, the earliest end of period would be January 31, but I suspect it will be later than that. I would suggest that they follow the rules as if they were a brand new CA and get a period of time audit that has a period of at least 60 days and ends within 90 days of issuing their first public certificate. They then have 90 days to publish the report.
> Although this is well past the compliance date, we are sympathetic to
> Vodafone as they have been actively working towards compliance. They
> also have 4,580 public facing SSL certs makes revocation tricky. They
> issue a lot of client certificates from these sub CAs where revocation
> could have a potentially devastating effect on telecommunications.
> Because of the large impact of revocation and how hard Vodafone is
> working to migrate, we'd like permission for them to comply by March
> 31, 2017, assuming serious issues are not uncovered by the audit
> report and that the December and January audits pass unqualified.
Given that the point in time audit and subsequent audit are for "new CA infrastructure", isn't clear how this helps their current CAs. Are they still signing new certificates with their current infrastructure?
> 7. The Belgium government is our biggest challenge [...]
> Verizon has represented that the issuing CAs are hosted in the Verizon
> infrastructure and are potentially covered by the Verizon audit. 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. 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.
When you say "Verizon infrastructure", does this mean DigiCert now hosts this or did Verizon retain some CA infrastructure? Either way, what control does the Belgium goverment have over the CA private keys?
> The final CA is Nets Norway. Unlike the other two issuing CAs, Nets
> Norway issued a SHA1 certificate earlier this year. Although Nets
> Norway promptly revoked the certificate and provided verbal assurances
> that SHA1 issuance would be restricted, the company obviously failed to take adequate measures.
> We informed Nets Norway that we are revoking their issuing CA later
> this month. We haven't revoked them yet because we wanted to complete
> the incident report first and allow public comment before finalizing
> the decision.
This seems like a reasonable plan for Nets Norway.
> Our investigation of Verizon's, Postecom's, and Telecom Italia's
> issuance of a SHA1 certificate is ongoing. As mentioned above,
> Postecom is scheduled for revocation. Our plan for now is to keep the
> current revocation schedule for Postecom as the SHA1 issuance occurred
> twice during January. We haven't formed a plan for Verizon or Telecom
> Italia yet and are waiting to hear back from their representatives.
> Verizon issued a single certificate back in January. Telecom Italia
> issued three in early January and February. Each of these incidents
> were only recently discovered by DigCert. We've since added an active
> monitor to crt.sh to alert our compliance team if a SHA1 certificate issues.
Has DigiCert considered requiring CT logging for subordinate CAs, either to public logs or logs readable only by DigiCert in order to help assure compliance?
> Despite the difficulties in bringing these customers into compliance,
> we still think the Verizon transaction was a good move from a
> compliance perspective. Helping these sub CAs identify problems and
> improve their processes has been an enlightening experience and given
> us insight on some of the difficulties other CAs may face in complying with the BRs.
Please share any feedback on how the BRs can be improved and also any thing learned that might be relevant to other policy discussions (such as CT mandates).
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.
Sincerely,
Jeremy
Ben Wilson
Nov 4, 2016, 3:48:27 PM11/4/16
to Jeremy Rowley, Peter Bowen, mozilla-dev-s...@lists.mozilla.org
The Belgian CAs are publicly disclosed at http://certs.eid.belgium.be/.
(I'm in the process of inputting them into the Mozilla database.)
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
(I'm in the process of inputting them into the Mozilla database.)
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Nick Lamb
Nov 5, 2016, 5:50:18 AM11/5/16
to mozilla-dev-s...@lists.mozilla.org
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.
> 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.
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.
Dimitris Zacharopoulos
Nov 5, 2016, 9:23:05 AM11/5/16
to Nick Lamb, mozilla-dev-s...@lists.mozilla.org
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 <tiala...@gmail.com> wrote:
>
>> On Friday, 4 November 2016 19:37:07 UTC, Jeremy Rowley wrote:
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 <tiala...@gmail.com> 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.
>
> 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.
Rob Stradling
Jan 9, 2017, 11:28:57 AM1/9/17
to Jeremy Rowley, mozilla-dev-s...@lists.mozilla.org
On 03/11/16 19:34, Jeremy Rowley wrote:
<snip>
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
<snip>
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.
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.
(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
Jeremy Rowley
Jan 9, 2017, 11:35:39 AM1/9/17
to Rob Stradling, mozilla-dev-s...@lists.mozilla.org
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.st...@comodo.com]
Sent: Monday, January 9, 2017 9:28 AM
To: Jeremy Rowley <jeremy...@digicert.com>;
mozilla-dev-s...@lists.mozilla.org
Subject: Re: Update on transition of the Verizon roots and issuance of SHA1
certificates
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.st...@comodo.com]
Sent: Monday, January 9, 2017 9:28 AM
To: Jeremy Rowley <jeremy...@digicert.com>;
mozilla-dev-s...@lists.mozilla.org
Subject: Re: Update on transition of the Verizon roots and issuance of SHA1
certificates
Kurt Roeckx
Jan 9, 2017, 11:54:53 AM1/9/17
to mozilla-dev-s...@lists.mozilla.org
On 2017-01-09 17:28, Rob Stradling wrote:
> On 03/11/16 19:34, Jeremy Rowley wrote:
> <snip>
>
> 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:
> On 03/11/16 19:34, Jeremy Rowley wrote:
> <snip>
>
> 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.
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
Jeremy Rowley
Jan 9, 2017, 12:02:57 PM1/9/17
to Kurt Roeckx, mozilla-dev-s...@lists.mozilla.org
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=digice...@lists.mozilla
.org] On Behalf Of Kurt Roeckx
Sent: Monday, January 9, 2017 9:54 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Update on transition of the Verizon roots and issuance of SHA1
certificates
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=digice...@lists.mozilla
.org] On Behalf Of Kurt Roeckx
Sent: Monday, January 9, 2017 9:54 AM
To: mozilla-dev-s...@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:
> <snip>
>
> 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.
> <snip>
>
> 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
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
Rob Stradling
Jan 9, 2017, 12:03:13 PM1/9/17
to Jeremy Rowley, mozilla-dev-s...@lists.mozilla.org
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.
> 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.
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?
Jeremy Rowley
Jan 9, 2017, 12:13:30 PM1/9/17
to Rob Stradling, mozilla-dev-s...@lists.mozilla.org
It probably should not be same as parent. Ben will update it.
-----Original Message-----
From: Rob Stradling [mailto:rob.st...@comodo.com]
Sent: Monday, January 9, 2017 10:02 AM
To: Jeremy Rowley <jeremy...@digicert.com>;
-----Original Message-----
From: Rob Stradling [mailto:rob.st...@comodo.com]
Sent: Monday, January 9, 2017 10:02 AM
To: Jeremy Rowley <jeremy...@digicert.com>;
mozilla-dev-s...@lists.mozilla.org
Subject: Re: Update on transition of the Verizon roots and issuance of SHA1
certificates
Subject: Re: Update on transition of the Verizon roots and issuance of SHA1
certificates
Ben Wilson
Jan 9, 2017, 12:19:23 PM1/9/17
to rob.st...@comodo.com, Jeremy Rowley, mozilla-dev-s...@lists.mozilla.org
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=digice...@lists.mozilla.org] On Behalf Of Rob Stradling
Sent: Monday, January 9, 2017 10:02 AM
To: Jeremy Rowley <jeremy...@digicert.com>; mozilla-dev-s...@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
Ben Wilson, JD, CISA, CISSP
DigiCert VP Compliance
-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On Behalf Of Rob Stradling
Sent: Monday, January 9, 2017 10:02 AM
To: Jeremy Rowley <jeremy...@digicert.com>; mozilla-dev-s...@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
Erwann Abalea
Jan 10, 2017, 9:49:06 AM1/10/17
to mozilla-dev-s...@lists.mozilla.org
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.
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.
> 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.
0 new messages