Hello Ryan,

thanks a lot for your very helpfull response!

A couple more comments below:

On 12.02.2018 19:13, Ryan Sleevi wrote:
>     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.

Do you mean out of scope for this discussion on this list? I understand.

I wonder if we should have a separate mailing list, where secondary
consumers of the Mozilla CA list could exchange thoughts on how to
implement the changes intended by Mozilla as closely as possible.

>     > 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?

I was trying to understand the origin of the additional subCAs, which
need to be covered using transitional intermediates. Who created those
managed CAs initially, and why are they related to the Symantec to
DigiCert transition? If they were originall issued by Symantec Root CAs,
why weren't they included in the initial list of subCAs that need to be

This is just out of curiosity.

dev-security-policy mailing list

Reply via email to