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.
IIUC, the current implementation in Firefox (for the early console
warnings) is based on distinguished named (DN), not SPKI:
> 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?
If not, it would be helpful to list these risks, and why they can only
be addressed by using SPKI matching.
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?
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?
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?
Maybe the compatibility risks aren't about alternative subCAs?
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,
> 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?
What is the potential disruption, and how are you avoiding it?
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?
Also, I noticed that Gerv's post from 2017-10-17 had mentioned 7 Apple
but the chromium "excluded" subdirectory contains only 6 Apple subCAs.
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?
> For example, if you note, there are two Google certificates, but they
> share the same SPKI and Subject Name - which is why the Chromium
> whitelist only has one certificate listed, as it extracts the SPKI from
> that resource as part of the whitelist.
Are you referring to these two subCAs?
It seems the first one has already expired, and it might no longer be
necessary to worry about it?
dev-security-policy mailing list