Re: Intermediate certificate disclosure deadline in 2 weeks

[Peter Bowen]

I think there is confusion over the generic term “Symantec”.  There is no issue 
for Symantec (the company) to be an affiliate of the USG FPKI and to operate 
CAs mutually cross-certified with the USG FPKI.  Additionally there is no issue 
with Symantec (or anyone else) to operate CAs included in the Mozilla trust 
anchor list.

Where there is a problem, as Richard pointed out, is when a CA in the Mozilla 
trust anchor list issues a cross-certificate to a CA mutually cross-certified 
by the USG FPKI.  The Mozilla policy is that every CA that is the subject of a 
cross issued by a CA in the Mozilla trust anchor list must comply with Mozilla 
policy.  This is recursively true as well — “grandchild”, “great-grandchild”, 
etc CAs must comply with Mozilla policy.

Instead of revoking the Symantec SSP to Federal Bridge certificate, Symantec 
could instead revoke these two certificates to separate the USG FPKI from their 
Mozilla trusted CAs:
https://crt.sh/?id=2733031
https://crt.sh/?id=12722020

This is probably a better option and would avoid the issues you raised before.

Thanks,
Peter

> On Jun 29, 2016, at 10:18 PM, Myers, Kenneth (10421) 
>  wrote:
> 
> Thanks Eric.
> 
> 
> 1)  Mutual trust is dependent on an exchange of certificates as outlined 
> in the MOA and not the receipt. If one is removed, both must be removed per 
> the MOA. It is currently being discussed to allow only a certificate receipt 
> because mutual trust is a fundamental principle of the Federal Bridge. 
> Revoking the certificate breaches the agreement. The IdenTrust CA is operated 
> under a different program which coincidentally removed the certificate 
> exchange requirement around the same time it was brought up in the forum and 
> in the FPKI SSL testing.
> 
> 2)  The federal bridge is an identity hub and not an anchor. Trust is 
> established through the cert chain to Federal Common Policy and not through a 
> trust bundle or a trust store. Its purpose is to connect organizational PKIs 
> so an affiliate or federal agency can continue to use their root CA as a 
> trust anchor without the need to install other roots. By entering into an 
> agreement with the Federal Bridge, all affiliates (Symantec included) 
> recognize they trust certificates issued by other affiliates of the Federal 
> Bridge based on the policy mapping in certificate exchange. All certificates 
> are issued against the same criteria as outlined in the Federal Bridge CP and 
> mapped to affiliate CPs.
> 
> Ken

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

Re: FW: Intermediate certificate disclosure deadline in 2 weeks

[Eric Mill]

On Tue, Jun 28, 2016 at 5:48 PM, Myers, Kenneth (10421) <
kenneth.my...@protiviti.com> wrote:

>
> To revoke the Symantec certificate, the certificates issued by
> organizations under Symantec would no longer be trusted by federal relying
> parties.


No, I don't believe this is accurate. If Symantec revokes their
cross-signature of the Federal Bridge, then entities which trust Symantec
will no longer also automatically trust the Federal Bridge.

It's *only* if the Federal Bridge revokes their cross-signature of Symantec
that certificates issued by organizations under Symantec would no longer be
trusted by relying parties.

Each of those cross-signatures can be independently revoked, and the only
thing that's being discussed here is the cross-signature that Symantec made
(using its Mozilla-trusted root) of the Federal Bridge. That should not
have a drastic impact on federal relying parties.

Symantec is resolving the issue with the Federal PKI Policy Authority, but
> the risk to revoking the certificate is still uncertain.
>

As I said above, the technical impact of revoking the certificate was
misstated, so the risk should be assessed with the understanding that only
one direction of the relationship is under request to be revoked.



> 2) It is not acceptable for CAs trusted by the Mozilla Program to
> cross-sign with the Federal Bridge (From Richard Barnes)

...

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 be clear though, the Federal Bridge (anyone, really) could choose to
cross-sign roots trusted by the Mozilla trusted root program. I could spin
up a new CA on my laptop and cross-sign Symantec's root myself. That
wouldn't add any risk to the Mozilla root program. It's the other way
around that matters.

-- Eric



> Ken
>
> -Original Message-
> From: Rob Stradling [mailto:rob.stradl...@comodo.com]
> Sent: Monday, June 27, 2016 09:01
> To: Myers, Kenneth (10421) ;
> 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=CwIC-g=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY=DlNVTZg70U3he7Kt-304vEDqF9fDGX8jfPq5RnStn50=pqUpzJZnt7pQ1HsJr6dBrqifrxrdjl-iFkah0G685TY=
> >.
> >
> > 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=CwIC-g=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY=DlNVTZg70U3he7Kt-304vEDqF9fDGX8jfPq5RnStn50=diEBbsWTZ7Zo0d_TwT8WGR-3EwDoH469HqxCqlif53k=
>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=CwIC-g=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY=DlNVTZg70U3he7Kt-304vEDqF9fDGX8jfPq5RnStn50=JB_38bUAYT_Hl4B58oExVy_P8sXMISQGtZhyoyoSx2U=
>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 |
> > kenneth.my...@protiviti.com
> > Connect:
> > LinkedIn > edin.com_in_kennethmy=CwIC-g=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAt
> > E256go=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY=DlNVTZg70U3he7K
> > t-304vEDqF9fDGX8jfPq5RnStn50=yxnEOhIxqEJxYCndopgWxHD8FxhHFsjtBlvztmv
> > whhM= > | Thought Leadership:
> > Protiviti.com
> >
> > On Jun 24, 2016, at 08:01, "
> 

Re: Request to enable EV for VeriSign Class 3 G4 ECC root

[sanjay_modi]

On Wednesday, May 18, 2016 at 2:58:54 PM UTC-7, Kathleen Wilson wrote:
> Here is a summary of this discussion so far about Symantec's request to 
> enable EV treatment for the "VeriSign Class 3 Public Primary Certification 
> Authority - G4" root certificate that was included via bug #409235, and has 
> all three trust bits enabled. 
> 
> 1) The "Symantec AATL ECC Intermediate CA" needs to be revoked and added to 
> OneCRL. The intermediate cert has been added to Salesforce. 
> I'm assuming we may proceed with this request, as long as the cert is added 
> to OneCRL before EV treatment is actually enabled in a Firefox release.

It’s been revoked. 

> 
> 2) Questions were raised about wildcard certs in regards to the BRs. But it 
> sounds like for now Symantec's use of wildcard certs is not breaking any BRs.
> Question for Symantec: Are any of the issued wildcard certs EV?

No, we’ve have not issued an EV wildcard certificate. 

> 
> 3) Question raised: What technical controls are in place to ensure that 
> systems which issue S/MIME certs "in this CA hierarchy" are not capable of 
> issuing an SSL server certificate?
> Answer from Symantec: We have a technical control in place for systems that 
> issue S/MIME certs in this CA hierarchy.  Our systems use static cert 
> templates from which end-entity certs are issued. Those templates include an 
> EKU value, but do not use the serverAuth or anyExtendedKeyUsage values.
> 
> 4) Intermediate certificates for this root have been loaded into Salesforce, 
> and are available at the following links:
> https://wiki.mozilla.org/CA:SubordinateCAcerts
> https://mozillacaprogram.secure.force.com/CA/PublicIntermediateCerts?CAOwnerName=Symantec%20/%20VeriSign
> Symantec’s revoked intermediate certs have not yet been loaded into 
> Salesforce. 
> As per https://wiki.mozilla.org/CA:Communications#March_2016_Responses 
> Symantec plans to enter this data by June 30, 2016.


Yes, the revoked intermediates have been added to Salesforce. 

> 
> This request is still under discussion, so please continue to provide your 
> input.
> 
> Thanks,
> Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ISRG Root Inclusion Request

[Nick Lamb]

On Wednesday, 29 June 2016 04:13:59 UTC+1, Matt Palmer  wrote:
> The only difference here between LE and every other CA is that issuance from
> LE is free.

Nope. StartSSL and WoSign offer free issuance, Comodo offers a free "trial" 
which would be perfectly good for criminal enterprise. Symantec has a partner 
deal which is free at point of use, I'm sure I missed others, in effect free DV 
is the baseline product today.

Let's Encrypt is different in two significant ways, (1) they're a 
not-for-profit which eliminates the profit motive that has driven CA behaviours 
which were variously unsafe for the web PKI or terrible for subscribers; (2) 
they implement an IETF standards track mechanism for issuance

> While it's not a meaningful speedbump for the modern criminal,
> it does at least mean they've got to find a stolen CC.

Nope. You can buy a "prepaid" EMV card at a corner store. If you're under-25 
it's probably easier to buy a prepaid card than a bottle of liquor in many 
countries.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Salesforce offline Tuesday, June 28, for data import

[Kathleen Wilson]

The data migration has happened, and I have reviewed the data in the 
production DB. We will need to do some tweaking/fixing over then next 
couple of weeks, but I think we're good to go.


So, we will begin restoring access to the system, and I will send the 
"end of service outage" notice as soon as it has all been restored.


Kathleen


On 6/28/16 8:57 PM, Kathleen Wilson wrote:

All,

The signature that we were waiting for has happened, so we will continue
with the data migration. The public-facing reports will not be available
when the data import is happening, and until we have verified the data.

Kathleen


On 6/28/16 7:56 PM, Kathleen Wilson wrote:

All,

I apologize for the delay. We are waiting for a signature on the
agreement that must be completed before we can import the Microsoft root
store data into production. It is looking like we may have to wait until
tomorrow morning (PDT).

In the meantime, public-facing reports are working, but access to the
system is very limited because we don't want any changes going into the
system until we finish the data import.

I will provide status updates as things progress.

Kathleen



On 6/28/16 8:29 AM, Kathleen Wilson wrote:

The work on this data migration is starting now. The CA Community in
Salesforce (a.k.a. the Common CA Database) will be offline while we do
this data migration.

I have kicked off the process to send an email with subject
"CA Community in Salesforce - Planned Outage - Starting Now"
to everyone who has a login to the CA Community in Salesforce.

Kathleen



On 6/27/16 3:56 PM, Kathleen Wilson wrote:

All,

We are planning to do the import of the data corresponding to
Microsoft's root store program into the CA Community in Salesforce,
with
the hopeful start time of 8:00am PDT on Tuesday, June 28. We expect the
work to take 8 to 10 hours.

I understand that many of you are working to get your intermediate
certificate data entered by the end of June, so I will grant a reprieve
of a few days for those of you who are impacted by the system being
down
tomorrow. Also, I had to postpone some of the mass importing of
intermediate certificate data, and will resume that when I return from
vacation. So, please understand that our target date of having the
intermediate cert data entered by June 30 will be delayed a bit longer.

Jody and I are hoping to get his data imported tomorrow, so that we
have
a day to recover and handle any fine tuning, before I go on
vacation. We
decided not to wait until after my vacation, because Jody has a lot of
work to do on restoring his data, hopes to do the work once (not
have to
repeat), and wants to get started as soon as possible. We were
hoping to
get this data import done much earlier, but there have been unforeseen
delays.

Below is the draft of the mass email that I plan to send to everyone
who
has access to the CA Community in Salesforce -- one message will be
sent
at the beginning of the data migration, and the other at the end.

Please let me know if you have any feedback on this.

Thanks,
Kathleen

== At beginning of migration day ==

Dear Certification Authority,

Today, {!Today}, the Common CA Database (a.k.a. CA Community in
Salesforce) will be offline while we import Microsoft’s root store data
into the production database.

During that time, the following things will happen:
1) You will not be able to login to the CA Community in Salesforce.
2) The urls to Mozilla’s public-facing reports will not work.

Background on the Common CA Database may be found here:
https://wiki.mozilla.org/CA:CommonCADatabase:RootStoreOperators

I will send another email as soon as the data migration has been
completed.

I apologize for any inconvenience this causes.

Regards,
Kathleen Wilson
Mozilla
CA Program Manager
==
== At end of migration day ==

Dear Certification Authority,

The work on the Common CA Database (a.k.a. CA Community in Salesforce)
has been completed. Your access to the system and Mozilla's
public-facing reports have been restored.

You may notice the following:
1) Microsoft’s root store data has been imported and merged, so there
are more CA Owner and Root Certificate records.
2) The “Status” field in the CA Owner and Root Certificate records has
been changed to “Mozilla Status”.
3) There is a “Microsoft Fields” section in the page layout for CA
Owner
and Root Certificate records, and those fields can only be edited by
Microsoft’s root store operator, Jody Cloutier.
4) There is a “Mozilla Fields” section in the page layout for the Root
Certificate records and those fields can only be edited by Mozilla’s
root store operator, Kathleen Wilson.
5) Mozilla’s public-facing reports should still only indicate
information pertaining to Mozilla’s root store.

Please reply to this email if you notice any issues with your CA’s
data,
or if you have any problems logging into the system.

Regards,
Kathleen Wilson
Mozilla
CA Program Manager
==











___

Re: FW: Intermediate certificate disclosure deadline in 2 weeks

[Kurt Roeckx]

So my understanding of this is that Symantec knowns that the
other CAs have not been audited as required under the Mozilla
policy, that they shouldn't have signed those certs, but refuse to
revoke it because they're being paid for it.  This is in my
opinion just not acceptable.

Either Symantec's CP/CPS is not compatible with the Mozilla
Policy in which case the Symantec root should be removed,
or they're not following it in which case they should revoke that
certificate.


Kurt

On Tue, Jun 28, 2016 at 09:48:10PM +, 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=ka0t000TNS6AAO=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=ka0t000TNYYAA4=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 

Re: FW: Intermediate certificate disclosure deadline in 2 weeks

[Rob Stradling]

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=ka0t000TNS6AAO=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=ka0t000TNYYAA4=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=kA0t000KyroCAC).

Ken

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

On 27/06/16