Hi everyone,
We’re still progressing towards close and transition. One of the items we are heavily evaluating is the root structure and cross-signings post close. Although the plan is still being finalized, I wanted to provide a community update on the current proposal. Right now, Mozilla post stated that they plan to deprecate Symantec roots for TLS by the end of 2018. We continue to work on a plan to transition all customers using the roots for TLS to another root, likely the DigiCert High Assurance root. We will not cross-sign any Symantec roots, however we will continue using those roots for code signing and client/email certs post close (non-TLS use cases). We also plan on using Symantec roots to cross-sign some of the DigiCert roots to provide ubiquity in non-Mozilla systems and processes. However, this sign will only provide one-way trust, with the ultimate chain in Mozilla being EE-> Issuing CA -> DigiCert root in all cases. DigiCert currently has four operational roots in the Mozilla trust store: Baltimore, Global, Assured ID, and High Assurance. The other roots are some permutation of these four roots that were established for future use cases/rollover (ECC vs. RSA). We already separate operations by Sub CA, with TLS, email, and code signing using different issuing CAs. As mentioned in my previous post, we plan on using multiple Sub CAs chained to the DigiCert roots to further control the population trusted by each Sub CA but have not decided on exact numbers. OV and EV will be limited by Alexa distribution and/or number of customers. DV isn’t readily identifiable by customer and will use a common sub CA. Root separation proves a difficult, yet achievable, task as there are only four operational roots: Baltimore, High Assurance, Global, and Assured ID. Global and High Assurance issue mostly OV/EV certs but do include code signing and client certificates. High Assurance is our EV root and used for both EV code signing certificates and TLS certs. Baltimore is our cross-signed root and used primarily by older Verizon customers. Assured ID is used mostly for code signing and client. However, Assured ID is also our FBCA root, meaning government-issued TLS certificates chain to it. Of course, all TLS certs are issued in accordance with the BRs regardless of root. Looking at the current customer base, our current plan is to issue EV (code and TLS) from High Assurance, OV (code and TLS) from Global. Assured ID will continue as our client certificate and government root. We plan to continue using Symantec roots for code signing and client. We’re still looking into this though. We’d love to separate out the roots more than this, but that’s not likely possible given the current root architecture. If there is a non-cross-signed Symantec root that the browsers are not planning to remove, we’d like to continue using the root to issue high volume DV and device certificates. If this is not possible and Mozilla is still planning on distrusting all Symantec roots, we’ll likely migrate DV certs to a Sub CA chained to the Baltimore root. Of course, this is only an initial proposal. We’ll revise as things progress and based on the community feedback. We appreciate your thoughts. Jeremy From: Peter Kurrasch [mailto:fhw...@gmail.com] Sent: Thursday, August 3, 2017 11:21 PM To: Jeremy Rowley <jeremy.row...@digicert.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: DigiCert-Symantec Announcement I agree with the high-level concepts, although I would probably like to add something about "being good stewards of technologies that play a critical role in the global economy." (Feel free to use your own words!) Regarding the current Mozilla/Google plans, I don't necessarily have a problem with them but I do think we should give ourselves permission to make adjustments (if needed) because the circumstances have changed since those plans were developed. Consider: * Because the acquisition is now in the picture, legal issues might impede progress in certain areas. The most notable example is the fact that DigiCert will have limited authority over Symantec until the deal actually closes. For example, what will happen in the period between Dec 1 and the closing (assuming it's after the first)? * Once the deal does close, personnel and management issues could present various challenges in meeting certain deadlines. For example, if subject matter experts decide to leave Symantec prior to the closing, how might that hinder DigiCert? * A lot of churn is about to be introduced in the global PKI. Times of chaos create moments of opportunity for those who wish to do bad things. Should something happen, corrections may be necessary which can impact delivery dates, and so on. Let me be clear that these are just hypothetical situations and rhetorical questions. I don't expect answers and my only intention is to get people to start thinking about these matters (if they haven't already begun). Hopefully this better explains where I was coming from in my initial reply. From: Jeremy Rowley Sent: Thursday, August 3, 2017 8:13 PM Hey Peter, I think the Mozilla and Google plans both stand as-is, although probably need an updated based on this announcement. I'm hoping that the high-level concepts remain unchanged: - Migrate to a new infrastructure - Audit the migration and performance to ensure compliance - Improve operational transparency so the community has assurances on what is happening. Jeremy This certainly shakes things up! I've had my concerns that Symantec's plan was complicated and risky, but now I'm wondering if this new path will be somewhat simpler--yet even more risky? I'm not suggesting we shouldn't take this path but I am hoping we make smart, well-thought-out decisions along the way. ...snip... * I think it's appropriate to re-think some of the deadlines, given that we're talking less about a carrots-and-sticks model and more of one based on smart decision-making, good risk management, and sticks.
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
