On Monday, May 22, 2017 at 4:46:16 PM UTC, Gervase Markham wrote:
> On 21/05/17 19:37, userwithuid wrote:
> > With the new proposal, the "minimal disruption" solution for Firefox
> > will require keeping the legacy stuff around for another 3.5-4 years
> > and better solutions will now be a lot harder to sell without the
> > leverage provided by Google.
>
> Why so? In eight months' time, if Chrome is no longer trusting certs
> issued before 2016-06-01, why would it be a problem for Firefox to stop
> trusting them shortly thereafter?
A)
It wouldn't. Specifically, for all certs under current Symantec roots, to sync
with Google we can check:
1. If the chain contains a whitelisted intermediate (= "Managed CA"), don't
impose further notBefore restrictions
2. For all other intermediates, only trust certs with notBefore between
2016-06-01 and 2017-08-08
This is a whole lot better than no restrictions and should definitely be done.
(Also, Jakob explained this above as well, I'm just repeating it).
My point was about the fringe parts of Symantec's current PKI. In 8 months,
Chrome will _actually_ eliminate all of those using both CT-enforcement and
notBefore => the "old" PKI is now WYSIWYG and quite fresh from their point of
view. No more unknowns or waiting for Symantec to draw their map and discover
SSP2 while forgetting SSP3. :-P
For Firefox, this doesn't hold true. Not all certs under Symantec roots issued
since 2016-06-01 are or need to be CT-enabled, so that date doesn't really
align with better issuance practices for everything Mozilla actually trusts.
At the end of the day it's gonna be fine of course: Most of the legacy will
also be disabled in practice with the notBefore restrictions in Firefox. And
anyway: What good is a cert if it isn't trusted by half of all web users? We
can ride that Chrome market share wave. Still, Google's solution w.r.t. to the
old PKI is just technically superior.
B)
Anyway, I don't want to derail the discussion and get back to what to do with
the intermediate PKI ("Managed CA" under old roots) and new PKI (new roots,
2018?), that is also very important.
One suggestion on that: Let's define the date on which we remove the old roots
from NSS and disallow the use of any "Managed CA" via policy so that the
intermediate PKI can't tranform into a de-facto long-term PKI. This is meant to
force Symantec to focus their efforts on their own new roots. I don't think
they should have that intermediate PKI as a comfy fallback when things with the
new roots don't turn out that well or get delayed (they seem to have a tendency
for delaying things...).
One such date would be 2021-06-01, after the last 39 months cert issued by the
Managed CA on 2018-02-28 expires. That allows the Managed CA to operate
unrestricted (only BR-compliant) until 2019-02-28 at least, then enter a sunset
period with shorter lifetimes. Lots of time to get the new roots fully
operational.
We could shave off up to 7 months on both dates (purge and sunset) if we don't
allow the Managed CA to issue 39mo certs in the first place, only 27. Mozilla's
first proposal was 13 months for new certs, so 27 - which will become mandatory
soon anyway - sounds quite reasonable to me.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
