RE: DigiCert-Symantec Announcement
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 ; mozilla-dev-security-policy 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 thin
Re: BR compliance of legacy certs at root inclusion time
On Sun, Aug 20, 2017 at 3:44 PM, Peter Bowen wrote: > From the perspective of being "clean" from a given NSS version this, > makes sense. However the reality for most situations is there is > demand to support applications and devices with trust stores that have > not been updated for a while. This could be something as similar as > Firefox ESR or it could be a some device with an older trust store. > Assuming there is a need to have the same certificate chain work in > both scenarios, the TLS server may need to send a chain with multiple > root to root cross-certificates. > I'm not sure it's fair to say there needs to be the 'same' certificate chain working in both. The variety of trust stores already shows how that's not necessary today. Merely, one needs to have 'a' certificate chain. Perhaps I've missed a point you weren't stating, but I'm not sure why you would need root-to-root cross-certificates, as this proposal only applies to the roots included in Mozilla's store, and offers a transition path for those roots. > https://gist.github.com/pzb/cd10fbfffd7cb25bb57c38c3865f18f2 is just > the roots in each unique disconnected graph. Having the entries there > does not imply that all have cross-signed each other, rather than > there is a path from each pair of roots to a common node. For > example, Root A and Root B might each have a subordinate CA that have > each cross-certified the same, third subordinate. > I'm not sure if you're arguing that this is a desired config, or merely, a config that exists. I certainly would not be willing to suggest CAs have (effectively) managed their cross-certificates well, and it would seem as if some of these paths are reflective of business transitions/deals (and their expirations) rather than intrinsic needs of the Web PKI. As it sounds like you agree that the overall design is both sound and desirable, from a Web PKI perspective, perhaps you could clarify what you believe is a case not supported by this design. This would be useful to understanding what, if any, material consequence there would be of implementing this saner approach to root store management. > Considering we already see paths like: > > OU=Class 3 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US => > CN=VeriSign Class 3 Public Primary Certification Authority - G3,OU=(c) > 1999 VeriSign\, Inc. - For authorized use only,OU=VeriSign Trust > Network,O=VeriSign\, Inc.,C=US => > CN=VeriSign Class 3 Public Primary Certification Authority - G5,OU=(c) > 2006 VeriSign\, Inc. - For authorized use only,OU=VeriSign Trust > Network,O=VeriSign\, Inc.,C=US => > CN=VeriSign Universal Root Certification Authority,OU=(c) 2008 > VeriSign\, Inc. - For authorized use only,OU=VeriSign Trust > Network,O=VeriSign\, Inc.,C=US => > CN=Symantec Class 3 Extended Validation SHA256 SSL CA,OU=Symantec > Trust Network,O=Symantec Corporation,C=US * => > (End-Entity Certificate) > > I think we need to be careful when considering root rotations. > While a useful real world example, I think the cross-signing activities of several CAs (and one can examine Entrust for a similar issue, or the multiple paths StartCom previously did) are not necessarily designed with either interoperability or consideration of the ecosystem in mind. After all, this is the same set of activities that make it easy for 'forget' disclosure of critical intermediates. Rather, with appropriate advice, one can easily end up with a linear path, where the only 'cost' is paid by legacy systems that don't update, and the servers that need to support such legacy systems. As there is an inherent lifetime for how long something can be 'safely' connected to the Internet, this doesn't seem unreasonable to build upon. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: BR compliance of legacy certs at root inclusion time
On Fri, Aug 18, 2017 at 8:47 AM, Ryan Sleevi via dev-security-policy wrote: > On Fri, Aug 18, 2017 at 11:02 AM, Gervase Markham via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Sometimes, CAs apply for inclusion with new, clean roots. Other times, >> CAs apply to include roots which already have a history of issuance. The >> previous certs issued by that CA aren't always all BR-compliant. Which >> is in one sense understandable, because up to this point the CA has not >> been bound by the BRs. Heck, the CA may never even have heard of the BRs >> until they come to apply - although this seems less likely than it would >> once have been. >> >> What should our policy be regarding BR compliance for certificates >> issued by a root requesting inclusion, which were issued before the date >> of their request? Do we: >> >> A) Require all certs be BR-compliant going forward, but grandfather in >>the old ones; or >> B) Require that any non-BR-compliant old certs be revoked; or >> C) Require that any seriously (TBD) non-BR-compliant old certs be >>revoked; or >> D) something else? >> > > D) Require that the CA create a new root certificate to be included within > Mozilla products, and which all future BR-compliant certificates will be > issued from this new root. In the event this CA has an existing root > included within one or more software products, this CA may cross-certify > their new root with their old root, thus ensuring their newly-issued > certificates (which are BR compliant) work with such legacy software. > > This ensures that all included CAs operate from a 'clean slate' with no > baggage or risk. It also ensures that the slate always starts from "BR > compliant" and continues forward. > > However, some (new) CAs may rightfully point out that existing, 'legacy' > CAs have not had this standard applied to them, and have operated in a > manner that is not BR compliant in the past. > > To reduce and/or eliminate the risk from existing CAs, particularly those > with long and storied histories of misissuance, which similar present > unknowns to the community (roots that may have been included for >5 years, > thus prior to the BR effective date), require the same of existing roots > who cannot demonstrate that they have had BR audits from the moment of > their inclusion. That is, require 'legacy' CAs to create and stand up new > roots, which will be certified by their existing roots, and transition all > new certificate issuance to these new 'roots' (which will appear to be > cross-signed/intermediates, at first). Within 39 months, Mozilla will be > able to remove all 'legacy' roots for purposes of website authentication, > adding these 'clean' roots in their stead, without any disruption to the > community. Note that this is separable from D, and represents an effort to > holistically clean up and reduce risk. > > The transition period at present cannot be less than 39 months (the maximum > validity of a newly issued certificate), plus whatever time is afforded to > CAs to transition (presumably, on the order of 6 months should be > sufficient). In the future, it would also be worth considering reducing the > maximum validity of certificates, such that such rollovers can be completed > in a more timely fashion, thus keeping the ecosystem in a constant 'clean' > state. >From the perspective of being "clean" from a given NSS version this, makes sense. However the reality for most situations is there is demand to support applications and devices with trust stores that have not been updated for a while. This could be something as similar as Firefox ESR or it could be a some device with an older trust store. Assuming there is a need to have the same certificate chain work in both scenarios, the TLS server may need to send a chain with multiple root to root cross-certificates. To get a feel for how long a not looping path might be, I recently pulled trust stores for dozens of versions of Windows, Netscape, Mozilla, and Java. I then used unexpired cross-certificates from CT to group these trust anchors into unique clusters or disconnected graphs. The results are available as gists. https://gist.github.com/pzb/cd10fbfffd7cb25bb57c38c3865f18f2 is just the roots in each unique disconnected graph. Having the entries there does not imply that all have cross-signed each other, rather than there is a path from each pair of roots to a common node. For example, Root A and Root B might each have a subordinate CA that have each cross-certified the same, third subordinate. https://gist.github.com/pzb/ffab25cbe7d32c616792a5dec3711315 is the same data with all the unexpired subordinate cross-certificates included. Note that the clustering does not take into account anything besides expiration; for example it is possible that two paths to a common node have conflicting constraints. Considering we already see paths like: OU=Class 3 Public Primary Certification Authority,O=VeriSig