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 agree
@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.Valid
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 c
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
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 a
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-auth
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.
H
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://
hmy> | 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>"
mailto:dev-security-policy-requ...@lists.mozilla.org>
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
On 2017-04-12 13:42, braddockmews...@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
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). D
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
__
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 Mozill
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 Requireme
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'l
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 th
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 buildi
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 responsibil
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 tha
20 matches
Mail list logo
