On Thu, Nov 3, 2016 at 11:28 AM, Jeremy Rowley <jeremy.row...@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, Thank you for addressing this non-compliance head on. While it probably would have been better to raise this when you became aware of it, it is good that DigiCert brought this to the group proactively rather than waiting for a discussion on "should we dump these roots". I have a bunch of questions, through out the document. First, a couple of questions about DigiCert itself. The press release at https://thomabravo.com/2015/10/22/thoma-bravo-completes-acquisition-of-majority-stake-in-digicert/ says that Thoma Bravo acquired a majority stake in DigiCert in October 2015. Looking at the current portfolio (https://thomabravo.com/portfolio/all/current/), I don't see any other CAs, but can you confirm that (a) they still own a majority & controlling share of DigiCert and (b) that Thoma Bravo does not own a majority or controlling share (directly or indirectly) of any other CA? What is the relationship between Cyber Secure Asia (https://www.cybersecureasia.com/about-cyber-secure-asia-csa/newsroom) and DigiCert? Are they a subsidiary, a subordinate CA, a reseller or something else? It is hard to tell, as they talk about DigiCert all over their site but also say something about being a subsidiary of CyberTrust Japan (which might be part of DigiCert?) > About a year ago in > July, DigiCert closed an agreement with Verizon where DigiCert took > ownership of three publicly-trusted Verizon root certificates. These > certificates are the Verizon Global Root CA, the Baltimore CyberTrust Root > CA, and the Verizon Root CA. According to https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport, DigiCert currently has 10 roots in the Mozilla trust anchor list. These include eight with "DigiCert Inc" in the organization name attribute, one with "Baltimore" in the organization name attribute, and one with "CyberTrust, Inc" in the organization name attribute. The removed CA report (https://mozillacaprogram.secure.force.com/CA/RemovedCACertificateReport) lists one root as belonging to DigiCert. This has "GTE Corporation" in the organization name attribute. You list three root certificates in your email. Which of the DigiCert certificates in the Mozilla root reports map to the three you list? You talk about taking ownership of three "root certificates". Did you also take ownership and control of all copies of the associated private keys? Did you take control of other CAs and private keys (e.g. subordinate CAs) or just the three listed above? > After watching the > issuance of wildcard EV certs, non-compliant subordinate CAs, and certs with > poor profiles, we made a conscious decision to purchase these roots with the > intention of migrating them to more complaint system. We felt that helping > these CAs get to the point of regular audits and best practices would raise > the quality of the entire industry. So would just revoking them. > Unfortunately, the age of the > roots and large number of cross-signs led to a lot of missing paperwork and > certain issues in identifying which CAs were covered by audits. Prior to > closing we believed there were approximately five technically constrained > sub CAs and around 20 unconstrained sub CAs. Turns out there were actually > more than 200, each with various levels of compliance. Most of these Sub CAs > operated under the Baltimore Cybertrust root, which was created in 2000. > To their credit, Verizon revoked 48 of the issuing CAs prior to DigiCert's > acquisition of the roots. Given this huge variance, how sure are you that you have identified all the CA certificates issued by these roots? Did all of the CA certificates include zero path length constraints or are there possibly whole trees of CAs out there that are unknown? > After our operational acquisition of the roots (which occurred the last part > of September, 2015), we identified 15 expired issuing CAs, 70 revoked sub > CAs, 131 audited sub CAs, and 36 where the status was unknown. Since then, > we've revoked 25 issuing CAs and assisted others with technical constraints, > exodus from the Omniroot cross-signing program, or obtaining audits. What is "Omniroot"? How many of these are operated by DigiCert and how many are operated by unaffiliated third 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). Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
