On Mon, Feb 12, 2018 at 11:36 AM, Kai Engert <k...@kuix.de> wrote: > On 09.02.2018 22:20, Ryan Sleevi wrote: > > As a small clarification - while Chrome has included the certificates, > > as noted in the readme, the whitelist is based on SPKI. This was > > intentional, to avoid situations of interoperability issues. > > Hi Ryan, > > IIUC, the current implementation in Firefox (for the early console > warnings) is based on distinguished named (DN), not SPKI: > > https://hg.mozilla.org/integration/autoland/rev/d3acb68f73c4 > > > > Whitelisting by certificate, rather than either SPKI or SPKI-Tuple, > > brings with it significant compatibility risks to the ecosystem in terms > > of being able to respond to issues. > > Can these risks be avoided, too, by using the DN matching strategy that > the Firefox code uses? >
No. > If not, it would be helpful to list these risks, and why they can only > be addressed by using SPKI matching. > These risks were previously extensively discussed during the finalization of the plan, and are expanded upon below. Is your worry that alternative subCAs (already existing, or potentially > being introduced in the future) could be used in server configurations, > and that path building code might fail to match unexpected subCAs > against the whitelist? > Yes. > I hope we shouldn't have to worry about alternative, already existing > subCAs. There shouldn't be alternative subCAs, because it would have > been required to request their whitelisting already, right? > No, not if done by SPKI. > Also, I hope we shouldn't have to worry about alternative, future > subCAs. It's not allowed to use the old Symantec CA infrastructure to > issue alternative subCAs that might require whitelisting, right? > No, it's not, provided they use the same SPKI. https://crt.sh/?spkisha256=ac50b5fb738aed6cb781cc35fbfff7786f77109ada7c08867c04a573fd5cf9ee is a concrete example of this. The initial Transition RSA Root was cut, then issued under the VeriSign Class 3 G5 root - https://crt.sh/?id=250864698 This was all done prior to 2017-12-01. However, this was insufficient for a number of customers, who needed certificates chaining to other roots. Several DigiCert/Symantec customers reached out with examples of this, such as requiring chains to the VeriSign Universal Root Certification Authority ( https://crt.sh/?caid=1110 ). There is no path from G5 to UCA. To accommodate such customers, DigiCert performed another signing ceremony, on December 8, in which they issued several additional certificates which chain to other Symantec roots (other than G5), while sharing the same SPKI. To avoid causing path building issues on clients, each of these new certificates varies by DN, but all share the same SPKI, providing assurance that it's the same key material with the same audited controls as the managed PKI. When thinking about what assurances are desired by the Managed CA, the security assurance is tied to the key, not to the name. This is why Chrome's whitelist is based on SPKI - if the key is adequately secured and audited, we have assurance, but the name can be associated with any key, and is not. It's not unreasonable to predict that, as the transition continues, and more customers look to transition (particularly those with certificates issued after 2016-06-01), we may see further managed CAs cut. In a DN-based whitelist, all of these would fail to work in browsers unless code changes were made, whereas in an SPKI whitelist, all of these would work just fine. > A separate question which would be good to clarified: What about > environments, which want to distrust all old Symantec roots in October > 2018, but cannot add whitelisting to their cert validation code, and > choose to explicitly trust each of the subCAs. Such an environment > should be able to find a chain to one of the explicitly trusted subCAs, > right? > You're asking about non-browser environments that cannot implemented https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F ? I thought we'd ruled that out of scope rather comprehensively. Explicitly trusting by sub-CAs is, in effect, a DN whitelist with added restrictions, and thus runs the risk I mentioned. > > We've already seen this born out > > with respect to DigiCert and their Managed PKI intermediates, and wanted > > to avoid disruption to both Apple and Google that would otherwise > > destablize the ecosystem. > > What is the relationship between the distrust of Symantec CAs and > intermediates managed by DigiCert? Did DigiCert already run managed > intermediates, before the Symantec-to-DigiCert migration efforts begun, > that still depend on Symantec CAs to be trusted? > I'm not sure I understand this question? > What is the potential disruption, and how are you avoiding it? > See above. > Are you avoiding it by including the two DigiCert Transition RSA/ECC > Root certificates in the whitelist? > Why is it necessary to refer to them by SPKI, e.g. do you expect there > might be future, alternative intermediates for transition roots those? > Yes. For DigiCert (as we've already seen), potentially for Apple (as we've had discussions with them), and potentially for Google (as Piotr has mentioned below). Based on your message, I just looked at them, but I see that all of them > have different SPKI. Do you know why the Chromium excluded directory > only lists 6 Apple subCAs? > Audit scope. > Are you referring to these two subCAs? > https://crt.sh/?id=23635000 > https://crt.sh/?id=142951186 > > It seems the first one has already expired, and it might no longer be > necessary to worry about it? > See Piotr's reply, and my restatement of what was already discussed above :) _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
