Re: Symantec Response L

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

Re: Symantec Response L

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

Re: Symantec Response L

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

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

Re: Symantec Response L

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-

Re: Symantec Response L

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.

Re: Symantec Response L

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

Re: Symantec Response L

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

Re: Symantec Response L

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

Re: Symantec Response L

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

Re: Symantec Response L

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

Re: Symantec Response L

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

Re: Symantec Response L

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

Re: Symantec Response L

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.

Re: Symantec Response L

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

Re: Symantec Response L

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

Re: Symantec Response L

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

Symantec Response L

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