I'm not sure exactly what you are asking. These sub CAs are cross-signs with 
other entities. DigiCert controls the root, but not the issuing CAs. Except for 
the ones I listed, they are all WebTrust or ETSI audited so we trust them. They 
are primarily government, large corporations, and other CAs. Most are 
transferring away from DigiCert or moving to a solution where we host the 
private keys and certificates. There are some who insist on operating their own 
root and cross-sign for ubiquity. 

-----Original Message-----
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert....@lists.mozilla.org]
 On Behalf Of Han Yuwei
Sent: Thursday, November 3, 2016 6:14 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Update on transition of the Verizon roots and issuance of SHA1 
certificates

在 2016年11月4日星期五 UTC+8上午3:52:23,Jeremy Rowley写道:
> Resent without a signature....
> 
> 
> 
> Hi everyone,
> 
> 
> 
> This email is intended to gather public and browser feedback on how we are 
> handling the transitioning Verizon's customers to DigiCert and share with 
> everyone the plan for when all non-DigiCert hosted sub CAs will be fully 
> compliant with the BRs and network security guidelines. Primarily, this 
> letter addresses when all issuing CAs previously held by Verizon will be 
> covered by an unqualified audit and how we are responding to the sub CAs that 
> issued SHA1 certificates. We are looking forward to the browser and public 
> feedback on how to handle the non-compliant cross-signs and insight on how 
> the public views our transition progress and planned completion dates.
> 
> 
> 
> Background
> 
> Prior to presenting the plan for remediation, I thought I'd share a bit about 
> our progress with migrating Verizon customers.  About a year ago in July, 
> DigiCert closed an agreement with Verizon where DigiCert took ownership of 
> three publicly-trusted Verizon root certificates. These certificates are the 
> Verizon Global Root CA, the Baltimore CyberTrust Root CA, and the Verizon 
> Root CA. There were many reasons the acquisition made sense, including 
> acquisition of a root that had cross-signed DigiCert for many years. The 
> ubiquity of the Verizon roots is wide-spread, which meant a lot of CAs like 
> to cross-sign with them. Another significant reason for the acquisition was 
> an attempt to improve the CA industry. After watching the issuance of 
> wildcard EV certs, non-compliant subordinate CAs, and certs with poor 
> profiles, we made a conscious decision to purchase these roots with the 
> intention of migrating them to more complaint system. We felt that helping 
> these CAs get to the point of regular audits and best practices would raise 
> the quality of the entire industry.
> 
> 
> 
> Prior to the acquisition, we were made aware of several potential 
> non-compliances by Verizon's customers. We worked closely with Verizon to 
> clean up many of the Sub CAs, including revoking CAs that would never be 
> compliant with the requirements and attempting to technically constrain 
> others.  Sub CAs were revoked because they either didn't have an audit, were 
> unresponsive to communication, or couldn't control their issuance. Verizon 
> was a great partner and took a very proactive approach in removing CAs that 
> were not actively working towards compliance. Unfortunately, the age of the 
> roots and large number of cross-signs led to a lot of missing paperwork and 
> certain issues in identifying which CAs were covered by audits. Prior to 
> closing we believed there were approximately five technically constrained sub 
> CAs and around 20 unconstrained sub CAs. Turns out there were actually more 
> than 200, each with various levels of compliance. Most of these Sub CAs 
> operated under the Baltimore Cybertrust root, which was created in 2000.
> 
> 
> 
> To their credit, Verizon revoked 48 of the issuing CAs prior to DigiCert's 
> acquisition of the roots. Unfortunately, this left around 150 for our small 
> team to work through. Although the endeavor was daunting, Ben Wilson and 
> others worked to gather audit reports, email customers about compliance 
> dates, monitor certificates issued, and revoke non-compliant customers. 
> Verizon was very good at assisting us in these efforts. This information is 
> now recorded in the Mozilla database and continuously updated as the 
> information changes.
> 
> 
> 
> Transition Process
> 
> After our operational acquisition of the roots (which occurred the last part 
> of September, 2015), we identified 15 expired issuing CAs, 70 revoked sub 
> CAs, 131 audited sub CAs, and 36 where the status was unknown. Since then, 
> we've revoked 25 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

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to