On 16.10.2017 19:33, Gervase Markham via dev-security-policy wrote:
> As per previous discussions and
> https://wiki.mozilla.org/CA:Symantec_Issues, a consensus proposal[0] was
> reached among multiple browser makers for a graduated distrust of
> Symantec roots.
> 
> Here is Mozilla’s planned timeline for the graduated distrust of
> Symantec roots (subject to change):
> 
> * January 2018 (Firefox 58): Notices in the Developer Console will warn
> about Symantec certificates issued before 2016-06-01, to encourage site
> owners to migrate their TLS certs.
> 
> * May 2018 (Firefox 60): Websites will show an untrusted connection
> error if they have a TLS cert issued before 2016-06-01 that chains up to
> a Symantec root.

My understanding is, this will be done without making any changes to the
Mozilla CA list. Firefox will implement these initial phases by changing
its certificate validation code.

It seems likely that many other consumers of the Mozilla CA list, which
use their own implementation for certificate validation, will likely not
implement these initial phases. I'm probably stating the obvious.

I'd like to thank the developers who can implement this initial distrust
phase in their software, as it will clear the way for the later phase of
distrust, benefitting other TLS client software which cannot easily
implement the initial phases.


> * October 2018 (Firefox 63): Removal/distrust of Symantec roots, with
> caveats described below.

This is the milestone that will affect also the secondary consumers of
the Mozilla CA list. I assume the updated CA list with the removed
Symantec roots will be published as part of NSS 3.39 around mid October.


> However, there are some subCAs of the Symantec roots that are
> independently operated by companies ... [snip] ...> There are two ways that 
> we can provide a smoother transition for these
> subCAs.

I haven't seen a follow up message with a decision on this detail. I
assume it's still open for discussion.


> Option 1)
> Temporarily treat these subCAs as directly-included trust-anchors.
> ... [snip]
> 
> Option 2)
> Add code to Firefox to disable the root such that only certain subCAs
> will continue to function. So, the final dis-trust of Symantec roots may
> actually involve letting one or two of the root certs remain in
> Mozilla’s trust store, but having special code to distrust all but
> specified subCAs. ... [snip]

I assume that these subCAs are used on the public web. IIUC, after
secondary consumers of the Mozilla CA list update to the newer version,
they will also require a solution that allows them to continue to trust
these subCAs.

Option 2 solves the issue for Firefox, but it isn't a practical solution
for secondary consumers of the Mozilla CA list.

There are too many implementations of certificate validation, and I
think it's unrealistic that each implementation can implement Option 2.

Without implementing option 2, but to keep compatibility with the public
web, those secondary consumers would have to modify the Mozilla CA list.
There's risk they might decide to continue to trust the Symantec CAs, as
that would be the easiest and most compatible approach. I think we
should avoid that secondary consumers might consider this solution, as
it would be counterproductive to this initiative.

I understand that secondary consumers of the Mozilla CA list aren't the
primary focus of Mozilla and of this policy list, but in the interest of
applying the Symantec distrust initiative to the majority of the open
source software ecosystem, it might be prererable to implement Option 1
in the Mozilla CA list.

Gerv mentioned the following concerns on Option 1:

> Mozilla prefers *not* to take this approach, because even if clearly
> explained up front that it is a temporary solution with deadlines, it
> would be very easy for people to start treating such a subCA as a
> regular trust anchor, and thereby have that subCA become a de facto
> included CA. 

If consumers of the Mozilla CA list usually followed Mozilla's removal
decisions, why would they not follow Mozilla's removal of these CAs at a
later time?

Why would this be more risky than Option 2? Couldn't we similarly argue,
if a secondary consumer of the Mozilla CA list decided to implement
whitelisting of these subCAs in their certificate validation code, isn't
there similar risk that they wouldn't remove such whitelisting from
their code? I'd even argue that a code implementation has a higher risk
of surviving for a longer amount of time, because changing code is more
difficult than changing configuration files that contain a list of
trusted CAs.


> Additionally, it could become very complicated to remove
> such subCAs in the future, especially if they have not performed the
> recommended transitions.

This message was sent in October 2017. By the time we reach October
2018, the owners of the subCAs will have known about the need to
transition away from the classic Symantec PKI for one year. In the case
of Google it's even longer, because they have started to push for this
change much earlier.

If Mozilla decides to grant Apple and Google the ability to continue to
use these subCAs beyond October 2018, then IMHO Mozilla is already very
generous.

Given that critical incidents in the Web PKI could require an emergency
distrust of Root CAs at any time, the need for migration times beyond
one year surprises me.

I don't mind allowing Apple and Google to keep using their subCAs for a
little longer, but it also seems to me, that negotiating a clear
deadline for these subCAs should be acceptable, and that removing the
subCAs by a clearly announced date should be acceptable, too.

However, I understand the general reluctance for effectively including
these subCAs directly in the Mozilla Root store, because it would
effectively give those subCAs the treatment of a Root CA, without having
gone through the usual hurdles for inclusion.

Nevertheless, even if Mozilla decided to go with Option 2, secondary
consumers of the Mozilla CA list might have to implement Option 1
anyway, for practical purposes.

Kai
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to