Hey Ryan – Thanks a ton for this post. I’m working on a reply and should have something next week, but I wanted to acknowledge that we saw the post and are working on providing the information requested.
Jeremy From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Thursday, September 14, 2017 1:28 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: DigiCert-Symantec Announcement On Wed, Aug 2, 2017 at 5:12 PM, Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: Hi everyone, Today, DigiCert and Symantec announced that DigiCert is acquiring the Symantec CA assets, including the infrastructure, personnel, roots, and platforms. At the same time, DigiCert signed a Sub CA agreement wherein we will validate and issue all Symantec certs as of Dec 1, 2017. We are committed to meeting the Mozilla and Google plans in transitioning away from the Symantec infrastructure. The deal is expected to close near the end of the year, after which we will be solely responsible for operation of the CA. >From there, we will migrate customers and systems as necessary to consolidate platforms and operations while continuing to run all issuance and validation through DigiCert. We will post updates and plans to the community as things change and progress. I wanted to post to the Mozilla dev list to: 1. Inform the public, 2. Get community feedback about the transition and concerns, and 3. Get an update from the browsers on what this means for the plan, noting that we fully commit to the stated deadlines. We're hoping that any changes Two things I can say we plan on doing (following closing) to address concerns are: a. We plan to segregate certs by type on each root. Going forward, we will issue all SSL certs from a root while client and email come from different roots. We also plan on limiting the number of organizations on each issuing CA. We hope this will help address the "too big to fail" issue seen with Symantec. By segregating end entities into roots and sub CAs, the browsers can add affected Sub CAs to their CRL lists quickly and without impacting the entire ecosystem. This plan is very much in flux, and we'd love to hear additional recommendations. b. Another thing we are doing is adding a validation OID to all of our certificates that identifies which of the BR methods were used to issue the cert. This way the entire community can readily identify which method was used when issuing a cert and take action if a method is deemed weak or insufficient. We think this is a huge improvement over the existing landscape, and I'm very excited to see that OID rolled out. Thanks a ton for any thoughts you offer. Jeremy eremy, Thanks for sharing details about your rough plans. There’s a lot at play here, particularly when trying to fully visualize DigiCert’s existing and proposed hierarchy, so I’m wondering if it might be easier to explore what the ‘ideal PKI’ may look like, and then try to work backwards to figure out how this acquisition can help that. At the core, we can imagine there is a root CA for each major long-term cryptographic configuration - which, in today’s world, generally means RSA/2048, RSA/4096, ECC/256, and ECC/384. In tomorrow’s world, this may also accommodate additional curves Ed25519 and Ed448, such as via https://tools.ietf.org/id/draft-ietf-curdle-pkix . In total, this means the ideal PKI only needs four to six root certificates. Within each root, you can build out the appropriate segmentation. For performance reasons, it’s likely preferable to have a ‘wide’ PKI (many sub-CAs off the root, each constrained in capability and used for a limited amount of time) versus a ‘deep’ PKI (hierarchically reducing the capabilities at each level in the trust graph- for example, “All TLS” -> “All DV” -> “All first party DV” -> “All first party DV in Q12017”), even if a deep PKI can provide better compartmentalization for some use cases. It isn’t clear that compartmentalizing on root provides any obvious benefits to users, especially as it’s the same infrastructure and audits, but it does seem that it increases the management overhead (for root stores), the configuration challenges (for site operators), not to mention the management (and, occasionally, network & memory) challenges for users to support all of those roots. It would be ideal to see DigiCert streamline its PKI to better align with that vision, and to understand what challenges might prevent that. For example, is there a path to transition all new DigiCert issuance to a single root? If it can’t be done for all certs, can it be done for TLS? Understanding if there are challenges to that goal can provide invaluable insight into how the Managed CA transition can look. A significant reason for the Managed CA plan was to provide a temporary bridge for those TLS servers who had made risky and fragile technical decisions - such as pinning to a single CA or only supporting a single CA on a device - while minimizing the risk to the broader TLS ecosystem. As Symantec, like other organizations wishing to operate a trusted CA, would be permitted to apply to have new roots (and a new infrastructure) included, once it had met the minimum required security standards, the Managed CA only needed to serve as a transition point until either Symantec had implemented new infrastructure or the community had migrated away. Conceptually, this bridge concept is somewhat similar to how SHA-1 was handled. In the lead-up to SHA-1’s deprecation, CAs self-removed a number of roots, on the basis that they planned these legacy roots to be used for SHA-1 issuance, and thus no longer be BR audited. Customers, both existing and new, were given SHA-256 certificates by default, but, should there be a demonstrated technical need for the legacy solution, a SHA-1 certificate could be provided that would work with older devices. The main difference between that SHA-1 transition and the proposal here is that the community recognizes that an immediate migration away from Symantec’s old infrastructure could present challenges, and thus a path was provided that allowed a limited degree of public trust for those compatibility certificates, with the assumption and expectation that it would be an interim solution towards either an eventual reapplication for trust or an ultimate sunset of this managed infrastructure. How does this all practically play out? One way to effectively manage this as follows: Identify the existing Symantec hierarchy, mapping out every logical CA (same name and key) and all the permutations of certificates for those names and keys - including cross-signs. Graphing this out is strongly recommended, given the sheer amount of information here. From there, look to identify what paths are currently, actively issuing TLS certificates that are trusted in the Web PKI - I suspect this will be a much smaller subset, based on Symantec’s past public disclosures. Some of these paths may transition multiple roots; such as having an older root sign a newer root sign the active intermediate. For each of the ‘newest’ roots, establish a new DigiCert-managed private key and issuance infrastructure on DigiCert’s existing infrastructure, name it in a way that ideally clearly identifies it, and cross-sign it with that ‘newer’ Symantec root. This serves as the Managed CA “root”, and in a way that provides the greatest similarity to Symantec’s existing issuance practices. Once you have that ‘emergency Managed CA’ infrastructure in place, work to migrate all existing Symantec customers to DigiCert issuance as quickly as possible. I know you suggested your goal was 2018, but one way you may be able to do this quicker is, for every existing Symantec customer, as a new certificate request comes in, issue them a DigiCert-chaining certificate. If they identify a compatibility issue - such as a client that only supports certain Symantec certificates - issue them a certificate off the Managed CA infrastructure - much like CAs handled the SHA-1/SHA-256 transition in the lead-up to the SHA-1 sunset. This reduces the use of the Managed CA infrastructure to just those who absolutely need it, and in a way that helps DigiCert identify the concrete challenges customers may face, which can facilitate community discussion on how to solve these challenges. I would further encourage the limiting the validity period of these Managed CA certificates to something 13 months or less, to help ensure that this bridge doesn’t become a crutch, and seems to align with your stated goal of helping these customers move to an existing DigiCert root by 2018. On the Root Program side, this helps greatly simplify the transition overhead and compatibility risk. If a Root Program takes no action, new (DigiCert-issued) certificates from the Managed CA infrastructure continue to work as-is, because they chain to the old Symantec roots. For Root Programs that are taking steps to reduce trust in Symantec certificates, they can whitelist those intermediates you identify from such reductions of trust - by adding the new Managed CA certificates as ‘new’ roots or by action in code. When steps are taken to fully remove the Symantec infrastructure (in 2018, as proposed), Root Programs can fully remove the legacy Symantec roots, and all of the certificates it has issued previously - while the new certificates issued under the Managed CAs will continue to work, as the Managed CAs were added as roots (or whitelisted from distrust). This plan helps transition from “legacy Symantec” to “new DigiCert”, which reduces the immediate risks to the ecosystem. Unfortunately, this has the side-effect that it means that DigiCert will now be operating a significant number of roots - the existing DigiCert roots, the ones it acquired from Verizon, the new “Symantec” roots (for those that did the swap-and-replace), and/or the old Symantec roots (for those that did not). This is not a problem unique to DigiCert - it arises in any form of CA acquisition or merger, such as Entrust/TrendMicro or WoSign/StartCom - but is truly special in the sheer number of combined-entity roots that will exist. Thus, it’s also incredibly useful if, in parallel, DigiCert can look for ways to harmonize and streamline that PKI towards that longer-goal of having just four to six roots - one for each cryptographic algorithm. In thinking about what actions may present compatibility issues - either to existing certificates or to new ones - I would suggest that signing any existing DigiCert root or subordinate CAs, or anything other than these few identified Managed CAs, with the legacy Symantec certificates, would likely be a recipe for interoperability issues for TLS clients. I’m not saying it’s expressly forbidden - just that, if done with existing roots, it may cause those current roots and everything they’ve signed to be rejected. This would happen for applications which don’t support the notion of trust anchors (e.g. when the intermediate in the chain presented is the same as a trusted root, which includes legacy OpenSSL-based products in addition to a number of macOS and iOS versions) to those that impose policies based on the root (whether EV recognition or, as a result of past misissuances, policies that limit trust in Symantec-issued certificates). Avoiding that for, at a minimum, TLS, is the best success strategy I can recommend, although I would honestly recommend avoiding that across the board, given the client issues I’ve seen over the years. If there are challenges with this outline, it might be useful to diagram a bit of the existing Symantec and DigiCert infrastructure - both by logical CA (same name and key) and the actual certificates - so that we can easily visualize and discuss what paths may be impacted by DigiCert’s proposed plan or those plans of Root Programs. This would allow easier collaboration on how best to achieve that integration with minimal risk to the ecosystem or to DigiCert or Symantec customers, which is a goal I’m certain we all share.
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
