Notes on your below suggested timeline:
1. I see no reason to have that many new root bundles from Symantec.
Ideally, there would be just two bundles: A transitional root bundle
which signs the outsourced SubCAs only, and a final bundle intended
to become the new long-term Symantec roots. The transitional root
bundle would be made in a subset of the current Symantec
infrastructure, while the final bundle would be generated in the
new higher security infrastructure isolated from any historic bugs
in the old infrastructure.
2. For any certificate bundle that needs to be incorporated into the
Mozilla root stores, a significant period (3 to 6 months at least)
will be needed between acceptance by Mozilla and actual trust by
Mozilla users. This would involve time to complete the following:
2.1 Adding the new roots to the NSS store source code.
2.2 Actually incorporating that updated NSS store into release candidate
builds of all Mozilla products.
2.3 Releasing those builds of Mozilla products to the general public
2.4a Waiting for the majority of users (especially those with telemetry
and other phone-home behavior disabled) to install the updated Mozilla
products.
2.4b Waiting for enterprise users to incorporate the updated Mozilla
products into new system images and rolling out those system images.
2.4c Waiting for users to migrate beyond Firefox ESR 52 due to
disrupting non-PKI changes (feature removals) made at that point.
Similar for future feature-disrupting Mozilla product changes.
(Note this is not a complaint about the breaking changes beyond Fx ESR
52, just an observation that such actions by other Mozilla teams can
cause a significant delay in the deployment of NSS root store changes).
On 16/06/2017 14:43, Peter Kurrasch wrote:
My thoughts:
2) Timeline.
I agree with Symantec that Google's original deadlines are far too
aggressive, for 2 reasons. First, I do not think Symantec can move
quickly without causing further damage. Second, I do not think
Symantec's customers can move quickly at all given that a majority of
them are large corporations that have to coordinate budgets, staff,
outsourcing firms, and so forth. These customers also need time to
familiarize themselves with the new rules and identify a course of
action that makes sense for their business environments and their user
base. Even though I understand the desire to move quickly, in this
situation it seems imprudent to do so.
Many will find this next bit unacceptable, but in the interest of
providing an alternative, let me suggest a timeline of 6 different dates
over the next 2 years (in case it really does take that long): the 21st
day of February, May, and August of 2018 & 2019. Each of these dates
represent a different milestone for changes in policy enforcement,
certificate validation, software and systems, and whatever is identified
as a deliverable in these ongoing discussions. The dates here are chosen
specifically to acknowledge that many businesses operate on a quarterly
system while avoiding complications that inevitably take place at the
end of a quarter and the end of the year. And, yes, that would imply no
action taken before Feb of next year.
1) Scope of Distrust
First a question: is removing the EV entitlements from the Symantec
roots something that is still on the table for Mozilla products or has
that been dismissed for some reason? I ask because it hardly seems
appropriate that a CA under sanction be entitled to all the benefits
that are extended to CA's which are not under sanction. Doing so also
inflicts some pain on Symantec (without breaking the global economy)
until such time as they've resolved their issues to Mozilla's satisfaction.
Regarding the expiration of certificates, I do not agree that CT logging
engenders trust so I disagree with Symantec on that. Frankly I don't
entirely agree with Google on the phased dis-trust and CT logging items.
Those seem to increase complexity in the PKI ecosystem (which carries
its own risk) without necessarily improving the ecosystem, but it's very
likely I've missed some important details.
As to scope itself, my understanding is that Mozilla will eventually
remove trust from all current Symantec roots (the "ubiquitous roots")
and in its place use a set of "new roots", some of which will be under
the purview of Symantec competitors. These new roots will be
cross-signed to those ubiquitous roots so that new certs that chain up
to these new roots will still validate properly on products that have
not or cannot be updated to use the new roots. (If my understanding is
incorrect, I hope someone will correct me.)
To put it another way, all existing certs that chain up to the
ubiquitous roots will eventually stop working--many before their date of
normal expiration. As such, there needs to be a ramp up of new cert
issuing capacity while at the same time a phasing out of the existing
certs. Combining that with the above "alt-timeline" would look something
like the following. The exact makeup of the root bundles and CA groups
are TBD.
Milestone 1 (Feb 21, 2018) - EV entitlement removed from the ubiquitous
roots, new root cert bundle A is ready to go, and CA group 1 is
approved to begin issuing against the roots in bundle A. No new end
entity certs have been issued yet.
Milestone 2 (May 21, 2018) - New root bundle B is ready to go and CA
group 2 is approved to begin issuing against bundle B, but has not yet
done so.
Milestone 3 (Aug 21, 2018) - New root bundle C is ready to go and CA
group 3 is approved to begin issuing against bundle C, but has not yet
done so.
Milestone 4 (Feb 21, 2019) - New root bundle D is ready to go and CA
group 4 is approved to begin issuing against bundle D, but has not yet
done so. In addition, some analysis should be performed to evaluate the
overall health of the new root solution (for example, how many total
certs have been issued, any reports of major disruptions to end users,
etc.).
Milestone 5 (May 21, 2019) - The fifth, and final, bundle E of new
roots is ready to go and CA group 5 is approved to begin issuing against
them but has not yet done so. This would also represent the earliest
date that Symantec is allowed to be included in any of the CA groups.
Milestone 6 (Aug 21, 2019) - Final removal of trust for the original
Symantec roots.
I know that some of this represents a significant departure from what
Google and Symantec have previously discussed but I thought there might
be some utility in having an alternate framework from which to draw.
*From: *Gervase Markham via dev-security-policy
*Sent: *Tuesday, June 6, 2017 9:03 AM
On 02/06/17 15:53, Gervase Markham wrote:
>
https://www.symantec.com/connect/blogs/symantec-s-response-google-s-subca-proposal
I'm slightly surprised to see no engagement here. Perhaps it would be
help to break it down. Symantec's specific requests for modification are
as follows (my interpretation):
1) Scope of Distrust
Google proposal: existing CT-logged certificates issued after 1st June
2016 would continue to be trusted until expiry.
Symantec proposal: all CT-logged certificates should continue to be
trusted until expiry.
Rationale for change: if transparency is enough to engender trust, that
principle should be applied consistently. This also significantly
reduces the revalidation burden.
2) Timeline
Google proposal: a set of dates by which certain milestones must be
achieved.
Symantec proposal: no specific alternative dates (more info by the end
of June), but the Google dates are too aggressive.
Rationale: need to establish business relationships; capacity issues at
Managed CAs; international requirements further complicate things; the
revalidation burden is very large; writing solid code takes time.
3) SubCA Audit Type
Google proposal: SubCAs are audited with the standard audits.
Symantec proposal: treat SubCAs as Delegated Third Parties and so give
them BR section 8 audits (an audit by the CA not an auditor; 3% sampling).
Rationale: none given.
4) Validation Task Ownership
Google proposal: Symantec and its affiliates must not participate in any
of the information verification roles permitted under the Baseline
Requirements. They may, however, collect and aggregate information.
Symantec proposal: Symantec currently uses a 2-step process - validation
and review. Symantec should be allowed to do the first, with the SubCA
doing the second (with 100% review, not samplingh).
Rationale: reducing the burden on the SubCA, reducing the time for them
to ramp up, and (presumably) to allow the Symantec personnel to continue
to have jobs.
5) Use of DTPs by SubCA
Google proposal: SubCAs may not use Delegated Third Parties in the
validation process for domain names or IP addresses.
Symantec proposal: SubCAs should be allowed to continue to use them in
situations where they already do.
Rationale: SubCAs should not be required to rejig their processes to
work with Symantec.
6) SubCA Audit Timing
Google proposal: SubCAs are audited at 3 month intervals in the 1st
year, 6 months intervals in the 2nd year, and then yearly.
Symantec proposal: after the initial audit, only yearly audits should be
required.
Rationale: Because SubCAs are established CAs, once an audit has been
done to validate the transition, the subsequent audit schedule should be
the standard yearly one, not the high-frequency 3/6 month one proposed.
7) Detailed Audits
Google proposal: Symantec may be requested to provide "SOC2" (more
detailed) audits of their new infrastructure prior to it being ruled
acceptable for use.
Symantec proposal: such audits should be provided only under NDA.
Rationale: they include detailed information of a sensitive nature.
Gerv
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
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
