Without commenting on the Symantec aspect of this, there is a rather substantial correction to the behaviour of client software - including Firefox.
Unfortunately, very few libraries and path validators support chain building terminating at trust anchors in the way you describe. Recent changes in Firefox itself have resulted in it preferring longer chains (validating to the cross-signed root), rather than terminating at the trust anchor, thus affecting measurements of per-root usage. Examples: - macOS versions prior to 10.11 were biased to use the presented chain - meaning if cross-certified trust anchors were presented, they may result in a longer chain (DigiCert should recall the effect of this). 10.11+ has a weighting scale for certificate chains, but this is somewhat opaque - OpenSSL versions prior to 1.0.2 were biased to prefer the presented chain and try to build to a self-signed root. Thus if intermediates had explicit trust settings (including if it was because a self-signed version was trusted), these settings would be ignored. As noted in the 1.0.2 changelog, this feature is still 'experimental' - Firefox recently regressed with this behaviour - https://bugzilla.mozilla.org/show_bug.cgi?id=1364159 introduced the bug (Firefox 55), and https://bugzilla.mozilla.org/show_bug.cgi?id=1400913 (Firefox 57) tried to resolve it. - Windows bases its path-preferences on a complex set of signals, some internal (such as the order of store creation and the ordering of MD5/SHA-1 hashes of the certs), some external (such as the notBefore date of the certificate). This can be further compounded by whether or not users have AuthRoot updates disabled and/or misconfigured (e.g. improper proxy settings). For example, if your new roots were added in a subsequent root update, there's no guarantee that Windows users would consistently build paths to that new root, because they may not yet know that the new root is trusted, or the configuration of intermediates may result in a longer path being preferred. In short, you cannot reliably assume that in the case of cross-signing, the shorter path to a trust anchor will be build or preferred. For this reason, cross-signing to existing roots is complex. On Fri, Oct 27, 2017 at 12:37 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Yes. Or any root that is cross signed by the Symantec sub cas. I assume > there would be zero impact as the chain building should stop with the > trustees root and not look at the Symantec roots, but it’s definitely good > to double check. > > On Oct 27, 2017, at 10:32 AM, Peter Bowen <pzbo...@gmail.com<mailto:pzbo > w...@gmail.com>> wrote: > > On Fri, Oct 27, 2017 at 9:21 AM, Jeremy Rowley > <jeremy.row...@digicert.com<mailto:jeremy.row...@digicert.com>> wrote: > I'm also very interested in this scenario. > > I'm also interested in what happens if a trusted DigiCert root is signed by > a Symantec root. I assume this wouldn't impact trust since the chain > building would stop at a DigiCert root, but I wanted to be sure. > > Jeremy, > > To clarify your scenario, do you mean what happens if a DigiCert owned > and operated CyberTrust or DigiCert branded root is cross-signed by a > DigiCert owned and operated VeriSign, Thawte, or GeoTrust branded > root? (Assuming all the roots are roots currently listed at > https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport) > > Thanks, > Peter > > > -----Original Message----- > From: dev-security-policy > [mailto:dev-security-policy-bounces+jeremy.rowley= > digicert.com@lists.mozilla > .org] On Behalf Of Peter Bowen via dev-security-policy > Sent: Friday, October 27, 2017 9:52 AM > To: Gervase Markham <g...@mozilla.org<mailto:g...@mozilla.org>> > Cc: mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozil > la-dev-security-pol...@lists.mozilla.org>; Kathleen Wilson > <kwil...@mozilla.com<mailto:kwil...@mozilla.com>> > Subject: Re: Mozilla's Plan for Symantec Roots > > On Tue, Oct 17, 2017 at 2:06 AM, Gervase Markham <g...@mozilla.org<mailto: > g...@mozilla.org>> wrote: > On 16/10/17 20:22, Peter Bowen wrote: > Will the new managed CAs, which will operated by DigiCert under > CP/CPS/Audit independent from the current Symantec ones, also be > included on the list of subCAs that will continue to function? > > AIUI we are still working out the exact configuration of the new PKI > but my understanding is that the new managed CAs will be issued by > DigiCert roots and cross-signed by old Symantec roots. Therefore, they > will be trusted in Firefox using a chain up to the DigiCert roots. > > Gerv, > > I'm hoping you can clarify the Mozilla position a little, given a > hypothetical. > > For this, please assume that DigiCert is the owner and operator of the > VeriSign, Thawte, and GeoTrust branded roots currently included in NSS and > that they became the owner and operator on 15 November 2017 (i.e. > unquestionably before 1 December 2017). > > If DigiCert generates a new online issuing CA on 20 March 2018 and > cross-signs it using their VeriSign Class 3 Public Primary Certification > Authority - G5 offline root CA, will certificates from this new issuing CA > be trusted by Firefox? If so, what are the parameters of trust, for > example > not trusted until the new CA is whitelisted by Mozilla or only trusted > until > a certain date? > > What about the same scenario except the new issuing CA is generated on > 30 June 2019? > > Thanks, > Peter > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org<mailto:dev- > security-pol...@lists.mozilla.org> > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
