Symantec Response L

[Steve Medin]

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.

[Ryan Sleevi]

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?

[Eric Mill]

On Mon, Apr 10, 2017 at 10:56 AM, Steve Medin via dev-security-policy <
dev-secur...@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-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



--
Eric Mill
Senior Advisor, Technology Transformation Service, GSA
eric...@gsa.gov, +1-617-314-0966

[Gervase Markham]

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

[Gervase Markham]

Hi Eric,

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

On 11/04/17 04:45, Eric Mill wrote:
> 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

And you think that the fact that the root had cross-certified the FPKI
was a relevant fact which should have been brought to Mozilla's attention?

> 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

And you think it should have done?

> 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.

In 2009, we did not have any policies relating to disclosure of
intermediates. The relevant policy at the time was 1.2:
https://wiki.mozilla.org/CA:CertificatePolicyV1.2
As you can see, requirements were relatively limited.

(See https://wiki.mozilla.org/CA:CertPolicy for the full history of our
policy.)

> 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?

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

[Eric Mill]

On Tue, Apr 11, 2017 at 6:37 AM, Gervase Markham via dev-security-policy <
dev-secur...@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

[Ryan Sleevi]

On Tue, Apr 11, 2017 at 6:31 AM, Gervase Markham <ge...@mozilla.org> 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 <https://www.youtube.com/watch?v=hXUqwuzcGeU>, 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.

[Eric Mill]

On Tue, Apr 11, 2017 at 6:37 AM, Gervase Markham via dev-security-policy <
dev-secur...@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-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



--
Eric Mill
Senior Advisor, Technology Transformation Service, GSA

eric...@gsa.gov, +1-617-314-0966 <(617)%20314-0966>

[Gervase Markham]

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

[braddoc...@gmail.com]

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=ka0t0000000TNRIAA4&field=File__Body__s)

[Kurt Roeckx]

On 2017-04-12 13:42, braddoc...@gmail.com wrote:
> If browsers did policy validation would it have been a problem? I
can't answer that.

So I guess that would be something like require one of the CAB policy
IDs for which validation that happened? (2.23.140.1.2.1 for DV,
2.23.140.1.2.2 for OV, 2.23.140.1.2.3 for IV, 2.23.140.1.1 for EV). And
that if none of those are present it should reject the certificate?

I would clearly be in favor of those policy IDs to be always present.
But there were no such policy IDs in the past, and they're still not
required.

The FPKI now seems to use Certificate Policies, not Policy Constraints.
If they used Policy Constraints, and the browsers enforced the above
policies, it would be obvious that the FPKI couldn't issue certificates
that could be used to authenticate servers. I think we need both to
prevent it.

You indicate that they started using FPKI for server authentication. I
doubt that they have been audited to follow the BR requirements, so I
think it would be good that we reject them.


Kurt

[Eric Mill]

On Wed, Apr 12, 2017 at 4:53 AM, Gervase Markham via dev-security-policy <
dev-secur...@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

[Myers, Kenneth (10421)]

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> | Kennet...@Protiviti.com<mailto:Kennet...@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-...@lists.mozilla.org<mailto:dev-security-...@lists.mozilla.org>" <dev-security-...@lists.mozilla.org<mailto:dev-security-...@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.

[Martin Heaps]

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-secur...@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.

[Peter Bachman]

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.

[Eric Mill]

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

[Peter Bachman]

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,

[Peter Bachman]

That very useful visualization can seen in Chrome and validates against the Identrust ACES 2 root.

[Myers, Kenneth (10421)]

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&file=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.

[Myers, Kenneth (10421)]

@Martin

Your error may be related to OCSP checking in Java. The word I received from IdenTrust was the IdenTrust Public Root is not included in the latest Java deployment, but is/may be scheduled in the next release.

STATUS: Good (not revoked)
OCSP ERROR: Exception: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target [https://aces.ocsp.identrust.com]

[Peter Bachman]

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.