On 30/07/2017 00:45, Peter Bowen wrote:
On Thu, Jul 27, 2017 at 11:14 PM, Gervase Markham via
dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
Google have made a final decision on the various dates they plan to
implement as part of the consensus plan in the Symantec matter. The
message from blink-dev is included below.

[...]

We now have two choices. We can accept the Google date for ourselves, or
we can decide to implement something earlier. Implementing something
earlier would involve us leading on compatibility risk, and so would
need to get wider sign-off from within Mozilla, but nevertheless I would
like to get the opinions of the m.d.s.p community.

I would like to make a decision on this matter on or before July 31st,
as Symantec have asked for dates to be nailed down by then in order for
them to be on track with their Managed CA implementation timetable. If
no alternative decision is taken and communicated here and to Symantec,
the default will be that we will accept Google's final proposal as a
consensus date.

Gerv,

I think there three more things that Mozilla needs to decide.

First, when the server authentication trust will bits be removed from
the existing roots.  This is of notable importance for non-Firefox
users of NSS.  Based on the Chrome email, it looks like they will
remove trust bits in their git repo around August 23, 2018.  When will
NSS remove the trust bits?

Second, how the dates apply to email protection certificates, if at
all.  Chrome only deals with server authentication certificates, so
their decision does not cover other types of certificates.  Will the
email protection trust bits be turned off at some point?


It was previously stated in this newsgroup that non-SSLServer trust
would not be terminated, at least for now.

Third, what the requirements are for Symantec to submit new roots,
including any limit to how many may be submitted.
https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport
shows that there are currently 20 Symantec roots included.  Would it
be reasonable for them to submit replacements on a 1:1 basis -- that
is 20 new roots?


Those 20 old roots were the result of decades of mergers and
acquisitions, causing lots of "duplicates".

That said, it is better for overall security to have meaningful splits
of root CAs for any new CAs.  Most notably:

- Issuing a new (cross-signed) root for each new signature algorithm.  A
 full service CA should currently have roots for RSA-SHA256, RSA-SHA384,
 RSA-SHA512, and the ECDSA curves above 256 bits, each paired with the
 matching SHA size.  Others would be added 6 to 24 months after becoming
 BR-permitted.

- Due to current Mozilla implementation bugs, having separate roots for
 EV certificates is currently the only way to only accept EV certs from
 EV SubCAs.  This is specific to Mozilla.

- If Symantec wants to again set up a trust tree dedicated to cross-
 signing lots of outside parties (similar to the old "GeoRoot" program),
 it would be best to put that under separate roots.




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to