On Mon, Apr 10, 2017 at 10:56 AM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Issue L: Cross-Signing the US Federal Bridge (February 2011 - July 2016)
> Symantec, as well as VeriSign, has participated in the FPKI since 2006,
> and we take our responsibility as a participant of this program very
> seriously. When Symantec began participating in FPKI, FPKI rules required
> two-way cross-certification in a networked PKI model. In addition, FPKI
> rules mandated multiple assurance levels, which we mapped to our Class 1,
> Class 2 and Class 3 roots. Class 3 roots are the only ones that have ever
> been enabled for TLS server certificate issuance.

A few things up front:

* My information could be incomplete.
* Symantec's responses to my questions when I brought this issue to their
attention in 2016 were always clear, professional, and timely.
* While we're at the same agency and we do collaborate, I don't work on the
Federal PKI team, and this message represents only my individual efforts
and not the Federal PKI or all of GSA.

But I want to add some color here and note that Symantec has a public
statement on m.d.s.p in December 2011 that seems to indicate that the root
which created the cross-sign in question came in through a VeriSign


That root certificate's name ("VeriSign Class 3 SSP Intermediate CA - G2")
was never mentioned in Bugzilla, and was not discussed during the inclusion
of its parent CA ("VeriSign Universal Root Certification Authority"):

While Symantec's CPS in 2016 mentions the Federal Bridge, the CPS that
VeriSign had at the time they submitted that parent CA to Mozilla's program
in 2009 does not mention the Federal PKI in any way:


I am not familiar with what Mozilla's policies were in 2009, and I know
there was a great deal of effort to draw attention to undisclosed
intermediates in 2016 -- that effort is what drew attention to these

But I think it's important to note that this relationship was not widely
understood or publicly discussed as part of the Mozilla trusted root
program, between 2009 and 2016.

In February 2016, Eric Mill prompted discussions with Symantec and the
> community about why the cross-certification resulted in some FPKI certs
> being trusted in browsers at https://github.com/18F/fpki-testing/issues/1.
> That discussion highlighted that browsers didn't process certificate policy
> extensions content during path building, while FPKI made extensive use of
> policy processing.

The discussion above is long and interesting, and definitely does highlight
that browsers don't process certificate policy extensions. The discussion
shows that this was a surprise to some participants. However, I would not
necessarily expect this to be a surprise to all participants in the web PKI

We had already engaged with FPKI personnel to address this concern, and
> further engaged to determine if one-way cross-certification from FPKI to
> Symantec was sufficient, such that we could remove the cross-certification
> from Symantec to FPKI. On July 5, 2016,  FPKI notified Symantec that the
> cross-certificate, which was set to expire July 31, 2016, would not be
> required.

> Because we have a responsibility to our customers to ensure their
> businesses remain uninterrupted, we knew that communication and giving them
> adequate time to adjust to the unscheduled change in trust was critical. In
> order to effect minimal disruption, we allowed the cross-certificate to
> expire on July 31, 2016, rather than revoking it sooner.

Identrust was in a nearly identical position, having been asked about an
undisclosed cross-signature of the FPKI at the same time as it was pointed
out to Symantec:


I am not aware what differences may exist between Symantec's and
Identrust's arrangements with the Federal PKI. However, Identrust made a
prompt decision and revoked the certificate by February 19th.

-- Eric

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

Eric Mill
Senior Advisor, Technology Transformation Service, GSA
eric.m...@gsa.gov, +1-617-314-0966
dev-security-policy mailing list

Reply via email to