> -----Original Message-----
> From: Gervase Markham [mailto:g...@mozilla.org]
> Sent: Wednesday, June 07, 2017 2:51 PM
> To: Steve Medin <steve_me...@symantec.com>; mozilla-dev-security-
> pol...@lists.mozilla.org
> Cc: Kathleen Wilson <kwil...@mozilla.com>
> Subject: [EXT] Mozilla requirements of Symantec
>
> Hi Steve,
>
> I'm writing to you in your role as the Primary Point of Contact for Symantec
> with regard to the Mozilla Root Program. I am writing with a list of Mozilla-
> specific additions to the consensus remediation proposal for Symantec, as
> documented by Google.
>
> We note that you have raised a number of objections and queries with
> regard to the consensus proposal. As you know, we are considering our
> responses to those. We reserve the right to make additional requests of
> Symantec in relation to any changes which might be made to that proposal,
> or for other reasons.
>
> However, we have formulated an initial list of Mozilla-specific addenda to
> the consensus proposal and feel now is a good time to pass them on to
> Symantec for your official consideration and comment. We would prefer
> comments in mozilla.dev.security.policy (to which this notice has been
> CCed), and in any event by close of business on Monday 12th June.
>
> 1) Mozilla would wish, after the 2017-08-08 date as documented in the
> consensus proposal, to alter Firefox such that it trusts certificates issued 
> in
> the "new PKI" directly by embedding a set of certs or trust anchors which
> are part of that PKI, and can therefore distrust any new cert which is issued
> by the old PKI on a "notBefore" basis. We therefore require that Symantec
> arrange their new PKI and provide us with sufficient information in good
> time to be able to do that.
>

Symantec supports creation of a new PKI. Limiting Firefox trust of new 
certificates to those issued off of the new PKI is a practical path forward, 
due to Firefox’s contained scope and auto-update capabilities.

The same does not hold true for the removal of current PKI roots from NSS and 
the entirety of NSS dependents.

We understand the cutoff date to mean that any end entity cert issued after 
that date from the current PKI would not be trusted, but this date would have 
no effect on the trust of existing current PKI certs, their issuers, or their 
roots. Mozilla has not yet chosen the notBefore milestone date, and we 
interpret your proposal as intent to set a date and announce that date with 
enough advance notice to support public notice to affected parties. To that 
end, based on our research, we believe the 2017-08-08 date is not achievable 
given the magnitude of the transition that would need to occur and we propose 
that Mozilla not conclude on final dates for Symantec certificates at this time.

In response to the Google proposal, Symantec is currently evaluating a third 
party “SubCA” approach, which requires substantial operational changes. We have 
conducted outreach to candidate partners (SubCAs) to understand the potential 
constraints, timelines and the integration work that might be needed. We have 
also formalized and issued an RFP with specific questions around timing, 
logistics and dependencies. We expect to have the required feedback to inform a 
project plan by the end of June, at which time we will come back to Mozilla and 
the community regarding suggested dates that are both aggressive and achievable 
under this approach, by Symantec and the SubCA(s).

> 2) Mozilla would wish, at some point in the future sooner than November
> 2020 (39 months after 2017-08-08, the date when Symantec need to be
> doing new issuance from the new PKI), to be certain that we are fully
> distrusting the old PKI. As things currently stand technically, distrusting 
> the
> old PKI would mean removing the roots, and so Symantec would have to
> move their customers to the new PKI at a rate faster than natural certificate
> expiry. Rather than arbitrarily set a date here, we are willing to discuss 
> what
> date might be reasonable with Symantec, but would expect it to be some
> time in 2018.
>
> As you know, Firefox currently does not act upon embedded CT
> information, and so CT-based mechanisms are not a suitable basis for us to
> determine trust upon. Were that to change, we may be able to consider a
> continued trust of CT-logged certs, but would still want to dis-trust non-CT-
> logged certs sooner than November 2020.
>

We think it is critically important to distinguish potential removal of support 
for current roots in Firefox versus across NSS. Limiting Firefox trust to a 
subset of roots while leaving NSS unchanged would avoid unintentionally 
damaging ecosystems that are not browser-based but rely on NSS-based roots such 
as code signing, closed ecosystems, libraries, etc.

As one example, we note that libraries that rely on NSS in non-browser based 
applications, many of which are not easily updated, may have unintended 
negative impact in automobiles, television sets, routers, printers, mobile 
phones, tablets, set top boxes, and media players.

We believe that the concern is in regards to the integrity of certificates 
issued from subCAs that were authenticated by both Symantec’s team and those of 
our former SSL/TLS RAs, given concerns related to the practices of the RAs. 
With the exception of Issue D in 2015, the validation practices of Symantec’s 
authentication team are not in question. Mozilla has publicly supported our 
in-house team’s work as “better/safer” than requiring third parties to perform 
validation. That same Symantec authentication team has now completed a full 
revalidation of CrossCert authenticated certificates and a 100% review of those 
from all other SSL/TLS RAs. We are finalizing our disclosure about that 
revalidation/review effort that proved on average 96% of RA-issued certificates 
fully satisfied our criteria that, in many aspects, exceed the Baseline 
Requirements. Any exception certificates have been revoked. And of the 4% 
remaining, the revocations we conducted were largely necessitated by errors in 
spelling, translation, location tier, or abbreviation. As a result, we don’t 
see a reason for shorter trust of existing certificates from these subCAs.

Should Mozilla see a need to establish a cutoff in Firefox for trust of 
certificates from our current PKI, we recommend harmonizing that approach with 
other browsers – and specifically anchor that trust around whether or not the 
certificates have been logged to CT and include SCTs. We began logging 
certificates to CT starting in January 2015 and moved to 100% logging in June 
2016. We assert that the certificates we have authenticated and issued have 
been issued correctly. While we understand that Firefox does not act upon CT 
information, CT, independent of any one browser, still provides domain owners 
the ability to determine if certificates issued to their domains were 
authorized. CT monitors are easily available (and some free). The ability for 
members of the Mozilla community to leverage CT has required no work by Mozilla 
(e.g. to support SCT extensions or any of CT’s technical implementation), but 
nevertheless has allowed issues to be found and the associated risk to be 
managed. We see this as an appropriate risk-based approach to transitioning 
from the current PKI within Firefox to a new one while limiting unnecessary 
customer disruption.

> 3) If any additional audit is performed by Symantec, including but not
> limited to one that "that includes a description of the auditor’s tests of
> controls and results", then the intended users of the audit report must also
> include persons who assist in decisions related to the trusted status of
> Certification Authorities within Mozilla products. For any audit to unusually
> detailed criteria, it is permitted to place this information behind a login 
> (or
> require it to be so placed) as long as Mozilla is allowed to give access to 
> any
> member of our community that we wish.
>

We share our audit reports today and auditors are required to include in those 
reports any material findings. We responded to Google that we would be willing 
to share other reports of a sensitive nature under non-disclosure. Enabling any 
member of the Mozilla community, which we interpret as potentially an unlimited 
number of persons, to access detailed audit reports is difficult to allow 
without a clear understanding and agreement on the level of detail we would 
share or redact.

Our assumptions about the information you ask us to disclose may be different 
from yours. Therefore, we would like to better understand the scope of the 
information you want to see to determine whether exposure of that information 
is a manageable risk and acceptable to the audit firms. WebTrust auditors are 
not required to disclose their test of controls and our experience has been 
that auditors in general will not consent to publicly disclose additional 
information regarding their audit engagement beyond what is established by the 
audit standards they follow. We welcome more input from the community including 
auditors as well.

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

Reply via email to