Re: Symantec Response L

[Peter Bachman via dev-security-policy]

I probably need some additional information to see if my partners can 
effectively share PHI at LOA 3 and I don't want to burden the list on whether 
the healthcare use cases defined by the Federal Health Architecture is covered 
by ACES 2017 Jan policy. It's very important that the community agreed on LOA 3 
for healthcare providers and LOA 2 for patients. It's not an issue about 
validating to domain names. That's what I meant about separating Internet from 
USperson citizen use cases. 

This goes back to 2004 when enabling legislation was created to apply the 
Internet to Healthcare and create secure services to exchange information. 
Eventually, years later the FHA set down with Direct Project certificate 
requirements, however the two models are different in that one is based on a 
end user STA, and a different model that uses a MITM intentionally that 
requires a different trust layer under HIPAA called a business associate 
agreement. The LOA3 Direct STA to STA does not require an additional trust 
framework beyond the Federal Bridge. Typically the bridge only deals with cross 
certification of CAs. So to meet the requirements the individual user 
certificate needs to use a root that can chain through the bridge and have a 
separate signing and encryption certificate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response L

[Myers, Kenneth (10421) via dev-security-policy]

IdenTrust operates an issuing CA for the US Federal Government - General 
Services Administration - Access Certificates for Electronic Services Program 
(ACES). It is a government sponsored PKI program separate from the Non-Federal 
issuer programs under the Federal Bridge.

ACES certificates are can be used for identity (people signature and 
authentication) or devices (server authentication). The individual ACES vendors 
write their own CPS and the IdenTrust CPS meets CAB Forum BR and through a 
WebTrust for SSL audit (https://cert.webtrust.org/SealFile?seal=2106=pdf). 
IdenTrust operates their ACES issuing CA with a path to both the Federal Common 
Policy CA and an IdenTrust public root. Since the issuing CA is certified with 
the Federal PKI and not the root, there is no path to the IdenTrust public root 
 from the rest of the Federal PKI.

I think this and DigiCert are the only two examples of a PKI hierarchy with the 
Federal PKI that do not allow Federal PKI certificates to validate to the 
public root of the company. This testing was outlined in the FPKI SSL testing 
on github. https://github.com/18F/fpki-testing

>From a user experience perspective, companies (and government agencies) should 
>use SSL certificates that fit their requirements. Trying to explain how to use 
>PKI is hard enough so having a statement that says "Don't use this PKI except 
>where and when in this configuration" just adds to the confusion. I'd say that 
>statement fit the needs of the overall federal government effort in ensuring 
>federal websites used SSL certificates which offered a consistent user 
>experience.

@Peter -  But the policy mapping between these different use cases is perhaps 
overly complex and certainly not user friendly. "
- Do you mean the policy mapping used by ACES and the Federal PKI?

This specific IdenTrust CA does not have a cross-certificate back to the 
Federal PKI. It has two distinct validation paths to two different roots; 
Federal Common Policy and the IdenTrust Public Root. Only IdenTrust issued ACES 
Federal PKI certificates can validate with Mozilla.
NOTICE: Protiviti is a global consulting and internal audit firm composed of 
experts specializing in risk and advisory services. Protiviti is not licensed 
or registered as a public accounting firm and does not issue opinions on 
financial statements or offer attestation services. This electronic mail 
message is intended exclusively for the individual or entity to which it is 
addressed. This message, together with any attachment, may contain confidential 
and privileged information. Any views, opinions or conclusions expressed in 
this message are those of the individual sender and do not necessarily reflect 
the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, 
printing, copying, retention, disclosure or distribution is strictly 
prohibited. If you have received this message in error, please immediately 
advise the sender by reply email message to the sender and delete all copies of 
this message. Thank you.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response L

[Peter Bachman via dev-security-policy]

That very useful visualization can seen in Chrome and validates against the 
Identrust ACES 2 root.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response L

[Peter Bachman via dev-security-policy]

The 2017 ACES CP excluding anything other than citizen to E-gov breaks certain 
use cases that are outside the scope of Mozilla, but not from the standpoint of 
a fully functional commercial  c=US structure which I have developed since 1996 
since I reached an agreement with GSA on how to proceed after managing the  
c=US pilot and implementing X.509 for the National Labs in the Directory.

Specifically it blocks the development of a functional national patient and 
provider Directory structure in which relying parties require fully valid cross 
certified trust chains that was already developed with HHS. 

Invalid patient identity is at the heart of one of the leading causes of 
mortality in the US. Not reaching consensus on equipping end users with low 
cost affordable PKI in addition to browser security policy puts profit over 
human rights.

The only rational reason I can see for such a policy is to MITM at will medical 
records under the 702 Authorities, since end user implementation of PKI based 
tecnology in an end to end manner precludes business level meddling and trust, 
replaced by the original Diffie concept. As we know this is already the policy 
of the IETF and IAB to encrypt everything. But the policy mapping between these 
different use cases is perhaps overly complex and certainly not user friendly. 

Also the Blue Button MU2 used ACES in their trust bundle at one point and I 
checked yesterday for medical providers that already attested to MU2 SMTP/SMIME 
compliance and received Federal money under the recovery stimulus package and 
that's not limited to just the VA but the VA has used this very effectively. 

Browsers of course don't typically implement bi-directional TLS authenticating 
the client which is very useful in use cases related to maintaining data 
integrity in disaster situations for logging.

i checked the Identrust site and their ACES CP had poor user documentation with 
CP dated 2015. That's when I subsequently found your information which was up 
to date and very useful.

I see that the only remaining bug issue was to drop the cross certificate so 
that Mozilla users could not incorrectly validate,
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response L

[Eric Mill via dev-security-policy]

For the benefit of the list, I'm the author of that text and that quote is
from this page, which is maintained by the General Services Administration
(though again, not by the Federal PKI team):

https://https.cio.gov/certificates/#does-the-us-
government-operate-a-publicly-trusted-certificate-authority%3f

The intended audience is federal agencies, and the intended takeaway is
that certificates from the Federal Common Policy CA should not be used for
TLS/HTTPS services where the expected client base is "the general public",
since the Federal PKI is not a member of the Mozilla root program.

Certificates from the Federal PKI can obviously be used where the client
base can be expected to trust its root CA, and there are many such uses of
the Federal PKI.

-- Eric

On Sun, Apr 16, 2017 at 8:50 PM, Peter Bachman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Since we use ACES certificates for sending healthcare information in a way
> that mimimizes MITM, I was surprised to read the following.
>
>
> "The Federal PKI has cross-certified other agencies and commercial CAs,
> which means their certificates will be trusted by clients that trust the
> Federal PKI. However, none of these roots are publicly trusted. Even when a
> publicly trusted commercial CA is cross-certified with the Federal PKI,
> they maintain complete separation between their publicly trusted
> certificates and their Federal PKI cross-certified certificates.
>
> As a result, there is not currently a viable way to obtain an individual
> certificate for use in TLS/HTTPS that is issued or trusted by the Federal
> PKI, and also trusted by the general public."
>
> Source CIO Council
>
>
>
> The new ACES CP dated Jan 17 2017 does not assure public use of the ACES
> root.
>
> ___
> 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 <(617)%20314-0966>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response L

[Peter Bachman via dev-security-policy]

Since we use ACES certificates for sending healthcare information in a way that 
mimimizes MITM, I was surprised to read the following.


"The Federal PKI has cross-certified other agencies and commercial CAs, which 
means their certificates will be trusted by clients that trust the Federal PKI. 
However, none of these roots are publicly trusted. Even when a publicly trusted 
commercial CA is cross-certified with the Federal PKI, they maintain complete 
separation between their publicly trusted certificates and their Federal PKI 
cross-certified certificates.

As a result, there is not currently a viable way to obtain an individual 
certificate for use in TLS/HTTPS that is issued or trusted by the Federal PKI, 
and also trusted by the general public."

Source CIO Council



The new ACES CP dated Jan 17 2017 does not assure public use of the ACES root. 

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

Re: Symantec Response L

[Martin Heaps via dev-security-policy]

On Tuesday, 11 April 2017 22:09:39 UTC+1, Eric Mill  wrote:
> On Tue, Apr 11, 2017 at 6:37 AM, Gervase Markham via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> 
> An (interactive) picture might help illustrate what I'm pointing to. This
> is the Federal PKI:
> https://fpki-graph.fpki-lab.gov
> 

Just as an aside: 

Fascinating as this graphic is, loading it gives me a "Secure Connection 
Failure" (SEC_ERROR_CERT_BAD_ACCESS_LOCATION) as well as an OCSP ERROR in its 
revokation status.  

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

Re: Symantec Response L

[Myers, Kenneth (10421) via dev-security-policy]

I don't know if it was mentioned elsewhere but Symantec had an MOA with the 
Federal PKI which required cross-certificates. If Symantec revoked it, the MOA 
would also have been violated which would have severed the trust with the 
Federal PKI and Symantec customers.

To the particular IdenTrust CA, it was part of a different program still under 
the Federal PKI (the General Services Administration Access Certificates for 
Electronic Services Program). Coincidentally, at the same time the cross 
certificate was brought up, the ACES CP was updated to not allow 
cross-certificates. Just a coincidence which potentially led to the shorter 
timeline in revocation.

Kenneth Myers
Protiviti | Government Solutions | Manager
Alexandria | +1 571-366-6120<tel:+1%20571-366-6120> | 
kenneth.my...@protiviti.com<mailto:kenneth.my...@protiviti.com>
Connect: LinkedIn<https://www.linkedin.com/in/kennethmy> | Thought Leadership: 
Protiviti.com<http://www.protiviti.it/en-US/Pages/Insights.aspx>

On Apr 12, 2017, at 14:42, 
"dev-security-policy-requ...@lists.mozilla.org<mailto:dev-security-policy-requ...@lists.mozilla.org>"
 
<dev-security-policy-requ...@lists.mozilla.org<mailto:dev-security-policy-requ...@lists.mozilla.org>>
 wrote:

Re: Symantec Response L
NOTICE: Protiviti is a global consulting and internal audit firm composed of 
experts specializing in risk and advisory services. Protiviti is not licensed 
or registered as a public accounting firm and does not issue opinions on 
financial statements or offer attestation services. This electronic mail 
message is intended exclusively for the individual or entity to which it is 
addressed. This message, together with any attachment, may contain confidential 
and privileged information. Any views, opinions or conclusions expressed in 
this message are those of the individual sender and do not necessarily reflect 
the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, 
printing, copying, retention, disclosure or distribution is strictly 
prohibited. If you have received this message in error, please immediately 
advise the sender by reply email message to the sender and delete all copies of 
this message. Thank you.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response L

[Eric Mill via dev-security-policy]

On Wed, Apr 12, 2017 at 4:53 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 11/04/17 22:08, Eric Mill wrote:
> > I'll leave it to others to opine on the severity of the mistake and the
> > quality of the response, but I do want to at least properly communicate
> the
> > impact.
>
> Thank you. I have updated my write-up for Issue L.
>

Great. I see one inaccuracy in the text there right now:

When this was drawn to their attention, Symantec did not revoke the
cross-sign certificate under discussion, instead allowing it to expire
(less than a month later).


The cross-signature was brought to Symantec's attention in mid-February
2016. The certificate expired at the end of July 2016. The current text
says "less than a month later".

I believe that "less than a month later" is meant to reference the time
between when Symantec obtained concurrence from the Federal PKI about
undoing the cross-signature, and when the certificate expired.

Identrust revoked their similar cross-signature in mid-late February, a
week or so after being notified of the issue by Richard Barnes (then of
Mozilla).

-- Eric


>
> Gerv
>
> ___
> 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

Re: Symantec Response L

[braddockmewshoa--- via dev-security-policy]

To add to Eric's response, the U.S. Federal PKI was built and is dependent on 
Policy OID validation. There are 25 OIDs registered with NIST that define 
different assurance levels and is heavily focused on people certificates 
although it is a broad use PKI for the U.S. Federal Government (USG). Devices 
were never a big use case until HTTPS went mainstream and agencies starting 
leveraging their existing PKI to issue Server Auth certificates. There was a 
growing divide between Federal PKI policy and CAB Forum / Browsers 
(specifiallly with the interpretation of RFC 5280 and Intermediate CA EKU use) 
that the Federal Government is now trying to correct with the new NPE CP 
development (https://github.com/uspki/policies). 

The USG even set up a testing program (FIPS 201 Evaluation Program) to test PKI 
enabled applications and ensure they met Federal PKI requirements for policy 
OID validation which still exists today. It is mainly focused on non-mainstream 
products like physical access systems, SCVP, logical access appliances, and a 
couple other categories. NIST developed a PKI test suite 
(http://csrc.nist.gov/groups/ST/crypto_apps_infra/pki/pkitesting.html) to test 
5280, but it is kind of dated. The FIPS 201 program is updating and integrating 
the NIST test suite items. I'm not sure if it ever tested email, browsers, or 
other mainstream type programs and now cloud-based applications. That seems 
like a gap in ensuring policy validation worked in products and keeping the 
Federal PKI informed of new events in the web PKI. Adobe is the only mainstream 
application I know of or heard of that does policy validation for PKI vendor 
supplied policies.

In relation to Symantec, the Federal Bridge was established as an 
interoperability hub using OID validation of strong to low assurance people 
credentials which were intermingled with device credentials (the focus 
primarily being on people). If you ask anyone in the Federal PKI they would say 
I only accept XX.XX OID and don't worry about other certificates. This is a 
potential issue for products that only do path validation though. That doesn't 
address any of the questions directed at Symantec and why the cross-cert wasn't 
disclosed. If browsers did policy validation would it have been a problem? I 
can't answer that.

Here is an overview document of how the U.S. Federal PKI was designed and built 
(https://www.idmanagement.gov/IDM/servlet/fileField?entityId=ka0t000TNRIAA4=File__Body__s)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response L

[Gervase Markham via dev-security-policy]

On 11/04/17 22:08, Eric Mill wrote:
> I'll leave it to others to opine on the severity of the mistake and the
> quality of the response, but I do want to at least properly communicate the
> impact.

Thank you. I have updated my write-up for Issue L.

Gerv

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

Re: Symantec Response L

[Eric Mill via dev-security-policy]

On Tue, Apr 11, 2017 at 6:37 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> On 11/04/17 04:45, Eric Mill wrote:
>
> > 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.
>
> And you think that's bad?
>

An (interactive) picture might help illustrate what I'm pointing to. This
is the Federal PKI:
https://fpki-graph.fpki-lab.gov

There's something like 200 civilian, military, and non-government CAs in
there, connected through a huge number of bridges and cross-signatures.
Despite the name, the Federal PKI contains more than the federal government
-- within that graph are signatures bridging over to sector-wide PKIs such
as SAFE-BioPharma. In the center is the Federal Common Policy CA, which
ultimately everything can be chained up to.

For the time that the cross-signature was active (the one in question is
here - https://crt.sh/?id=12638543 and was ~8 months beginning in December
2015), all 200 of those CAs were capable of issuing a certificate that
would be technically trusted by users of the Mozilla root store. I haven't
looked to see whether there were other cross-signatures issued by VeriSign
or Symantec since the cross-signer's parent CA was admitted to the Mozilla
root store around 2009.

All that's been said here by Symantec on this issue's impact is that the
discussion around this made it clear that browsers don't respect
certificate policy identifiers (OIDs). Those policy identifiers would have
been, as I understand it, the sole technical constraint capable of
protecting users of the Mozilla trust store from mis-issuance from any of
these 200 CAs, had clients respected them.

I'll leave it to others to opine on the severity of the mistake and the
quality of the response, but I do want to at least properly communicate the
impact.

-- Eric


> There were several discussions about including the FPKI roots during
> this time, and about the problems that might cause. I might expect
> someone reading those, who knew that we already trusted bits (or all?)
> of the FPKI due to their actions, to say something...
>
> Gerv
> ___
> 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 <(617)%20314-0966>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Symantec Response L

[Ryan Sleevi via dev-security-policy]

On Tue, Apr 11, 2017 at 6:31 AM, Gervase Markham  wrote:

> Hi Ryan,
>
> On 10/04/17 17:03, Ryan Sleevi wrote:
> > 2) You stated that "browsers didn't process certificate policy extensions
> > content during path building". This fails to clarify whether you believe
> it
> > was a Baseline Requirements violation, which makes no such statements
> > regarding policy building. Further, no such browser has, except for EV,
> > made use of any policy IDs beyond path building.
>
> Can you clarify: are you asking if Steve believes that the BRs require
> _browsers_ to do such processing of certificate policy extensions?
>

No. I'm asking if Symantec, through Steve, is intending to sound like a
Scooby Doo villain , or
whether it's merely accidental that this reads as "I would have gotten away
with it, if not for you meddling browsers"

More specifically, Symantec has failed to respond as to whether or not they
agree with the facts presented and, if so, whether or not this represents a
Baseline Requirements violation, as suggested. The reply could be read as
suggesting "This was meaningfully technically controlled, it is simply that
browsers failed to enforce that."

This is problematic on multiple fronts, least of all because policy mapping
and IDs have never been a meaningful form of technical control in the Web
PKI, and so I'm hoping for further elaboration on the statement to ensure
it is it not misinterpreted.


> Or if he believes that cross-certifying into a hierarchy which relies
> upon such extensions is a BR violation?
>

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

Re: Symantec Response L

[Eric Mill via dev-security-policy]

On Tue, Apr 11, 2017 at 6:37 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Eric,
>
> Perhaps you are being intentionally non-directive, in which case perhaps
> you can't answer my questions, but:
>

Yes, I am being intentionally non-directive. I'll leave the opinions to
others with more historical familiarity with the relevant programs and
policies.

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

Re: Symantec Response L

[Gervase Markham via dev-security-policy]

Hi Ryan,

On 10/04/17 17:03, Ryan Sleevi wrote:
> 2) You stated that "browsers didn't process certificate policy extensions
> content during path building". This fails to clarify whether you believe it
> was a Baseline Requirements violation, which makes no such statements
> regarding policy building. Further, no such browser has, except for EV,
> made use of any policy IDs beyond path building.

Can you clarify: are you asking if Steve believes that the BRs require
_browsers_ to do such processing of certificate policy extensions?

Or are you asking him if he believes that including such extensions in
the cross-cert was a BR violation?

Or if he believes that cross-certifying into a hierarchy which relies
upon such extensions is a BR violation?

Or something else? :-)

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

Re: Symantec Response L

[Eric Mill via dev-security-policy]

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

Re: Symantec Response L

[Ryan Sleevi via dev-security-policy]

Hi Steve,

Quick questions:

1) You identified that Symantec believed that it was a responsibility to
ensure your customers' businesses remain interrupted.
  a) What is Symantec's process for determining which of these concerns
(Baseline Requirements vs customer business) has priority?
  b) Has that process changed in response to this incident?

2) You stated that "browsers didn't process certificate policy extensions
content during path building". This fails to clarify whether you believe it
was a Baseline Requirements violation, which makes no such statements
regarding policy building. Further, no such browser has, except for EV,
made use of any policy IDs beyond path building.
  a) Does Symantec believe this was a Baseline Requirements violation?
  b) If so, why did Symantec fail to revoke this certificate, consistent
with Baseline Requirements, Section 4.9.1.2, Item 5?
  c) If so, why did Symantec fail to revoke this certificate, consistent
with Baseline Requirements, Section 4.9.1.2, Item 10?

3) Recognizing this risk, Symantec's Terms of Use under the Baseline
Requirements, Section 9.6.3, the CA is contractually obligated to include a
series of requirements, including Item 8, "An acknowledgement and
acceptance that the CA is entitled to revoke the certificate immediately if
the Applicant were to violate the terms of the Subscriber Agreement or
Terms of Use"
  a) Does Symantec's Subscriber Agreement or Terms of Use with the FPKI
include an obligation to issue consistent with Symantec's CP/CPS?
  b) Does Symantec's relevant CP/CPS state that it complies with the
Baseline Requirements?
  c) If so, does Symantec believe that such a requirement flows down to
subordinate CAs?
  d) If not, why not?

4) What steps has Symantec taken, if any, with regard to its Subscriber
Agreements or Terms of Use in light of this?

5) What steps has Symantec taken, if any, to ensure there is appropriate
transparency regarding Symantec's responsibility to their customers versus
responsibility to Root Program requirements?
  a) Specifically, what steps has Symantec taken to ensure all necessary
and sufficient information to independently evaluate that tradeoff is
available publicly?
  b) Specifically, what steps has Symantec taken to ensure that if one or
more Root Programs disagree with their assessment, that appropriate steps
can and will be taken by Symantec?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Symantec Response L

[Steve Medin via dev-security-policy]

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.

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. 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy