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 purchase: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/0xJClZlkO3w/CXjlamuOO-sJ 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"): https://bugzilla.mozilla.org/show_bug.cgi?id=484901 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: https://web.archive.org/web/20090612085619/http://www.verisign.com/repository/CPSv3.8.1_final.pdf 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 cross-signatures. 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 ecosystem. 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: https://bugzilla.mozilla.org/show_bug.cgi?id=1037590#c21 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
