US FPKI Root Inclusion Request

[Kathleen Wilson]

U.S. Federal PKI Management Authority (US FPKI) has applied to add the
�Federal Common Policy CA� root certificate, and to enable all three
trust bits.

The U.S. FPKI Management Authority is a National Government CA that
operates the Federal Common Policy Framework Certification Authority
(FCPCA) on behalf of the Federal PKI Policy Authority. The FCPCA is the
Trust Anchor for the Federal Government. CAs under the FCPCA issue PKI
credentials to Federal employees and contractors. The FCPCA is also
cross certified with the Federal Bridge Certification Authority which
provides a trusted path to cross certified Federal Agencies, commercial
venders, states governments and other bridges.

The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=478418

And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#US%20FPKI

Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=646686

Noteworthy points:

* All documents are in English.

CP: http://www.idmanagement.gov/fpkipa/documents/CommonPolicy.pdf
CPS:
http://www.idmanagement.gov/fpkipa/documents/FPKI_CPS_v4_1_Redacted_final_20120515.pdf


* This is the root certificate for the U.S. Federal Common Policy
Framework Certificate Authority (FCPCA). The FCPCA only issues
certificates to subordinate CAs. The sub-CAs are operated by the Shared
Service Providers (SSPs). End-entity certificates may be issued to
Federal employees, contractors, affiliated personnel, and devices
operated by or on behalf of Federal agencies. The list of certified SSPs
is provided on the FPKIPA website,
http://www.idmanagement.gov/pages.cfm/page/Federal-PKI.

** All CAs issuing certificates subordinate to the Federal Common Policy
CA must adhere to the X.509 Certificate Policy For The U.S. Federal PKI
Common Policy Framework, which can be found here:
http://www.idmanagement.gov/fpkipa/documents/CommonPolicy.pdf
** Certified PKI Shared Service Providers (SSP):
http://www.idmanagement.gov/pages.cfm/page/Federal-PKI-Policy-Authority-Shared-Service-Provider-Working-Group-Certified-PKI-Shared-Service-Prov
** Entities cross-certified with FBCA:
http://www.idmanagement.gov/pages.cfm/page/Federal-PKI-Management-Authority-entities-crosscertified-with-the-FBCA
** http://fpkiapps.icam.pgs-lab.com/fbcaApps shows the output of a tool
that crawls the public repositories starting from the Federal Common
Policy CA root certificate and finds all CA certificates with a valid
path back through the AIAs.

* Federal Legacy CAs are cross-certified with the FCPCA or the FBCA.
CP Section 1.1.4: Except for legacy Federal PKIs, interoperation with
CAs that issue under different policies will be achieved through policy
mapping and cross-certification through the Federal Bridge Certification
Authority. Legacy Federal PKIs may perform policy mapping and cross-
certification with either the Common Policy Root CA or Federal Bridge
Certification Authority at their discretion.

* The request is to enable all three trust bits

** In-person identification of human subscribers is required, and all
certificates are manually processed.

** CP section 1.3.4: For this policy, subscribers are limited to Federal
employees, contractors, affiliated personnel, and devices operated by or
on behalf of Federal agencies.

** CP section 3.2.2: Requests for CA certificates shall include the CA
name, address, and documentation of the existence of the CA. Before
issuing CA certificates, an authority for the issuing CA shall verify
the information, in addition to the authenticity of the requesting
representative and the representative�s authorization to act in the name
of the CA.

** CP section 3.2.3.1: The RA shall ensure that the applicant�s identity
information is verified. Identity shall be verified no more than 30 days
before initial certificate issuance. At id-fpki-common-High, the
applicant shall appear at the RA in person. For all other policies, RAs
may accept authentication of an applicant�s identity attested to and
documented by a trusted agent to support identity proofing of remote
applicants, assuming agency identity badging requirements are otherwise
satisfied. Authentication by a trusted agent does not relieve the RA of
its responsibility to perform steps 1), 2), the verification of
identifying information (e.g., by checking official records) in step 3),
and the maintenance of biometrics in step 4), below.
At a minimum, authentication procedures for employees must include the
following steps:
1) Verify that a request for certificate issuance to the applicant was
submitted by agency management.
2) Verify Applicant�s employment through use of official agency records.
3) Establish applicant�s identity by in-person proofing before the
registration authority, based on either of the following processes:
a) Process #1:
i) The applicant presents a government-issued form of identification
(e.g., an Agency ID badge, a passport, or driver�s license) as proof of
identity, and
ii) The RA examines the presented credential for biometric data that can
be linked to the applicant (e.g., a photograph on the credential itself
or a securely linked photograph of applicant), and
iii) The credential presented in step 3) a) i) above shall be verified
by the RA for currency and legitimacy (e.g., the agency ID is verified
as valid). Typically this is accomplished by querying a database
maintained by the organization that issued the credential, but other
equivalent methods may be used.
b) Process #2:
i) The applicant presents a government-issued form of identification
(e.g., an Agency ID badge, a passport, or driver�s license) as proof of
identity, and
ii) The RA examines the presented credential for biometric data that can
be linked to the applicant (e.g., a photograph on the credential itself
or a securely linked photograph of applicant), and
iii) The applicant presents current corroborating information (e.g.,
current credit card bill or recent utility bill) to the RA. The
identifying information (e.g., name and address) on the credential
presented in step 3) b) i) above shall be verified by the RA for
currency and legitimacy (e.g., the agency ID is verified as valid).
Practice Note: This may be accomplished by querying a database
maintained by the organization that issued the financial instrument or
through use of a commercial credit database. In some instances,
commercial credit card databases will validate name and address of
current cardholders on-line; this validation is acceptable if the card
is presented to the RA. Other methods may be accepted.

** CP section 3.2.3.2: Some computing and communications devices
(routers, firewalls, servers, etc.) and software applications will be
named as certificate subjects. In such cases, the device must have a
human sponsor. The sponsor is responsible for providing the following
registration information:
- Equipment identification (e.g., serial number) or service name (e.g.,
DNS name) or unique software application name
- Equipment or software application public keys
- Equipment or software application authorizations and attributes (if
any are to be included in the certificate)
- Contact information to enable the CA or RA to communicate with the
sponsor when required.
The identity of the sponsor shall be authenticated by:
- Verification of digitally signed messages sent from the sponsor using
a certificate issued under this policy; or
- In-person registration by the sponsor, with the identity of the
sponsor confirmed in accordance with the requirements of section 3.2.3.1.

** CP section 3.2.4: Information that is not verified shall not be
included in certificates.

** CP section 3.2.5: Before issuing CA certificates or signature
certificates that assert organizational authority, the CA shall validate
the individual�s authority to act in the name of the organization. For
pseudonymous certificates that identify subjects by their organizational
roles, the CA shall validate that the individual either holds that role
or has been delegated the authority to sign on behalf of the role.

** CP section 4.1: The Certificate application process must provide
sufficient information to:
Establish the applicant�s authorization (by the employing or sponsoring
agency) to obtain a certificate. (per section 3.2.3)
Establish and record identity of the applicant. (per section 3.2.3)
Obtain the applicant�s public key and verify the applicant�s possession
of the private key for each certificate required. (per section 3.2.1)
Verify any role or authorization information requested for inclusion in
the certificate.
These steps may be performed in any order that is convenient for the PKI
Authorities and applicants that does not defeat security, but all must
be completed before certificate issuance.


* EV-enablement is not being requested at this time.

* Root Cert Download: http://http.fpki.gov/fcpca/fcpca.crt

* Test Website: https://http.icam.pgs-lab.com

* CRL: http://http.fpki.gov/fcpca/fcpca.crl
** LDAP In end-entity cert for the test website.
** CP section 4.9.7: CAs that issue certificates to subscribers or
operate on-line must issue CRLs at least once every 18 hours, and the
nextUpdate time in the CRL may be no later than 48 hours after issuance
time (i.e., the thisUpdate time). For legacy Federal PKIs only, the
nextUpdate time in the CRL may be no later than 180 hours after issuance
time (i.e., the thisUpdate time).

* OCSP
** The FPKIMA does not run an OCSP responder for the Common Policy CA
itself.
** AIA Extension in end-entity cert for the test website has OCSP: URI:
http://ocsp.managed.entrust.com/OCSP/EMSSSPCAResponder
** CP section 4.9.9: CAs shall support on-line status checking via OCSP
[RFC 2560] for end entity certificates issued under
id-fpki-common-authentication and id-fpki-common-cardAuth. Where on-line
status checking is supported, status information must be updated and
available to relying parties within 18 hours of certificate revocation.
Where on-line status checking is supported and a certificate issued
under id-fpki-common-High is revoked for key compromise, the status
information must be updated and available to relying parties within 6 hours.

* Audit
** Audit Requirements:
http://www.idmanagement.gov/fpkipa/documents/FPKI_Compliance_Audit_Requirements.doc

** Audit Type: ISO 21188:2006
** Auditor: Slandala, and U. S. General Services Administration Office
of General Counsel
** Auditor Website: http://slandala.com
** Audit of audit:
http://www.idmanagement.gov/fpkima/documents/FPKI-audit-rev2-2012-jec-signed.pdf

** The ISO document says: Control objectives in the areas of CA
environmental controls, CA key life cycle management controls, and
certificate life cycle management controls are presented in 7.2 to 7.6,
representing baseline control criteria with which a CA shall comply and
against which a CA may be evaluated or audited. Such an evaluation may
take the form of an internal audit or external audit using any
appropriate audit methodology as may be defined by the rules of the
contractual environment.
** The FPKI Compliance Audit Requirements also do not specify a
particular audit methodology that must be used but requires that an
annual audit takes place, that it is done by a qualified independent
auditor, who ensured the CPS conforms to the CP and that operational
practices conform to the CPS. See Appendices C & D of
http://www.idmanagement.gov/fpkipa/documents/FPKI_Compliance_Audit_Requirements.doc
for what the CPWG reviews for all audit letters we receive from the FPKI
SSP and Affiliates.
** The CP that is used for the annual audit of the Federal Common Policy
and all subordinate CAs is the X.509 Certificate Policy for the U.S.
Federal PKI Common Policy Framework. All the cross-certified affiliates
of the FBCA are audited against their own CP which has been mapped to
the FBCA CP. Both of these are fully conformant CPs in RFC 3647 format
so adhere to the controls specified in section 7 and the tables in
section 8 of the ISO standard.


* https://wiki.mozilla.org/CA:SubordinateCA_checklist

** All subCAs are publicly disclosed and separately audited, with the
audit letters reviewed by the FPKIPA.
** All PKIs participating in the Federal PKI must provide a copy of
their annual audit letter to the Federal PKI Policy Authority.

1) The Federal Common Policy CA is the trust anchor for the Common
Policy CP � its only �subordinate� CAs are the Shared Service Provider
(SSP) CAs which are under contract to GSA to provide PKI services which
follow the Common Policy CP. These subordinate CAs could be considered
Third-Party as they are independently run by other organizations, but
they do not issue certificates to the general public. They are
restricted to issuing certificates to Federal employees, federal devices
and contractors approved by the Federal agency the contractor supports.
2) Although in a sense these might be considered Private or Enterprise
CAs as they are restricted in who they can issue subscriber certificates
to, the reason we want the Federal Common Policy CA in the Mozilla trust
store is because these subscriber certificates may be encountered by a
typical Mozilla user doing business with the US Federal government.
3) The SSP CAs are all required to undergo independent third party
audits on an annual basis. And we disclose the CAs � they are all
listed on the idmanagement.gov site, as well as in our publicly
available repositories available via both LDAP and HTTP. All SSPs
operating under the Common Policy can only issue certificates to
subordinate CAs that also adhere to the Common Policy CP.
4) The cross-certified CAs are not sub-CAs of Common Policy. However,
they also are required to undergo independent third party audits on an
annual basis and are also disclosed both on idmanagement.gov and in our
same publicly accessible repositories.

** Publication of CA information in the Entity repositories is a local
decision.

** Shared Service Provider Roadmap:
http://www.idmanagement.gov/fpkipa/documents/SSProadmap.pdf
This Shared Service Provider Roadmap is intended to identify the
background information, phases, and activities related to the selection
process for prospective PKI shared service providers. This document
identifies the process by which a vendor qualifies for inclusion on the
Certified PKI SSP List. It also describes requirements that must be met
to maintain certification, as well as contracting considerations.

** CP section 1.1.2: This CP states what assurance can be placed in a
certificate issued by the CA. The certification practice statement (CPS)
states how the CA establishes that assurance. Each CA that issues
certificates under this CP shall have a corresponding CPS.
CP section 1.1.3: This CP applies to certificates issued to CAs,
devices, and Federal employees, contractors and other affiliated personnel.


* http://wiki.mozilla.org/CA:Problematic_Practices
** External RAs, and distributing generated private keys.

** CP section 1.3.2: The registration authorities (RAs) collect and
verify each subscriber�s identity and information that is to be entered
into the subscriber�s public key certificate. The RA performs its
function in accordance with a CPS approved by the FPKIPA. The RA is
responsible for:
The identification and authentication process.

** CP section 1.3.3: The trusted agent is a person who satisfies all the
trustworthiness requirements for an RA and who performs identity
proofing as a proxy for the RA. The trusted agent records information
from and verifies biometrics (e.g., photographs) on presented
credentials for applicants who cannot appear in person at an RA. The CPS
will identify the parties responsible for providing such services, and
the mechanisms for determining their trustworthiness.

** CP section 8.1: CAs and RAs operating under this policy shall be
subject to a periodic compliance audit at least once per year. As an
alternative to a full annual compliance audit against the entire CPS,
the compliance audit of CAs and RAs may be carried out in accordance
with the requirements as specified in the Triennial Audit Guidance
document located at http://www.idmanagement.gov/fpkipa/.
Further, the Federal PKI Policy Authority has the right to require
aperiodic compliance audits of CAs operating under this policy. The
Federal PKI Policy Authority shall state the reason for any aperiodic
compliance audit.

** When CAs or RAs generate keys on behalf of the subscriber, then the
private key must be delivered securely to the subscriber. Private keys
may be delivered electronically or may be delivered on a hardware
cryptographic module. In all cases, the following requirements must be met:
- Anyone who generates a private signing key for a subscriber shall not
retain any copy of the key after delivery of the private key to the
subscriber.
- The private key(s) must be protected from activation, compromise, or
modification during the delivery process.
- The subscriber shall acknowledge receipt of the private key(s).
- Delivery shall be accomplished in a way that ensures that the correct
tokens and activation data are provided to the correct subscribers.
- For hardware modules, accountability for the location and state of the
module must be maintained until the subscriber accepts possession of it.
- For electronic delivery of private keys, the key material shall be
encrypted using a cryptographic algorithm and key size at least as
strong as the private key. Activation data shall be delivered using a
separate secure channel.
- The CA must maintain a record of the subscriber acknowledgment of
receipt of the token.


This begins the first discussion of the request from US FPKI to add the
�Federal Common Policy CA� root certificate, and to enable all three
trust bits.

At the conclusion of this discussion, I will provide a summary of issues
noted and action items. If there are no outstanding issues, then this
request can be approved. If there are outstanding issues or action
items, then an additional discussion may be needed as follow-up.

NOTE: This bug (#478418) has been marked as dependent on bug #651246,
�Make libpkix-based certificate path building/validation the default in
PSM�.
https://bugzilla.mozilla.org/show_bug.cgi?id=478418#c31
�� only the newer libPKIX chain-finding code will be able to find chains
to the root contained in this bug. I haven't checked myself whether this
is true, but if it is, then adding this root to NSS won't help you,
unless Mozilla/NSS is also changed to use the newer code by default. And
using the newer code by default is the subject of bug 651246.�
https://bugzilla.mozilla.org/show_bug.cgi?id=478418#c33
�It's important to note that this is -not- simply a website root, it's
much more geared toward enabling the US federal government PIV program
-- which is designed to extremely strongly authenticate individuals,
even more stringently than the Class 2 CAs we currently have in the program�

Kathleen

[Kyle Hamilton]

I have no issues with this. (I would have reservations if it also
wanted EV treatment, but that's beside the point.)

FPKI is a cross certifier, not an end entity certifier. It relies
upon readiness and operational audits to establish current SSP
readiness for its program. Even if audits indicate that a supplicant
CA is ready, a CA is not eligible until its operator has a federal
contract which requires that it be accredited.

All individuals operating a federal contract have high discoverability
for any malfeasance. They also have stronger felony laws which apply
to any malfeasance they may be associated with. For this reason
(familiarity with my home government's workings) I am okay with this
request.

I think Mozilla should implement its root program much like FPKI
implements its cross-certification program. Instead of relying on
"presence or absence in the root store", it should have its own roots
and embed cross-certificates from those roots. The only difference
should be, provide OCSP (since those would accredit EV issuers as
well).

-Kyle H

On Fri, Jul 27, 2012 at 1:32 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> U.S. Federal PKI Management Authority (US FPKI) has applied to add the

> “Federal Common Policy CA” root certificate, and to enable all three trust

> representative’s authorization to act in the name of the CA.
>
> ** CP section 3.2.3.1: The RA shall ensure that the applicant’s identity

> information is verified. Identity shall be verified no more than 30 days
> before initial certificate issuance. At id-fpki-common-High, the applicant
> shall appear at the RA in person. For all other policies, RAs may accept

> authentication of an applicant’s identity attested to and documented by a

> trusted agent to support identity proofing of remote applicants, assuming
> agency identity badging requirements are otherwise satisfied. Authentication
> by a trusted agent does not relieve the RA of its responsibility to perform
> steps 1), 2), the verification of identifying information (e.g., by checking
> official records) in step 3), and the maintenance of biometrics in step 4),
> below.
> At a minimum, authentication procedures for employees must include the
> following steps:
> 1) Verify that a request for certificate issuance to the applicant was
> submitted by agency management.

> 2) Verify Applicant’s employment through use of official agency records.
> 3) Establish applicant’s identity by in-person proofing before the

> registration authority, based on either of the following processes:
> a) Process #1:
> i) The applicant presents a government-issued form of identification (e.g.,

> an Agency ID badge, a passport, or driver’s license) as proof of identity,

> and
> ii) The RA examines the presented credential for biometric data that can be
> linked to the applicant (e.g., a photograph on the credential itself or a
> securely linked photograph of applicant), and
> iii) The credential presented in step 3) a) i) above shall be verified by
> the RA for currency and legitimacy (e.g., the agency ID is verified as
> valid). Typically this is accomplished by querying a database maintained by
> the organization that issued the credential, but other equivalent methods
> may be used.
> b) Process #2:
> i) The applicant presents a government-issued form of identification (e.g.,

> an Agency ID badge, a passport, or driver’s license) as proof of identity,

> individual’s authority to act in the name of the organization. For

> pseudonymous certificates that identify subjects by their organizational
> roles, the CA shall validate that the individual either holds that role or
> has been delegated the authority to sign on behalf of the role.
>
> ** CP section 4.1: The Certificate application process must provide
> sufficient information to:

> Establish the applicant’s authorization (by the employing or sponsoring

> agency) to obtain a certificate. (per section 3.2.3)
> Establish and record identity of the applicant. (per section 3.2.3)

> Obtain the applicant’s public key and verify the applicant’s possession of

> – its only “subordinate” CAs are the Shared Service Provider (SSP) CAs which

> are under contract to GSA to provide PKI services which follow the Common
> Policy CP. These subordinate CAs could be considered Third-Party as they
> are independently run by other organizations, but they do not issue
> certificates to the general public. They are restricted to issuing
> certificates to Federal employees, federal devices and contractors approved
> by the Federal agency the contractor supports.
> 2) Although in a sense these might be considered Private or Enterprise CAs
> as they are restricted in who they can issue subscriber certificates to, the
> reason we want the Federal Common Policy CA in the Mozilla trust store is
> because these subscriber certificates may be encountered by a typical
> Mozilla user doing business with the US Federal government.
> 3) The SSP CAs are all required to undergo independent third party audits on

> an annual basis. And we disclose the CAs – they are all listed on the

> each subscriber’s identity and information that is to be entered into the
> subscriber’s public key certificate. The RA performs its function in

> “Federal Common Policy CA” root certificate, and to enable all three trust

> bits.
>
> At the conclusion of this discussion, I will provide a summary of issues
> noted and action items. If there are no outstanding issues, then this
> request can be approved. If there are outstanding issues or action items,
> then an additional discussion may be needed as follow-up.
>

> NOTE: This bug (#478418) has been marked as dependent on bug #651246, “Make
> libpkix-based certificate path building/validation the default in PSM”.
> https://bugzilla.mozilla.org/show_bug.cgi?id=478418#c31
> “… only the newer libPKIX chain-finding code will be able to find chains to

> the root contained in this bug. I haven't checked myself whether this is
> true, but if it is, then adding this root to NSS won't help you, unless
> Mozilla/NSS is also changed to use the newer code by default. And using the

> newer code by default is the subject of bug 651246.”
> https://bugzilla.mozilla.org/show_bug.cgi?id=478418#c33
> “It's important to note that this is -not- simply a website root, it's much

> more geared toward enabling the US federal government PIV program -- which
> is designed to extremely strongly authenticate individuals, even more

> stringently than the Class 2 CAs we currently have in the program”
>
> Kathleen
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Phillip Hallam-Baker]

So lets get this straight, people had big problems with a Chinese
company getting a root included in case they might be under the
control of the Chinese government.

The US government asks for a root to be included and nobody has any
issues at all. This despite the fact that the US government was
implicated in a direct compromise of certs in the Stuxnet and Flame
incidents.

I am not arguing against including the US government root here, I am
arguing against a repeat of the earlier discussion.

[Erwann Abalea]

You're right, they already *proved* to have had a disputable behaviour. This alone should disqualify this request.
https://groups.google.com/d/msg/mozilla.dev.security.policy/xx8iuyLPdQk/7t-vjGZlawsJ

It's not only a government CA, it's a cross-certifying government CA.
The questions Mozilla had regarding cross-certified and external sub-CAs will be the same here, but on a much larger scale.
The responses that Mozilla (and others) had to deploy when one external sub-CA went to fail are suboptimal.
Mozilla relies on trusted actors to be transparent about security problems they encounter, and I don't think that transparency is one of their motto. (I'll agree to remove this argument if disputed, it's subjective)

[Ben Wilson]

Mozilla should approve the inclusion of the Federal PKI Root. My experience
is that the security requirements and oversight of the federal root have
been proven for well over 10 years.

-----Original Message-----
From: dev-security-policy-bounces+ben=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On
Behalf Of Erwann Abalea
Sent: Monday, July 30, 2012 11:12 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: US FPKI Root Inclusion Request

Le lundi 30 juillet 2012 04:02:39 UTC+2, Phillip Hallam-Baker a écrit :

You're right, they already *proved* to have had a disputable behaviour. This
alone should disqualify this request.
https://groups.google.com/d/msg/mozilla.dev.security.policy/xx8iuyLPdQk/7t-v
jGZlawsJ

It's not only a government CA, it's a cross-certifying government CA.
The questions Mozilla had regarding cross-certified and external sub-CAs
will be the same here, but on a much larger scale.
The responses that Mozilla (and others) had to deploy when one external
sub-CA went to fail are suboptimal.
Mozilla relies on trusted actors to be transparent about security problems
they encounter, and I don't think that transparency is one of their motto.
(I'll agree to remove this argument if disputed, it's subjective)

[Tom Lowenthal]

Kathleen Wilson:

> U.S. Federal PKI Management Authority (US FPKI) has applied to add the

> “Federal Common Policy CA” root certificate, and to enable all three
> trust bits.
>
<snip>

>
> CP: http://www.idmanagement.gov/fpkipa/documents/CommonPolicy.pdf
> CPS:
> http://www.idmanagement.gov/fpkipa/documents/FPKI_CPS_v4_1_Redacted_final_20120515.pdf

This root inclusion request does not include a complete and accurate
certification practice statement. The CPS provided and helpfully
indicated above is redacted. Unless the US FPKI can provide a CPS which
completely describes their operations I think that we should reject this
request.

[Chris Palmer]

On Tue, Jul 31, 2012 at 2:40 PM, Tom Lowenthal <t...@mozilla.com> wrote:

>> http://www.idmanagement.gov/fpkipa/documents/FPKI_CPS_v4_1_Redacted_final_20120515.pdf
>
> This root inclusion request does not include a complete and accurate
> certification practice statement. The CPS provided and helpfully
> indicated above is redacted. Unless the US FPKI can provide a CPS which
> completely describes their operations I think that we should reject this
> request.

Search the document for "[Redacted for Security Purposes]". Many of
the redactions are harmless and would not affect the goodness of this
CPS, but some of them are a bit questionable (especially since we
don't know the size of the redactions). For example, what are we
missing on pages 46 and 47?

"""
Automatic logs are generated each time an FPKI Trust Infrastructure CA
is started, an Entity
connects (or unsuccessfully attempts to connect) to the CA, or the
private signing key is used.

[Redacted for Security Purposes]
"""

What does the original say? "However, we don't log when we are doing
sneaky stuff."?

Redactions are not necessarily deal-breakers — for example, they
redact the exact locations of their facilities, which doesn't bother
me — but when entire paragraphs (sentences? pages?) are redacted in
areas that I do want to know about, well, that's different.

This exercise is about proving trustworthiness to the public — a very,
very high standard. Given that a tiny percentage of Mozilla (and
other) users will actually need to legitimately trust the US FPKI, and
given this rather cagey CPS, and given that small user communities
that want to trust a special root can easily do so, I don't think
their certificate(s) should be added to Mozilla's root.

[David E. Ross]

On 7/27/12 1:32 PM, Kathleen Wilson wrote:
> U.S. Federal PKI Management Authority (US FPKI) has applied to add the

> “Federal Common Policy CA” root certificate, and to enable all three

> trust bits.
>
> The U.S. FPKI Management Authority is a National Government CA that
> operates the Federal Common Policy Framework Certification Authority
> (FCPCA) on behalf of the Federal PKI Policy Authority. The FCPCA is the
> Trust Anchor for the Federal Government. CAs under the FCPCA issue PKI
> credentials to Federal employees and contractors. The FCPCA is also
> cross certified with the Federal Bridge Certification Authority which
> provides a trusted path to cross certified Federal Agencies, commercial
> venders, states governments and other bridges.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=478418
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#US%20FPKI
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=646686
>
> Noteworthy points:
>
> * All documents are in English.
>
> CP: http://www.idmanagement.gov/fpkipa/documents/CommonPolicy.pdf
> CPS:
> http://www.idmanagement.gov/fpkipa/documents/FPKI_CPS_v4_1_Redacted_final_20120515.pdf
>

> [snipped]

If portions of unknown size and meaning were redacted in the CP or CPS
for a commercial certification authority, would that be acceptable to
Mozilla? Does that meet the requirement of the 2nd bullet of #6 under
"Mozilla CA Certificate Inclusion Policy (Version 2.0)" to "publicly
disclose information"?

How is anyone to review and judge the CPS in this case? The whole issue
is TRUST. Trust requires transparency, which is lacking here.

--

David E. Ross
<http://www.rossde.com/>.

Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
© 1997 by David E. Ross

[Ben Wilson]

I'll let the FPKIPA speak for itself, but the difference is in the approach
that they take to what should be in a CPS. RFC 2828 reviews the various
definitions of "CPS", including those found in the ABA Digital Signature
Guidelines. In my subsequent work on the PKI Assessment Guidelines these
differing approaches were understood and discussed. Read Section 3.4 of RFC
3647. http://www.ietf.org/rfc/rfc3647.txt Experience in dealing with the
US Fed PKI demonstrates that they require more detail in a CPS and then
allow it to be redacted. This is done for Shared Service Provider CPSs of
Symantec and others. They focus on the initial need for a CPS to be a
"detailed" "security policy" to address their particular need, whereas those
who draft CPSs for commercial CAs already start from the premise that the
document will be public. For these other kinds of CPSs, the review requires
balance between too little and too much and deciding when transparency might
harm security (aka disclosing information that may have been put in the CPS
on a "need-to-know" basis). I think the redactions themselves might tend to
allow our imaginations to run wild with conspiracy theories, but more
realistically, wouldn't it be better to arrange for someone at Mozilla
(Kathleen) to conduct an "in camera" review of the redacted portions of such
CPS and for everyone to sign off on it if she gave the green light?

-----Original Message-----
From: dev-security-policy-bounces+ben=digice...@lists.mozilla.org
[mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On
Behalf Of David E. Ross
Sent: Tuesday, July 31, 2012 8:42 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: US FPKI Root Inclusion Request

On 7/27/12 1:32 PM, Kathleen Wilson wrote:

> U.S. Federal PKI Management Authority (US FPKI) has applied to add the

> "Federal Common Policy CA" root certificate, and to enable all three

> trust bits.
>
> The U.S. FPKI Management Authority is a National Government CA that
> operates the Federal Common Policy Framework Certification Authority
> (FCPCA) on behalf of the Federal PKI Policy Authority. The FCPCA is
> the Trust Anchor for the Federal Government. CAs under the FCPCA
> issue PKI credentials to Federal employees and contractors. The FCPCA
> is also cross certified with the Federal Bridge Certification
> Authority which provides a trusted path to cross certified Federal
> Agencies, commercial venders, states governments and other bridges.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=478418
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#US%20FPKI
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=646686
>
> Noteworthy points:
>
> * All documents are in English.
>
> CP: http://www.idmanagement.gov/fpkipa/documents/CommonPolicy.pdf
> CPS:
> http://www.idmanagement.gov/fpkipa/documents/FPKI_CPS_v4_1_Redacted_fi
> nal_20120515.pdf
>

> [snipped]

If portions of unknown size and meaning were redacted in the CP or CPS for a
commercial certification authority, would that be acceptable to Mozilla?
Does that meet the requirement of the 2nd bullet of #6 under "Mozilla CA
Certificate Inclusion Policy (Version 2.0)" to "publicly disclose
information"?

How is anyone to review and judge the CPS in this case? The whole issue is
TRUST. Trust requires transparency, which is lacking here.

--

David E. Ross
<http://www.rossde.com/>.

Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.

C 1997 by David E. Ross

[Phillip Hallam-Baker]

Oh come on.

The CPS specifies a set of restrictions on issue.

The question here should be, are the restrictions sufficient?

If they have additional restricitions, that should be no problem. Now
sections that nullify the other parts of the CPS would be a different
matter.

On Tue, Jul 31, 2012 at 7:41 PM, David E. Ross <nob...@nowhere.invalid> wrote:
> On 7/27/12 1:32 PM, Kathleen Wilson wrote:

>> U.S. Federal PKI Management Authority (US FPKI) has applied to add the

>> “Federal Common Policy CA” root certificate, and to enable all three

>> trust bits.
>>
>> The U.S. FPKI Management Authority is a National Government CA that
>> operates the Federal Common Policy Framework Certification Authority
>> (FCPCA) on behalf of the Federal PKI Policy Authority. The FCPCA is the
>> Trust Anchor for the Federal Government. CAs under the FCPCA issue PKI
>> credentials to Federal employees and contractors. The FCPCA is also
>> cross certified with the Federal Bridge Certification Authority which
>> provides a trusted path to cross certified Federal Agencies, commercial
>> venders, states governments and other bridges.
>>
>> The request is documented in the following bug:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=478418
>>
>> And in the pending certificates list here:
>> http://www.mozilla.org/projects/security/certs/pending/#US%20FPKI
>>
>> Summary of Information Gathered and Verified:
>> https://bugzilla.mozilla.org/attachment.cgi?id=646686
>>
>> Noteworthy points:
>>
>> * All documents are in English.
>>
>> CP: http://www.idmanagement.gov/fpkipa/documents/CommonPolicy.pdf
>> CPS:
>> http://www.idmanagement.gov/fpkipa/documents/FPKI_CPS_v4_1_Redacted_final_20120515.pdf
>>

>> [snipped]
>
> If portions of unknown size and meaning were redacted in the CP or CPS
> for a commercial certification authority, would that be acceptable to
> Mozilla? Does that meet the requirement of the 2nd bullet of #6 under
> "Mozilla CA Certificate Inclusion Policy (Version 2.0)" to "publicly
> disclose information"?
>
> How is anyone to review and judge the CPS in this case? The whole issue
> is TRUST. Trust requires transparency, which is lacking here.
>
> --
>
> David E. Ross
> <http://www.rossde.com/>.
>
> Anyone who thinks government owns a monopoly on inefficient, obstructive
> bureaucracy has obviously never worked for a large corporation.

> © 1997 by David E. Ross

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

--
Website: http://hallambaker.com/

[Brown, Wendy (10421)]

The FPKI requirement for the FPKIMA to make a redacted version of the CPS available is to provide information about our operational practices. However, in the interest of securely operating our PKIs, we do not make information available that would make it easier for someone to attempt an attack on our CAs. Therefore, we are directed to redact any information that is deemed to be sensitive, as is allowed in RFC3647.



This is the formula that was used to perform the redactions to the Common Policy CPS:

Replace the following information within the CPS with the following phrase "[Redacted for Security Purposes]":

* Location details

* Networking details pertaining to access to facilities

* Itemization of what is stored in containers

* CA platform and hardening details

* Acronyms and their references that are Trust Infrastructure specific

* Specific technology references



We would also like to remind everyone that the full Certificate Policy (CP) is publicly posted. If there is any concern regarding what the redacted text might say (e.g., "we don't log when we are doing sneaky stuff"), we suggest that you first consider the policy boundaries set forth in the CP. We also undergo an annual PKI audit by a qualified independent auditor who must follow the FPKI Audit Guidelines, which are also publicly posted.

Thanks,
Wendy

Wendy Brown
FPKIMA Technical Liaison
Protiviti Government Services
703-299-4705 (office) 703-965-2990 (cell)

wendy...@fpki.gov
wendy...@pgs.protiviti.com

[ianG]

On 1/08/12 07:40 AM, Tom Lowenthal wrote:
> Kathleen Wilson:

>> U.S. Federal PKI Management Authority (US FPKI) has applied to add the

>> “Federal Common Policy CA” root certificate, and to enable all three
>> trust bits.
>>
> <snip>

>>
>> CP: http://www.idmanagement.gov/fpkipa/documents/CommonPolicy.pdf
>> CPS:
>> http://www.idmanagement.gov/fpkipa/documents/FPKI_CPS_v4_1_Redacted_final_20120515.pdf
>

> This root inclusion request does not include a complete and accurate
> certification practice statement. The CPS provided and helpfully
> indicated above is redacted. Unless the US FPKI can provide a CPS which
> completely describes their operations I think that we should reject this
> request.

For me, a general -1 on the redaction criticism.

Redactions do not indicate a lack of completeness, if that is the
assumption being presented here. Lack of completeness would need to be
referenced to a disclosure that is listed as required, and is not found
in the CPS, etc.

I for one actually prefer to see redactions as it at least gives us a
feeling for what has not been disclosed.

One alternative is to have a published CPS and an un-published
side-letter. Lack of knowledge about the unpublished additional
documents leads to us being dumber but feeling safer - which is better?

iang

[Kathleen Wilson]

On 7/27/12 1:32 PM, Kathleen Wilson wrote:

> U.S. Federal PKI Management Authority (US FPKI) has applied to add the

> “Federal Common Policy CA” root certificate, and to enable all three

Thanks to those of you who have reviewed and commented on this request.

Here is a summary of the discussion so far.

A) The point was raised that the US government was implicated in a
direct compromise of certs in the Stuxnet and Flame incidents. I have a
question to those of you who are more versed in these incidents. In
either of these incidents were certificates chaining up to this “Federal
Common Policy CA” root certificate mis-issued? (e.g. not in compliance
with Mozilla's CA Certificate Policy)

http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
"4. We reserve the right to not include a particular CA certificate in
our software products. This includes (but is not limited to) cases where
we believe that including a CA certificate (or setting its "trust bits"
in a particular way) would cause undue risks to users' security, for
example, with CAs that
- knowingly issue certificates without the knowledge of the entities
whose information is referenced in the certificates; or
- knowingly issue certificates that appear to be intended for fraudulent
use."


B) Concerns were raised about the redacted CPS. The CPS contains
information that cannot be shared publicly, so those portions are
removed from the version of the CPS that is posted on the website. Other
CAs often do this by having a separate document for internal or
security-sensitive information. I am not concerned about this, and I
don't see a resulting action item.


A few other questions have been brought to my attention that I think we
need to consider.

1) The CA hierarchy (cross-signings, bridge system) is very complex.
Does this complexity add undue risk if this root certificate is included
in NSS?

2) Only the libpkix code path can handle this CA hierarchy, so this root
cert should not be included until libpkix becomes the default code path
for validation. Should approval be dependent on bug #651246?

3) Will Mozilla be able to enforce the Mozilla CA Certificate Policy and
future updates within the US FPKI?

4) The Government of India has a large CA hierarchy, so they were told
to have each subCA apply for inclusion separately.
https://bugzilla.mozilla.org/show_bug.cgi?id=557167#c16
Should this same logic be applied to the US FPKI?
See the list of cross-signed entities here:
http://www.idmanagement.gov/pages.cfm/page/Federal-PKI-Management-Authority-entities-crosscertified-with-the-FBCA


I will appreciate your thoughtful and constructive feedback on these
questions.

Kathleen

[Eddy Nigg]

On 08/21/2012 11:56 PM, From Kathleen Wilson:

> 4) The Government of India has a large CA hierarchy, so they were told
> to have each subCA apply for inclusion separately.
>

Kathleen, I believe the same applies here, additionally disclosure and
auditing will become an issue soon depending on policy updates by
Mozilla. But I believe that CAs shouldn't be admitted by proxy into
Mozilla's NSS.

BTW, the same approach was taken for the government CA of Brazil and
maybe also for S. Korea. Not sure if I should make the same argument
that lead to this decision with the other CAs that are affected, or if
it's sufficient like this.

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

[Kathleen Wilson]

On 8/21/12 1:56 PM, Kathleen Wilson wrote:
> On 7/27/12 1:32 PM, Kathleen Wilson wrote:
>> U.S. Federal PKI Management Authority (US FPKI) has applied to add the
>> “Federal Common Policy CA” root certificate, and to enable all three
>> trust bits.

>> <snip>

>>
>> The request is documented in the following bug:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=478418
>>
>> And in the pending certificates list here:
>> http://www.mozilla.org/projects/security/certs/pending/#US%20FPKI
>>
>> Summary of Information Gathered and Verified:
>> https://bugzilla.mozilla.org/attachment.cgi?id=646686

>> <snip>

>
>
> Thanks to those of you who have reviewed and commented on this request.

> <snip>

>
> A few other questions have been brought to my attention that I think we
> need to consider.
>
> 1) The CA hierarchy (cross-signings, bridge system) is very complex.
> Does this complexity add undue risk if this root certificate is included
> in NSS?

Further evaluation and testing needs to be done.

Common (Federal Common Policy CA) signs FBCA (Federal Bridge CA) for
legacy purposes, so the inclusion of Common would mean that FBCA is also
implicitly included. Therefore, we have to take into consideration the
impact that the validation path up through the FBCA will have in regards
to how the NSS software functions.

An analysis will have to be done to determine how the NSS code will
handle validation of certificates in the FBCA and Common hierarchies
(both the old code path and the libpkix code bath). This will involve a
significant amount of testing, and the types of errors that are expected
may be intermittent, so may be hard to identify and debug.

An analysis will have to be done to determine if there will be
performance impact of including Common. The study will have to include
certs chaining up to FBCA and Common, and also certs that don’t chain up
to this hierarchy at all.

> 2) Only the libpkix code path can handle this CA hierarchy, so this root
> cert should not be included until libpkix becomes the default code path
> for validation. Should approval be dependent on bug #651246?

Further evaluation needs to be done as described above.

> 3) Will Mozilla be able to enforce the Mozilla CA Certificate Policy and
> future updates within the US FPKI?

All CAs must demonstrate compliance with Mozilla's CA Certificate Policy
before being approved for inclusion, and must maintain compliance for
continued inclusion.
http://www.mozilla.org/projects/security/certs/policy/EnforcementPolicy.html

> 4) The Government of India has a large CA hierarchy, so they were told
> to have each subCA apply for inclusion separately.
> https://bugzilla.mozilla.org/show_bug.cgi?id=557167#c16
> Should this same logic be applied to the US FPKI?
> See the list of cross-signed entities here:
> http://www.idmanagement.gov/pages.cfm/page/Federal-PKI-Management-Authority-entities-crosscertified-with-the-FBCA

As part of the technical evaluation, there will also be investigation
into the possibility of constraining all certs chaining up to Common to
..gov and .mil. Since the FBCA hierarchy has been around for so long, the
only way to truly do this would be to add code to NSS.


Due to the technical evaluation and testing that needs to be done, I am
closing this discussion, and progress will be tracked in the bug.

After the necessary evaluation and testing has been completed, a new
discussion about this request will be started.


Thanks to all of you who have contributed to this discussion.

Kathleen