Thanks Kenneth.  Sounds complicated.  ;-)

Are "federal relying parties" impacted by Mozilla's OneCRL?
If not, then is it worth considering revoking the Symantec cross-certificate via OneCRL but _not_ revoking it via CRL/OCSP?

On 28/06/16 22:48, Myers, Kenneth (10421) wrote:
Thanks Rob. I came to the same conclusion.

I am a contractor supporting the Federal PKI and do not speak on their behalf, 
but would like to help clear up some misconceptions around the Federal PKI.

1) The Symantec Cross Cert has not been revoked.
The Federal PKI is an identity federation based on mutual trust of people. Multiple 
federal and non-federal organizations coming together based on common identity 
assurances for the benefit of G2G, C2G, and B2G digital transactions. Every 
affiliate within the Federal PKI adheres to the Federal Bridge CP which is based 
off NIST and international standards and other federal laws around identity 
management and information security to establish trusted operations and the 
criteria for a level of assurance. Multiple federal mandates and laws exist for the 
use of the Federal Bridge to accept commercial PKI credentials for electronic 
authentication and digital signature (mentioned below). Participating PKIs enter 
into a legal agreement (MOA) with the federal government to establish that trust 
and define the requirements around mutual recognition (Application for cross 
certification, 
https://www.idmanagement.gov/IDM/servlet/fileField?entityId=ka0t0000000TNS6AAO&field=File__Body__s).
 T
 his is evidenced through the exchange of certificates between organizational PKIs 
(In this case between the Federal Bridge and the Symantec CA) after a passing audit 
report. The FPKI audit requirements are based on a direct CP to CPS analysis with 
annual core requirements which provides improved assurance that affiliates continue 
to operate according to the Federal Bridge CP 
(https://www.idmanagement.gov/IDM/servlet/fileField?entityId=ka0t0000000TNYYAA4&field=File__Body__s).
 Without the exchange, there is no mutual trust. Symantec is a valued partner 
within the Federal PKI supporting nine non-federal organizations with 33 
operational CAs under the Federal PKI non-federal issuer program. To revoke the 
Symantec certificate, the certificates issued by organizations under Symantec would 
no longer be trusted by federal relying parties. Symantec is resolving the issue 
with the Federal PKI Policy Authority, but the risk to revoking the certificate is 
still uncertain.

2) It is not acceptable for CAs trusted by the Mozilla Program to cross-sign 
with the Federal Bridge (From Richard Barnes) There is a fundamental and 
growing philosophical difference between the Federal PKI (based on strong 
assurance of people identities for general use) and the PKI industry (assurance 
of device identities for specific uses). The Federal PKI continues to work to 
update our requirements to meet Mozilla program acceptance, but it is a 
difficult path. The Federal PKI is a heavily regulated environment governed by 
its members, federal regulations, and operated according to NIST and 
international standards. The Federal PKI is composed of:
- 19  affiliates
- 254 CAs
- 71 issuing partners
- 93 federal agencies
- >five million users
- >22 million active certificates issued to both people and devices

This does not include the federal relying party and commercial applications 
which accept FPKI certificates for authentication or other purposes. It is 
important to the Federal PKI that theses certificates are trusted to meet 
multiple federal drivers around electronic authentication/digital signature 
(Digital Signature and Electronic Authentication Act, Electronic Signatures in 
Global and National Commerce Act, and Government Paperwork Elimination Act) as 
well as PKI interoperability (E-Government Act) and strong authentication 
(Homeland Security Presidential Directive-12, White House Cybersecurity 
Strategy and Implementation Plan, and White House Cybersecurity National Action 
Plan) requirements. In some cases it is not a simple process to update the 
Federal PKI Certificate Policies, but we are very close to meeting the last two 
Mozilla requirements for our application which include incorporating CAB Forum 
BR and Mozilla CP requirements and publicly posting CP, CPS, and audi
t
 letters for the Shared Service Providers. Even small changes have a lasting 
impact to both federal budget and operational practices and must be understand.

If you're interested in a closer look, I've attached a white paper of the FPKI 
Infrastructure and Architecture 
(https://www.idmanagement.gov/IDM/s/document_detail?Id=kA0t0000000KyroCAC).

Ken

-----Original Message-----
From: Rob Stradling [mailto:rob.stradl...@comodo.com]
Sent: Monday, June 27, 2016 09:01
To: Myers, Kenneth (10421) <kenneth.my...@protiviti.com>; 
dev-security-policy@lists.mozilla.org
Subject: Re: Intermediate certificate disclosure deadline in 2 weeks

On 27/06/16 12:13, Myers, Kenneth (10421) wrote:
The Federal PKI has a tool to help identify trust paths, 
FPKI-graph.fpki-lab.gov<https://urldefense.proofpoint.com/v2/url?u=http-3A__fpki-2Dgraph.fpki-2Dlab.gov&d=CwIC-g&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=DlNVTZg70U3he7Kt-304vEDqF9fDGX8jfPq5RnStn50&s=pqUpzJZnt7pQ1HsJr6dBrqifrxrdjl-iFkah0G685TY&e=
 >.

I can do a true-up between the Mozilla CA list and FPKI trust paths to help 
identify which path may be causing the issue.

Hi Kenneth.  It would be great if you could do that, especially if there are 
any trust paths that are not yet known to CT / crt.sh.

I've just run some analysis on the crt.sh DB.  It's the following 2 
cross-certificates that are of interest:

https://urldefense.proofpoint.com/v2/url?u=https-3A__crt.sh_-3Fid-3D9114292&d=CwIC-g&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=DlNVTZg70U3he7Kt-304vEDqF9fDGX8jfPq5RnStn50&s=diEBbsWTZ7Zo0d_TwT8WGR-3EwDoH469HqxCqlif53k&e=
   Issuer: IdenTrust ACES CA 1
   Subject: Federal Bridge CA 2013
   OneCRL: Already revoked.
   Salesforce: Not yet disclosed.

https://urldefense.proofpoint.com/v2/url?u=https-3A__crt.sh_-3Fid-3D12638543&d=CwIC-g&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=DlNVTZg70U3he7Kt-304vEDqF9fDGX8jfPq5RnStn50&s=JB_38bUAYT_Hl4B58oExVy_P8sXMISQGtZhyoyoSx2U&e=
   Issuer: VeriSign Class 3 SSP Intermediate CA - G2
   Subject: Federal Bridge CA 2013
   OneCRL: Not yet revoked.
   Salesforce: Not yet disclosed.

If/when both of these intermediates are disclosed to Salesforce as "revoked", crt.sh 
should (once Mozilla have updated the CSV reports) detect the FPKI trust paths as 
"revoked".

Richard Barnes wrote on 23rd:
"It should be clear by this point that it is not acceptable for CAs trusted by the 
Mozilla program to cross-sign the Federal Bridge"

That Symantec cross-cert has not yet even been revoked via CRL!

Kenneth Myers
Supporting the GSA Federal PKI Management Authority 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.link
edin.com_in_kennethmy&d=CwIC-g&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAt
E256go&r=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=DlNVTZg70U3he7K
t-304vEDqF9fDGX8jfPq5RnStn50&s=yxnEOhIxqEJxYCndopgWxHD8FxhHFsjtBlvztmv
whhM&e= > | Thought Leadership:
Protiviti.com<http://www.protiviti.it/en-US/Pages/Insights.aspx>

On Jun 24, 2016, at 08:01, 
"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:

-----Original Message-----
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Thursday, June 23, 2016 3:35 PM
To: Eric Mill <e...@konklone.com<mailto:e...@konklone.com>>
Cc: Ben Wilson
<ben.wil...@digicert.com<mailto:ben.wil...@digicert.com>>; Kurt Roeckx
<k...@roeckx.be<mailto:k...@roeckx.be>>; Richard Barnes
<rbar...@mozilla.com<mailto:rbar...@mozilla.com>>; Jeremy Rowley
<jeremy.row...@digicert.com<mailto:jeremy.row...@digicert.com>>; Steve
<steve.me...@gmail.com<mailto:steve.me...@gmail.com>>;
mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-secur
ity-pol...@lists.mozilla.org>; Kathleen Wilson
<kwil...@mozilla.com<mailto:kwil...@mozilla.com>>; Rob Stradling
<rob.stradl...@comodo.com<mailto:rob.stradl...@comodo.com>>
Subject: Re: Intermediate certificate disclosure deadline in 2 weeks

DigiCert didn't cross-sign the Federal PKI with their Mozilla trusted CAs.

I'm sure Ben will tell me I have my terminology wrong, but DigiCert basically 
operates two PKIs:
- DigiCert Public WebPKI
- DigiCert Shared FederatedPKI

The first is a set of CAs that are in the Mozilla program and CAs signed by the 
Mozilla program.  The second is a set of CAs that are signed by the US Federal 
PKI; they are not in the Mozilla program.

The problem is that some non-DigiCert CA int he Mozilla program signed the US 
Federal PKI.  The DigiCert Shared FederatedPKI is now brought in via that 
signature, with which they had nothing to do.

On Thu, Jun 23, 2016 at 1:41 PM, Eric Mill 
<e...@konklone.com<mailto:e...@konklone.com>> wrote:
Peter, I think I get what you're saying about this being a different
category of cross-sign, but could you spell out explicitly how this
differs from e.g. the Identrust cross-sign issue that Richard linked to?

-- Eric

On Thu, Jun 23, 2016 at 4:39 PM, Ben Wilson 
<ben.wil...@digicert.com<mailto:ben.wil...@digicert.com>> wrote:

That's correct.

-----Original Message-----
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Thursday, June 23, 2016 2:39 PM
To: Ben Wilson
<ben.wil...@digicert.com<mailto:ben.wil...@digicert.com>>
Cc: Eric Mill <e...@konklone.com<mailto:e...@konklone.com>>; Kurt
Roeckx <k...@roeckx.be<mailto:k...@roeckx.be>>;
Richard Barnes <rbar...@mozilla.com<mailto:rbar...@mozilla.com>>;
Jeremy Rowley
<jeremy.row...@digicert.com<mailto:jeremy.row...@digicert.com>>; Steve
<steve.me...@gmail.com<mailto:steve.me...@gmail.com>>;
mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-secur
ity-pol...@lists.mozilla.org>; Kathleen Wilson
<kwil...@mozilla.com<mailto:kwil...@mozilla.com>>; Rob Stradling
<rob.stradl...@comodo.com<mailto:rob.stradl...@comodo.com>>
Subject: Re: Intermediate certificate disclosure deadline in 2 weeks

On Thu, Jun 23, 2016 at 11:45 AM, Ben Wilson
<ben.wil...@digicert.com<mailto:ben.wil...@digicert.com>>
wrote:
Another issue that  needs to be resolved involves the Federal Bridge
CA 2013 (?Federal Bridge?).  When a publicly trusted sub CA
cross-certifies the Federal Bridge, then all of the CAs
cross-certified by the Federal Bridge
are trusted.   The chart 
(https://urldefense.proofpoint.com/v2/url?u=https-3A__crt.sh_mozilla-2Ddisclosures&d=CwICAg&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=1UjPfxX9IFMWqfbTaQcpveBJs1JYI4p_EuZaqww5tuQ&s=uEywlyUMGlYbep6vFNZz0xasu6IojurxbFc_8QrcDW0&e=
 ) then
captures
all ?non-publicly-trusted? sub CAs.  For instance, the following CAs
are now caught up in the database,  but there is no way to input them
(or CAs subordinate to them) into Salesforce because only the CA that
cross-certified the Federal Bridge has access to that  certificate
chain in Salesforce. In otherwords, I don?t have access to input the
DigiCert Federated ID CA-1 or its sub CAs.


Ben,

Correct me if I'm wrong, but the DigiCert CA you mention is part of a
different PKI from the DigiCert public roots in Mozilla, right?  The
only reason that it is showing in the list is because a non-DigiCert
CA cross-signed the Federal PKI and the Federal PKI cross-signed the
DigiCert CA in question, correct?

Thanks,
Peter





--
konklone.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__konkl
one.com&d=CwIC-g&c=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go&r=v6QfM
BgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=DlNVTZg70U3he7Kt-304vEDqF9fDG
X8jfPq5RnStn50&s=c1rqzKNHVjlgTVwNLW7gmcTVRl_FBL23W8HwCSj5YQ4&e= > |
@konklone
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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.mozilla.org
_listinfo_dev-2Dsecurity-2Dpolicy&d=CwIC-g&c=19TEyCb-E0do3cLmFgm9ItTXl
bGQ5gmhRAlAtE256go&r=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY&m=DlN
VTZg70U3he7Kt-304vEDqF9fDGX8jfPq5RnStn50&s=Us3UaVYVbznpkZ1j73y7EA6kkrF
wQVLbqsrIXxgTQFs&e=


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690 Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed.  If 
you have received this email in error please notify the sender by replying to 
the e-mail containing this attachment. Replies to this email may be monitored 
by COMODO for operational or business reasons. Whilst every endeavour is taken 
to ensure that e-mails are free from viruses, no liability can be accepted and 
the recipient is requested to use their own virus checking software.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to