User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1; MS-RTC LM 8) Build Identifier: The Federal Public Key Infrastructure Management Authority (FPKI MA) would like to request that the Federal Common Policy Framework Certificate Authority (Common Policy CA) certificate be added to the default CA certificates in Mozilla products. 1. Certificate data (or links to the data) for the CA certificate requested: • Name: CN = Common Policy, OU = FBCA, O = U.S. Government, C = us • Description: The Root certificate for the Federal Common Policy Framework Certificate Authority • thumbprint = cb 44 a0 97 85 7c 45 fa 18 7e d9 52 08 6c b9 84 1f 2d 51 b5 2. The purposes of the CA hierarchy associated with the Common Policy CA certificate: Under the general guidance of Congressional and Presidential mandates, the United States Government has been developing the capacity for Internet-based Electronic Government services for more than ten years. As envisioned in these mandates, “e-Government” will foster and permit: (1) Electronic signatures in lieu of wet/ink signatures; (2) electronic records in lieu of paper records; and (3) electronic transactions in lieu of paper-based or voice-based transactions. It is anticipated that e-Government will result in significant increases in efficiency and effectiveness for the millions of other governments, businesses, and individuals (foreign and domestic) who have regular business dealings with the United States Government and each other. Internet-based business transactions carry special requirements relating to the identity of the participants and the integrity of the information being exchanged. The United States Government has taken an international leadership position in the design, development, implementation, operation, and maintenance of an interoperable Public Key Infrastructure (PKI) system through which to provide high-assurance identity and integrity solutions. That system has come to be known as the U.S. Federal PKI Architecture. The centerpieces of that architecture are the “X.509 Certificate Policy for the Common Policy Framework,” the Common Policy Framework Certification Authority, and the Federal Bridge Certification Authority (FBCA). The Common Policy Framework Certification Authority is the primary instantiation of the”X.509 Certificate Policy for the Common Policy Framework.” It is the root Certificate Authority for hierarchical PKIs, as well as, peer to peer with the FBCA. The FBCA is becoming a world-wide transitive-trust engine, based on its cross-certification with an ever-growing number of U.S. Government PKI systems, other government PKI systems (foreign and domestic), commercial PKI Certification Authorities (foreign and domestic), and other PKI bridges (foreign and domestic). Pre-installing the U.S. Government’s Common Policy CA certificate in the Mozilla Trusted Root Certificate Store creates a trusted path to the U.S. FBCA and all of the PKI systems cross-certified with the U.S. FBCA. Pre-installation also eliminates the need to train and assist millions of U.S. Government employees and contractors, other government representatives, business representatives, and individuals (foreign and domestic) in manipulating and maintaining their own Trusted Root Store on each of their computers, thereby reducing both costs and errors. • We require the following Extended Key Usages: • Server Authentication • Client Authentication • Secure E-mail • Code Signing • Timestamping • OCSP • Encrypting File System • IP Sec (Tunnel, User) 3. The Common Policy CA is operated in accordance with the “Public X.509 U.S. Federal PKI Architecture Certification Practice Statement,” dated 13 September 2005. Both this document and the Common Policy CP can be found on the FPKI Policy Authority web site (http://www.cio.gov/fpkipa). The Federal government has established a Certified PKI Shared Service Providers (PKI SSP) List for vendors that have demonstrated the ability to provide managed PKI services that meet the Common Policy CP and federal government security requirements. (see Shared Service Provider Roadmap: Navigating the Process to Acceptance http://www.cio.gov/fpkipa/documents/SSProadmap.pdf)  In Section 3.1 of the Shared Service Provider Roadmap: Navigating the Process to Acceptance requires Shared Service Providers to generate key pairs in a trustworthy system. The federal government verifies that key pairs are generated in a trustworthy system through certification and accreditation process – See Section 4.4.2. • As required In Section 3.2 Shared Service Provider Roadmap: Navigating the Process to Acceptance, the Shared Service Provider is required to have a third party auditor warrant that their information and representations with the FCPF CA are true. This information is forwarded to the federal government as part of the certification and accreditation package. 4. The FCPF CA issues certificates with the following policy OIDs: id-fpki-common-policy ::= {2 16 840 1 101 3 2 1 3 6} id-fpki-common-hardware ::= {2 16 840 1 101 3 2 1 3 7} id-fpki-common-devices ::= {2 16 840 1 101 3 2 1 3 8} id-fpki-common-authentication ::= {2 16 840 1 101 3 2 1 3 13} id-fpki-common-High ::= {2 16 840 1 101 3 2 1 3 16} 5. A security review of the FCPF CA operations was conducted in accordance with Office of Management and Budget (OMB) A-130 Circular, Appendix III; Federal Information Security Act; NIST publications such as FIPS 199, FIPS 200, and Special Publications 800-30, 800-37, 800-39, 800-53, and 800-53A; GSA IT Security Policy Manual P2100.1D. The Letter of Authorization to Operate can be found at: http://www.cio.gov/fpkia/documents/FPKIAato.pdf 6. Certificates issued from the root can be verified at the following URL: ldap://fpkia.gsa.gov/cn=Common%20Policy,ou=FBCA,o=U.S.%20Government,c=US Reproducible: Always

Accepting this bug so we can begin the Information Gathering and Verification phase as described in https://wiki.mozilla.org/CA:How_to_apply The information that is needed is listed in https://wiki.mozilla.org/CA:Information_checklist To begin, please provide the following information: 1) URL to download the root certificate 2) Is this the correct link to the Common Policy CP? http://www.cio.gov/fpkipa/documents/CommonPolicy.pdf 3) The specific URL to the document that you mentioned: “Public X.509 U.S. Federal PKI Architecture Certification Practice Statement,” dated 13 September 2005. 4) Please see sections 8, 9, and 10 of the Mozilla CA Policy at http://www.mozilla.org/projects/security/certs/policy/ in regards to the audit requirements.

1) URL to download the root certificate http://fpkia.gsa.gov/CommonPolicy/CommonPolicy.crt 2) Is this the correct link to the Common Policy CP? http://www.cio.gov/fpkipa/documents/CommonPolicy.pdf It has since moved to (although there should still be a link from the old location): http://www.idmanagement.gov/fpkipa/documents/CommonPolicy.pdf 3) The specific URL to the document that you mentioned: “Public X.509 U.S. Federal PKI Architecture Certification Practice Statement,” dated 13 September 2005. http://www.idmanagement.gov/fpkipa/documents/FPKIA_CPS.pdf

1) URL to download the root certificate http://fpkia.gsa.gov/CommonPolicy/CommonPolicy.crt 2) Is this the correct link to the Common Policy CP? http://www.cio.gov/fpkipa/documents/CommonPolicy.pdf It has since moved to (although there should still be a link from the old location): http://www.idmanagement.gov/fpkipa/documents/CommonPolicy.pdf 3) The specific URL to the document that you mentioned: “Public X.509 U.S. Federal PKI Architecture Certification Practice Statement,” dated 13 September 2005. http://www.idmanagement.gov/fpkipa/documents/FPKIA_CPS.pdf

The attached document summarizes the information that has been gathered and verified for this request. The items highlighted in yellow indicate where further information or clarification is needed. Please review the full document for accuracy and completeness.

Thank you for the information. >> The Common Policy CRLs contain a critical CIDP. This is a problem that must be resolved before the root can be included. The end-users will get the error: Error Importing CRL to local Database. Error Code:ffffe095 ffffe095, is equivalent to -8043, SEC_ERROR_CRL_UNKNOWN_CRITICAL_EXTENSION Resolution: See https://wiki.mozilla.org/CA:Problematic_Practices#CRL_with_critical_CIDP_Extension >> OCSP may be provided by the sub-CAs We will need to verify that OCSP works within Firefox under each of the sub-CAs that provide OCSP. I can do this verification if you provide a website whose SSL cert chains up to each relevant sub-CA and has an AIA extension with OCSP. >> Audit Has the FCPF CA operations ever been audited against one of the following criteria (or equivalent)? ETSI TS 101 456 ETSI TS 102 042 WebTrust Principles and Criteria for Certification Authorities What is the frequency of this type of audit? >> Verifying ownership/control of domain name (for SSL certs) and email address (for S/MIME certs) > Section 3 of the FCPF CP describes the naming used. > The FPKIPA resolves any disputes on the names. > SSPs only issue certificates on behalf of Federal Agencies who > are responsible for the registration of their own domain names. I have reviewed FCPF CP section 3, and it is still not clear to me how the CAs/RAs are supposed to confirm that the certificate subscriber owns the domain name to be referenced in an SSL certificate. Also, it is still not clear to me how the CAs/RAs are supposed to confirm that the certificate subscriber owns the email address to be referenced in a certificate.

A new Federal Common Policy CA (FCPCA) has been established to support the US Federal government move to SHA-256. The Shared Service Providers (SSPs) supporting Federal agencies have received new certificates from this new Common Policy CA and it is also cross certified with a new Federal Bridge CA. This FCPCA does not use the IDP in its CRLs, so it also resolves the issue which caused problems for including the previous Common Policy Root certificate in the Mozilla trust list. So I am requesting to to include the new FCPCA root cert in the Mozilla trust list. URL to download the certificate: http://http.fpki.gov/fcpca/fcpca.crt URL for latest Common Policy CP: http://www.idmanagement.gov/fpkipa/documents/CommonPolicy.pdf

We can continue using this bug for this request. Please provide all of the information listed here: https://wiki.mozilla.org/CA:Information_checklist After you have provided the listed information for the new root and updated CP, I will proceed with the next phase: https://wiki.mozilla.org/CA:How_to_apply#Information_Verification.

This is the CA information for the new Federal Common Policy root certificate

Within this document, the items highlighted in yellow indicate where further clarification or information is needed.

This request has been added to the queue for public discussion: https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion Now that you have a request in the Queue for Public Discussion, you are directly impacted by the time it takes to work through the queue. The goal is to have each discussion take about two weeks. However, that time varies dramatically depending on the number of reviewers contributing to the discussion, and the types of concerns that are raised. If no one reviews and contributes to a discussion, then a request may be in the discussion for several weeks. When there are not enough people contributing to the discussions ahead of yours, then your request will sit in the queue longer. How can you help reduce the time that your request sits in the queue? You can help by reviewing and providing your feedback in the public discussions of root inclusion requests, or by asking a knowledgeable colleague to do so. Participating in other discussions is a great way to learn the expectations and be prepared for the discussion of your request. Please see: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

The CRL link on the Public Discussion post is incorrect (and actually for the older Common Policy Certificate) The correct CRL URL is: http://http.fpki.gov/fcpca/fcpca.crl How do I get this corrected? thanks, wendy

I have updated http://www.mozilla.org/projects/security/certs/pending/#US%20FPKI as requested.

This policy does not require that the CN part of device certificates is verified by the CA (see section 3.2.3.2). This is at odds with the current rules. (I assume that device certificates are those to be used with web sites.)

The Common Policy CP requires the human sponsor of a device is authenticated and the sponsor is responsible for providing: "Equipment authorizations and attributes (if any are to be included in the certificate)" which includes the name to be included as the subject of the certificate. However, I agree it could be more clearly stated that there is a requirement for the registration and validation of the device to meet the issuing agency's requirements for validating attributes to be included in the certificate. I will have to see if I can get a change proposal accepted to clarify this.

(In reply to comment #17) > This policy does not require that the CN part of device certificates is > verified by the CA (see section 3.2.3.2). This is at odds with the current > rules. (I assume that device certificates are those to be used with web > sites.) Arguably, no CA should be issuing domain or device names in the CN, since it's been deprecated ever since SubjectAlternativeName came about.

(In reply to comment #17) > This policy does not require that the CN part of device certificates is > verified by the CA (see section 3.2.3.2). This is at odds with the current > rules. (I assume that device certificates are those to be used with web > sites.) There is now a change proposal under discussion in the FPKI Certificate Policy Working Group (CPWG) to more closely align the requirements for validation of the contents of a device certificate with the requirements in the US Federal Bridge CA Certificate Policy. This would include adding the following text: "Device certificates shall be issued only to devices under the sponsor’s control, where control requirements are defined by the sponsor’s agency (i.e., require registration and validation that meets all issuing agency’s requirements, as well as requiring re-validation prior to being re-issued). In the case a human sponsor is changed, the new sponsor shall review the status of each device under his/her sponsorship to ensure it is still authorized to receive certificates. The CPS shall describe procedures to ensure that certificate accountability is maintained. The registration information and the identity of the sponsor shall be verified to an assurance level commensurate with the certificate assurance level being requested. Acceptable methods for performing this authentication and integrity checking include, but are not limited to: • 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." Would this change address the current concerns about not requiring the CA to verify all information in the device certificate including the CN and subjectAltName if one is included?

(In reply to comment #20) > (In reply to comment #17) > > This policy does not require that the CN part of device certificates is > > verified by the CA (see section 3.2.3.2). This is at odds with the current > > rules. (I assume that device certificates are those to be used with web > > sites.) > > [...] > > Would this change address the current concerns about not requiring the CA to > verify all information in the device certificate including the CN and > subjectAltName if one is included? Unfortunately no. The issue is "entitlement to use the DNS domain name". That status must be checked not with the sponsor or the sponsor's agency, but through ICANN (which was set up by the US Federal Government specifically to arbitrate the DNS). Only the host part of the DNS label is authoritative at the sponsor. The rest of it is authoritative at ICANN. It is via ICANN's methods that you must verify that entitlement.

(In reply to comment #21) > (In reply to comment #20) > > (In reply to comment #17) > > > This policy does not require that the CN part of device certificates is > > > verified by the CA (see section 3.2.3.2). This is at odds with the current > > > rules. (I assume that device certificates are those to be used with web > > > sites.) > > > > [...] > > > > Would this change address the current concerns about not requiring the CA to > > verify all information in the device certificate including the CN and > > subjectAltName if one is included? > > Unfortunately no. > > The issue is "entitlement to use the DNS domain name". That status must be > checked not with the sponsor or the sponsor's agency, but through ICANN (which > was set up by the US Federal Government specifically to arbitrate the DNS). > > Only the host part of the DNS label is authoritative at the sponsor. The rest > of it is authoritative at ICANN. It is via ICANN's methods that you must > verify that entitlement. Actually for the domains likely to be in use under the Common Policy GSA is the .gov domain registrar. Commerce is the .us domain registrar. DoD is the .mil domain registrar So the Agency validation requirements are likely to be more authoritative than checking with ICANN. https://www.dotgov.gov/portal/web/dotgov is the site used to validate the .gov domain names.

Er, ICANN owns .gov. It owns .com, .net, .org, .biz, and a whole bunch of others. Your agencies may have authority over defining the host names within their assigned domains, but the root of the Internet's public authority is ICANN. ICANN is the only entity which has authority over the root DNS domain. ICANN is the authority used by the end user. ICANN delegated .gov to GSA, and GSA did not lend any authority to ICANN for putting "gov" in the root servers. (GSA is authoritative for all of the names like 'dotgov.gov', but it is not authoritative for '.gov'.) Put another way: Mozilla does not trust GSA or Commerce or Defense for DNS names; it only trusts ICANN. ICANN may delegate portions of that trust upon GSA or Commerce or Defense, but ICANN is the ultimate authority for the Internet name space. The end user is the target of the security policy which Mozilla has put into effect. The threat model is hijacked TCP sessions. As an end user myself, I rely upon the subjectAlternativeName and the CN fields to tell me what the actual name of the host that I connected to is (even if I got the wrong IP address, I can currently expect that if I can connect to the https port I will get the assured name). Remember, Mozilla doesn't think solely about US citizenry, and you're not looking for a name constraint on your authority. You -must- verify the names of the hosts via the chain of authority rooted at ICANN, passed through GSA/Commerce/Defense, and verify that the asserted device name is correct via the Internet-standard methods. I understand that the state is the state. I also understand that Mozilla is not the state. The state cannot impose its will upon Mozilla (unless the US were to become a tyranny), and Mozilla's rules govern which authorities it includes. Its rules state that you must verify the DNS name via the methods that the user uses. If the policy is not updated to reflect this, then the FPKI Common Policy root will remain solely in the hands of the state and not in the hands of the citizen end user -- at least not via Mozilla's channel. (You're getting a lot of advance notice: normally this wouldn't have come up until your request came up in the queue, and that would have necessitated more wasted state-employee time while you sorted it all out.)

Thinking on this some more has led me to this: What is missing from your documentation is the process by which you verify that the DNS domain is actually controlled by the sponsoring agency. Once you verify that, then anyone the sponsoring agency permits (since you verify with the sponsoring agency) must be able to request certificates under that DNS domain. You provided a link to the means to verify the .gov namespace (though you should check those namespace delegations at regular intervals as well); what are the similar services for .mil and .us? If I'm understanding the Basic Guidelines correctly, the DNS domain control should be verified at least every 39 months. I would request that this verification be performed by the FPKI every 24 months or so, as major structural changes tend to happen approximately that often (as legislators and Presidents come and go).

Please review the CA Communication that was recently sent, and is available here: https://wiki.mozilla.org/CA:Communications Please add a comment to this bug to provide your response to the action items listed in the CA Communication. For more information about action items #1 and #3, please see items #6 and #7 of https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices

The CPS for Common Policy has been rewritten. The new URL is: http://www.idmanagement.gov/fpkipa/documents/FPKI_CPS_FBCAandCommon_redacted.pdf

7.1.5: Can you please give some examples of the name constraints which are normally specified in the LOA, and how you encode them into the certificate? Have there been/are there currently any instances where name constraints were not placed into the LOA, causing an unrestricted cross-certificate to issue? Also, my understanding is that the LOA only issues upon satisfactory completion of a readiness audit or operational audit. Is this correct?

(In reply to Kyle Hamilton from comment #27) > 7.1.5: Can you please give some examples of the name constraints which are > normally specified in the LOA, and how you encode them into the certificate? > Have there been/are there currently any instances where name constraints > were not placed into the LOA, causing an unrestricted cross-certificate to > issue? This is an example of a name constraint in an LOA for a certificate from the FBCA: nameConstaints: (critical Permitted [1]Subtrees (0..Max): Directory Address: OU=DoD O=U.S. Government C=US [2]Subtrees (0..Max): Directory Address: DC=mil Excluded=None This is the way it is displayed by one LDAP browser, looking at the certificate in our directory: Name Constraints (2.5.29.30) Critical Extension Permitted Subtrees Base: ou=DoD,o=U.S. Government,c=US, Minimum:0 Base: dc=mil, Minimum:0 Yes - we do not put name constraints in certificates that are issued to the SSPs who may be providing certificate services for multiple federal agencies. We rely on them to follow the Common Policy CP and verify the content of all certificates issued. Likewise for some of the commercial PKIs that are cross-certified with the FBCA may not be constrained as long as they have processes defined for verifying the content of all certificates issued, since they may have contracted to provided certificate services to multiple organizations. > > Also, my understanding is that the LOA only issues upon satisfactory > completion of a readiness audit or operational audit. Is this correct? Yes - review of an initial PKI Audit Letter is part of the process for approving a cross-certificate be issued.

(In reply to Wendy Brown from comment #28) > Yes - we do not put name constraints in certificates that are issued to the > SSPs who may be providing certificate services for multiple federal > agencies. We rely on them to follow the Common Policy CP and verify the > content of all certificates issued. Alright. As these cross-certifications exist for the convenience of the US Federal Government, and must have a sponsoring agency, is it correct to assume that these SSPs will always be in contract with their sponsoring agency? I'm trying to determine if there are any penalties in addition to revocation in the case of intentional or negligent failure to adhere to the Common Certificate Policy. (If contracts exist, then I deem the protection sufficient, since I know the penalty for breaking a contract with the federal government.) Also, I've downloaded caCertsIssuedByfbca.p7c, and OpenSSL pkcs7 doesn't like the format for some reason. I'll assume that this is a bug in OpenSSL and not worry about it too much, but I would like to know what format it's in. It looks much like a list of Certificates in a SignedData structure. If it is not sensitive information, what tool was used to create it? What tool(s) are you aware of which can parse it?

(In reply to Kyle Hamilton from comment #29) > (In reply to Wendy Brown from comment #28) > > Yes - we do not put name constraints in certificates that are issued to the > > SSPs who may be providing certificate services for multiple federal > > agencies. We rely on them to follow the Common Policy CP and verify the > > content of all certificates issued. > > Alright. As these cross-certifications exist for the convenience of the US > Federal Government, and must have a sponsoring agency, is it correct to > assume that these SSPs will always be in contract with their sponsoring > agency? I'm trying to determine if there are any penalties in addition to > revocation in the case of intentional or negligent failure to adhere to the > Common Certificate Policy. (If contracts exist, then I deem the protection > sufficient, since I know the penalty for breaking a contract with the > federal government.) > There are contracts in place between each SSP and the agencies they support. If you look here: http://www.idmanagement.gov/pages.cfm/page/Federal-PKI-Policy-Authority-Shared-Service-Provider-Working-Group-Certified-PKI-Shared-Service-Prov you will see the list of approved SSPs and that they each have been awarded Authority To Operate (ATO) as an SSP. > Also, I've downloaded caCertsIssuedByfbca.p7c, and OpenSSL pkcs7 doesn't > like the format for some reason. I'll assume that this is a bug in OpenSSL > and not worry about it too much, but I would like to know what format it's > in. It looks much like a list of Certificates in a SignedData structure. > If it is not sensitive information, what tool was used to create it? What > tool(s) are you aware of which can parse it? Our p7cs are created using OpenSSL. I look at the p7cs by renaming them to a p7b and just opening them with Windows. I believe Adobe, Outlook, and the PKI Interoperability Test Tool (PITT) don't have any problem with them, but I am not entirely sure since they may be using the LDAP URIs in certificates instead.

I would like to explain why I added the dependency on bug 651246. I was inspired to do so by a recent comment (8) added to that bug. The NSS library contains two separate modules for the purpose of finding a chain from an entity certificate to a trusted root certificate. The older of both modules is still the one used by default in Mozilla software. This older module uses a rather simple strategy for finding a chain. If there are multiple chains possible, and only one of several chains leads to a trusted root, then the older module might fail to find that chain. In order to explore all possible chains, NSS must use our newer chain-finding-module, which is a part of what we call libPKIX. The referenced comment suggests that only the newer libPKIX chain-finding code will be able to find chains to the root contained in this bug. If 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. Unfortunately there are problems that have stopped us from changing the default. We could use some helping (programmer) hands to get this done more quickly. Contributions are welcome.

What websites do not work now in Firefox, that would work if/when we include this certificate? Please post some links.

https://pki.ustreas.gov/ is the one that I can most instantly cite. (Federal Common Policy CA is cross-certified from US Federal Bridge CA.) 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 (such as StartCom). It's also got stronger protections against the CAs than we currently have (in the body of the Government Accounting Office and the laws which make punishments for contract violation fraud against the US Federal Government two to four times worse than for private fraud). If individual authentication is useful (and I daresay it is), failing to include this certificate is harmful to that use.

Please provide a current audit statement and also respond to the action items outlined here: https://wiki.mozilla.org/CA:Communications#February_17.2C_2012

My understanding is that Federal Bridge falls under option (e): e) SubCAs are publicly disclosed to Mozilla, audited by a competent party (per Mozilla’s CA Certificate Policy) whose audit result has been publicly disclosed to Mozilla, and technically and/or contractually restricted to issue certificates in full compliance with Mozilla's CA Certificate Policy. All incoming and outgoing cross-certifications are documented, and are audited by competent parties accredited ultimately by the US Federal Government. The audit results relating to the cross-certifications are documented with "Authorization to Issue" letters, though the audit results themselves (from the auditors) are not typically disclosed. There are contractual, legal, and highly-discoverable restrictions preventing willful or negligent noncompliance with the Federal Common Certificate Policy, which policy conforms to Mozilla's CA Certificate Policy. I believe that US Federal Government actually has a stronger interest in ensuring that its CAs issue only under its Common Policy than Mozilla has in ensuring that its CAs issue only under its CA Certificate Policy. As such, even if it doesn't provide actual audit reports for its cross certified CAs, I shall vote aye. Of course, I'd like there to be an excludedSubtrees involving every ccTLD other than .us. I won't hold my breath, though.

The latest audit for the FPKI Trust Infrastructure has just concluded. I will be able to make the latest audit statement available after it has been through the program management and FPKI Policy Authority(FPKIPA)review process. I agree with Kyle - we fall into the e) category - all subCAs are publicly disclosed and separately audited, with the audit letters reviewed by the FPKIPA. for #2 - I will have to get the FPKIPA to determine if they feel it is necessary to add such a statement about MITM or "traffic management" of domain names or IPs that the certificate holder does not legitimately own or control. We already include statements about the requirement to verify all contents of certificates. for #3 - any EV SSL certificates would be issued by FPKI Affiliates and they should have answered that directly. for #4 - we do not allow MD5 and RSA keys of 1024 are only allowed for id-fpki-common-authentication or id-fpki-common-cardAuth that expire before January 1, 2014. All other RSA certificates must be at least 2048 bit keys. Adding excludedSubtrees for every ccTLD other than .us (.gov and .mil) would make for very long nameConstraints.

The latest Audit review for the Federal Common Policy CA can be found at: http://www.idmanagement.gov/fpkima/documents/FPKI-audit-rev2-2012-jec-signed.pdf and the latest publicly available redacted version of our CPS is now posted here: http://www.idmanagement.gov/fpkipa/documents/FPKI_CPS_v4_1_Redacted_final_20120515.pdf Please let me know if we need to supply anything else for the public discussion.

I am now opening the first public discussion for this request from U.S. Federal PKI Management Authority (US FPKI) to add the “Federal Common Policy CA” root certificate, and to enable all three trust bits. For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding dev-security-policy@lists.mozilla.org mailing list. http://www.mozilla.org/community/developer-forums.html https://lists.mozilla.org/listinfo/dev-security-policy news://news.mozilla.org/mozilla.dev.security.policy The discussion thread is called “US FPKI Root Inclusion Request” Please actively review, respond, and contribute to the discussion. A representative of US FPKI must promptly respond directly in the discussion thread to all questions that are posted.

The first public discussion of this request is now closed. A second round of discussion will be needed after the technical evaluation and testing has been completed. 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. Additionally an investigation is needed to determine the plausibility 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. This work does not have to be performed by a current member of the NSS team, but will have to be reviewed/approved by the NSS team.

I have done a considerable amount of work in the area of making Federal PKI work on NSS and would like to add a point that appears to have been overlooked. Mozilla has already included the Builtin Object Token certificate "DST ACES CA X6". This certificate is cross certified with the FBCA, which already causes trust chains that can be built and trusted by NSS as is shipped by Mozilla. So I'd like to interject that the argument that trusting the FCPCA is adding the FBCA by cross certification is a true statement, but Mozilla has already done that by including the "DST ACES CA X6". Furthermore, the inclusion of the "DST ACES CA X6" certificates is should be less desired from a Federal PKI perspective than including the FCPCA certificate since the weak chain building code included in NSS can cause trust chain looping, bugs that have been in NSS for years. I'd suggest to consider removing the DST ACES CA X6 certificate from the built in object store of Mozilla. I also recommend adding the FCPCA certificate as the authoritative root as proposed, and if CA's such as DST ACES CA X6 need to be validated, they can chain in the appropriate direction through the FBCA through to the FCPCA root that should be build in as proposed. Even if you choose not to include the FCPCA at this time, I'd suggest you also remove the DST ACES CA X6 certificate since the very same arguments for not including the FPPCA also apply to that certificate you already are including. Furthermore due to the weak chaining in NSS, removing the DST ACES CA X6 from the built in object store will reduce chaining issues for the FPKI infrastructure. I can elaborate and show documented examples of the issues we are encountering due to NSS weakness and the inclusion of comercial SSP roots that are bridged with the FBCA such as "DST ACES CA X6", rather than including the authoritative root, the FCPCA.

Is there any update on the inclusion of the FCPCA root certificate as a default object in Mozilla software? We are seeing significant client base having problems using the browser because the root cert has not been included. Easily resolved by having them use another browser, but would like to get back to maximum deployment coverage like we had with the FCPCA predecessor (Common Policy).

(In reply to Kathleen Wilson from comment #41) > Additionally an investigation is needed to determine the plausibility 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. > The ability to apply name constraints to root certs is being worked on in bug #743700.

Now that the name constraints issue is marked as no longer blocking this issue is there a path forward to introducing the Federal Common Policy into the Mozilla/nss default store?

I will review/update my notes on this request, and open another discussion. My notes say that we can constrain this CA hierarchy to *.us, *.gov, and *.mil. Is that correct?

I am getting a recently expired Verisign cert on https://www.idmanagement.gov and in the listed URL in the application, which is http, http://www.idmanagement.gov/fpkima a "view static 404" page.

(In reply to Peter Bachman from comment #47) > I am getting a recently expired Verisign cert on > https://www.idmanagement.gov and in the listed URL in the application, which > is http, http://www.idmanagement.gov/fpkima a "view static 404" page. I confirm as of this post. Cert expired 2014-05-10 and http://www.idmanagement.gov/fpkima/documents/FPKI-audit-rev2-2012-jec-signed.pdf returns a 404.

The FPKI Management authority is aware of the SSL Certificate expiration and is working to resolve it. the other item you were looking for may have moved, but can be located here: http://idmanagement.gov/sites/default/files/documents/FPKI-audit-rev2-2012-jec-signed.pdf

The expired SSL certificate on idmnagement.gov has been replaced. We are aware they got a SHA-1 certificate for the site and we have asked them to obtain a SHA-2 certificate. Please be aware that the SSL certificate on that site is not issued under the Federal Common Policy.

Hello, any update to this issue? i see its blocked by another, but no updates since april.

Are there any updates on this issue as it relates to the entire US PKI Chain? Is this still a valid ticket or has it been replaced by another?

I will be re-evaluating this request soon. I had been waiting for the name constraints ability, such as bug #970542, which looks to be going into Firefox 37, https://wiki.mozilla.org/RapidRelease/Calendar

(In reply to Kathleen Wilson from comment #53) > I will be re-evaluating this request soon. > > I had been waiting for the name constraints ability, such as bug #970542, > which looks to be going into Firefox 37, > https://wiki.mozilla.org/RapidRelease/Calendar Great news. This is so important to .gov users.

(In reply to Kathleen Wilson from comment #53) > I will be re-evaluating this request soon. > > I had been waiting for the name constraints ability, such as bug #970542, > which looks to be going into Firefox 37, > https://wiki.mozilla.org/RapidRelease/Calendar I hope that the other government super-CAs, such as Brazil, will use this too.

I have re-evaluated this request, and entered the information into SalesForce. Please review the attached document for accuracy and completeness, and provide the information/clarification that is still needed.

I've reached out to the FPKI Management authority for action on the ~15 items in the attachment. They indicated they would be reviewing and providing information.

I'm gathering the information and will submit it soon.

I previously noted the expiration of the commercial SSL certificate that was assigned to one of the documentation artifacts. I also researched the name constraints section of RFC-5280 in an attempt the grasp the practical aspects of what had provoked the DNS issue. There was a clearly mistaken opinion in this thread that .gov and .mil were somehow under ICANN's jurisdiction, I was there during the discussion in which this was brought up in the '90s since we did DNS registrations at the time under .mil in discussions with GSA regarding the commercial, non governmental c=US country object in which I maintain intellectual property under OID 1.3.6.1.1 as part of my X.500 Directory startup that came out of the original NSF Pilot for DNS and Directory in 1993. Now reading the document in Comment #56 that lists the valid root certificate,and SHA 256 Hash, I am concerned regarding the position of the end user here in relying on provably insecure http URL reference in that document to access or name a valid root certificate. In light of recent history regarding IETF and IAB to secure the web, and certificate transparency, etc, I did a little experiment in which I downloaded using that URL into my trust store and got an entirely different certificate than what is in the document. Certainly not rocket science and part of any typical penetration test toolkit. I'm not saying the actual cited root certificate as stated is incorrect in the document, I'm saying a failure to provide a secure path for chaining discovery and the documentation to be included in the trust bundle (other than the evaluation to set the trust bundle bits)is inadequate security due to client side certificate attacks which are well known in the wild for the normal end user.

As an addendum. Apparently a fundamental explanatory document: http://www.idmanagement.gov/sites/default/files/documents/fpki_certificate_profile_May2015%20v1.2.pdf has no PADES digital signature attesting to it's authenticity, nor is there any TLS certificate currently associated with that site. A new GSA warning has been affixed which was not previously there saying the site is for "official" use only. Again, this can be explained via manipulation, however citing that unsigned PDF is instructive in any case, especially in explaining name constraints. On page 5 of the profile it states regarding out of band verification of the self signed certificates: "is transferred to the application or certificate using system in an authenticated manner. The signature on the trust anchor certificate cannot authenticate the certificate" Is in fact this the case with the trust bundle regarding inclusion? Exactly how is this being authenticated.

Good morning everyone, I work with Wendy and support the Federal PKI Management Authority. See CA responses below to be added to our bug report. Please let me know if this needs to be submitted in a form or another method. Website URL with an SSL certificate that chains to this root: https://obs-recruit.tsa.dhs.gov https://pki.treas.gov/ https://communities.firstresponder.gov Mozilla Applied Constraints - We would prefer not have these constraints added, but if Mozilla decides to go that route *.gov and *.mil would be required. It may impact user experience between different products that use the NSS Trust Store if the constrained is only with Firefox. List of Shared Service Providers can be found here: www.idmanagement.gov/list-certified-shared-service-providers cross-certified Affiliates can be found here: www.idmanagement.gov/entities-cross-certified-federal-bridge Requirements in CP for sub-CAs to take reasonable measures to verify the ownership of the domain name and email address for end-entity certificate chaining up to the root: CP: 3.2.3.2 Authentication of Devices: These certificates shall be issued only to authorized devices under the subscribing organization’s control. In the case a human sponsor is changed, the new sponsor shall review the status of each device under his/her sponsorship to ensure it is still authorized to receive certificates. The CPS shall describe procedures to ensure that certificate accountability is maintained. See section 9.6.3 for subscriber responsibilities. 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. And 3.2.4 Non-verified Subscriber Information Information that is not verified shall not be included in certificates. URL to published list of the SSPs and their CPS documents: The FPKIPA does not currently require SSPs to post their CPS Auditor information Name: Jimmy Jung Web site: http://slandala .com Qualifications – see Audit letter here: http://www.idmanagement.gov/documents/federal-pki-auditor-letter-compliance Audit Type – we follow the Federal PKI Audit requirements which can be found here: http://www.idmanagement.gov/documents/fpkicompliance-audit-requirements Date of last audit letter: 7/1/2014 BR Audit – all SSPs are required to undergo external audit that meet the Federal PKI Audit requirements see URL above, but we do not require they post their audit letters at this time. A bundle of CA certificates that validate up to the FCPCA can be found here: http://fpkiapps.icam.pgs-lab.com/fbcaApps/allCerts/paths/CACertificatesValidatingToFederalCommonPolicy.p7b This gets automatically updated once a week We do not require them to publish CPS or annual audit letter, but the FPKI Policy Authority does require the audit letters to be submitted for review on an annual basis. Devices that are the subject of certificates issued under this policy shall be assigned either a geo-political name or an Internet domain component name. Device names shall take one of the following forms: • C=US, o=U.S. Government, [ou=department], [ou=agency], [ou=structural_container], cn=device name • dc=gov, dc=org0, [dc=org1], …, [dc=orgN], [ou=structural_container], [cn=device name] • dc=mil, dc=org0, [dc=org1], …, [dc=orgN], [ou=structural_container], [cn=device name] • where device name is a descriptive name for the device. Where a device is fully described by the Internet domain name, the common name attribute is optional. • We do not technically constrain subCAs with EKU – we require them all to undergo external audits on an annual basis and those audit letters are reviewed • FPKI Audit Requirements are used for the annual audits of all conforming CAs

(In reply to Ken Myers from comment #61) > <snip> > URL to published list of the SSPs and their CPS documents: The FPKIPA does > not currently require SSPs to post their CPS > <snip> > BR Audit – all SSPs are required to undergo external audit that meet the > Federal PKI Audit requirements see URL above, but we do not require they > post their audit letters at this time. > <snip> > We do not require them to publish CPS or annual audit letter, but the FPKI > Policy Authority does require the audit letters to be submitted for review > on an annual basis. > <snip> > We do not technically constrain subCAs with EKU – we require them all to > undergo external audits on an annual basis and those audit letters are > reviewed > <snip> > FPKI Audit Requirements are used for the annual audits of all conforming > CAs Hi Ken, Thank you for your thorough response. As per Mozilla's CA Certificate Inclusion Policy, we require public-facing CP/CPS documentation and annual audit statements for non-technically-constrained subordinate CAs chaining up to root certificates in Mozilla's program. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ "10. We recognize that technically constraining subordinate CA certificates as described above may not be practical in some cases. All certificates that are capable of being used to issue new certificates, that are not technically constrained, and that directly or transitively chain to a certificate included in Mozilla’s CA Certificate Program MUST be audited in accordance with Mozilla’s CA Certificate Policy and MUST be publicly disclosed by the CA that has their certificate included in Mozilla’s CA Certificate Program. ... For a certificate to be considered publicly disclosed and audited, the following information MUST be provided: ... The corresponding Certificate Policy or Certification Practice Statement used by the subordinate CA; and ... Annual public attestation of conformance..." Based on your response in Comment #61, it is my opinion that the US FPKI should be treated as a Super-CA as described here: https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs As such, the path forward for this CA hierarchy is to have the SSPs apply for inclusion themselves. Therefore, this request for inclusion of the US FPKI root certificate will be on hold, pending inclusion of its subordinate CAs. The subordinate CAs (SSPs) should create separate Bugzilla bugs and apply for inclusion themselves as separate trust anchors, https://wiki.mozilla.org/CA:How_to_apply. Thanks, Kathleen

(In reply to Peter Bachman from comment #59) > I previously noted the expiration of the commercial SSL certificate that was > assigned to one of the documentation artifacts. I also researched the name > constraints section of RFC-5280 in an attempt the grasp the practical > aspects of what had provoked the DNS issue. There was a clearly mistaken > opinion in this thread that .gov and .mil were somehow under ICANN's > jurisdiction, I was there during the discussion in which this was brought up > in the '90s since we did DNS registrations at the time under .mil in > discussions with GSA regarding the commercial, non governmental c=US country > object in which I maintain intellectual property under OID 1.3.6.1.1 as part > of my X.500 Directory startup that came out of the original NSF Pilot for > DNS and Directory in 1993. > > Now reading the document in Comment #56 that lists the valid root > certificate,and SHA 256 Hash, I am concerned regarding the position of the > end user here in relying on provably insecure http URL reference in that > document to access or name a valid root certificate. > > In light of recent history regarding IETF and IAB to secure the web, and > certificate transparency, etc, I did a little experiment in which I > downloaded using that URL into my trust store and got an entirely different > certificate than what is in the document. Certainly not rocket science and > part of any typical penetration test toolkit. > > I'm not saying the actual cited root certificate as stated is incorrect in > the document, I'm saying a failure to provide a secure path for chaining > discovery and the documentation to be included in the trust bundle (other > than the evaluation to set the trust bundle bits)is inadequate security due > to client side certificate attacks which are well known in the wild for the > normal end user. Hi Peter, We've update the site map document and it is digitally signed by the Federal PKI Management Authority Program Manager. I think that is what you were asking for. What certificate did you download that was different from the document? Can you send me a copy?

(In reply to Kathleen Wilson from comment #62) > (In reply to Ken Myers from comment #61) > > <snip> > > URL to published list of the SSPs and their CPS documents: The FPKIPA does > > not currently require SSPs to post their CPS > > <snip> > > BR Audit – all SSPs are required to undergo external audit that meet the > > Federal PKI Audit requirements see URL above, but we do not require they > > post their audit letters at this time. > > <snip> > > We do not require them to publish CPS or annual audit letter, but the FPKI > > Policy Authority does require the audit letters to be submitted for review > > on an annual basis. > > <snip> > > We do not technically constrain subCAs with EKU – we require them all to > > undergo external audits on an annual basis and those audit letters are > > reviewed > > <snip> > > FPKI Audit Requirements are used for the annual audits of all conforming > > CAs > > Hi Ken, > > Thank you for your thorough response. > > As per Mozilla's CA Certificate Inclusion Policy, we require public-facing > CP/CPS documentation and annual audit statements for > non-technically-constrained subordinate CAs chaining up to root certificates > in Mozilla's program. > > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/ > policy/inclusion/ > "10. We recognize that technically constraining subordinate CA certificates > as described above may not be practical in some cases. All certificates that > are capable of being used to issue new certificates, that are not > technically constrained, and that directly or transitively chain to a > certificate included in Mozilla’s CA Certificate Program MUST be audited in > accordance with Mozilla’s CA Certificate Policy and MUST be publicly > disclosed by the CA that has their certificate included in Mozilla’s CA > Certificate Program. ... For a certificate to be considered publicly > disclosed and audited, the following information MUST be provided: > ... The corresponding Certificate Policy or Certification Practice Statement > used by the subordinate CA; and > ... Annual public attestation of conformance..." > > > Based on your response in Comment #61, it is my opinion that the US FPKI > should be treated as a Super-CA as described here: > https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs > > As such, the path forward for this CA hierarchy is to have the SSPs apply > for inclusion themselves. > > Therefore, this request for inclusion of the US FPKI root certificate will > be on hold, pending inclusion of its subordinate CAs. The subordinate CAs > (SSPs) should create separate Bugzilla bugs and apply for inclusion > themselves as separate trust anchors, > https://wiki.mozilla.org/CA:How_to_apply. > > Thanks, > Kathleen Hi Kathleen, Thank you for the feedback. I will take this back to the Policy Authority for discussion. Ken

(In reply to Kathleen Wilson from comment #62) > (In reply to Ken Myers from comment #61) > > <snip> > > URL to published list of the SSPs and their CPS documents: The FPKIPA does > > not currently require SSPs to post their CPS > > <snip> > > BR Audit – all SSPs are required to undergo external audit that meet the > > Federal PKI Audit requirements see URL above, but we do not require they > > post their audit letters at this time. > > <snip> > > We do not require them to publish CPS or annual audit letter, but the FPKI > > Policy Authority does require the audit letters to be submitted for review > > on an annual basis. > > <snip> > > We do not technically constrain subCAs with EKU – we require them all to > > undergo external audits on an annual basis and those audit letters are > > reviewed > > <snip> > > FPKI Audit Requirements are used for the annual audits of all conforming > > CAs > > Hi Ken, > > Thank you for your thorough response. > > As per Mozilla's CA Certificate Inclusion Policy, we require public-facing > CP/CPS documentation and annual audit statements for > non-technically-constrained subordinate CAs chaining up to root certificates > in Mozilla's program. > > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/ > policy/inclusion/ > "10. We recognize that technically constraining subordinate CA certificates > as described above may not be practical in some cases. All certificates that > are capable of being used to issue new certificates, that are not > technically constrained, and that directly or transitively chain to a > certificate included in Mozilla’s CA Certificate Program MUST be audited in > accordance with Mozilla’s CA Certificate Policy and MUST be publicly > disclosed by the CA that has their certificate included in Mozilla’s CA > Certificate Program. ... For a certificate to be considered publicly > disclosed and audited, the following information MUST be provided: > ... The corresponding Certificate Policy or Certification Practice Statement > used by the subordinate CA; and > ... Annual public attestation of conformance..." > > > Based on your response in Comment #61, it is my opinion that the US FPKI > should be treated as a Super-CA as described here: > https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs > > As such, the path forward for this CA hierarchy is to have the SSPs apply > for inclusion themselves. > > Therefore, this request for inclusion of the US FPKI root certificate will > be on hold, pending inclusion of its subordinate CAs. The subordinate CAs > (SSPs) should create separate Bugzilla bugs and apply for inclusion > themselves as separate trust anchors, > https://wiki.mozilla.org/CA:How_to_apply. > > Thanks, > Kathleen Hi Kathleen, Quick question. I was wondering if we post the Shared Service Providers (SSP) CPS and Audit letters if that would be sufficient to meet the requirement? We do not want the SSPs to apply because in several cases they are issuing directly from the CA that is subordinate to the FCPCA and that would violate the Mozila requirement that trust roots should not directly issue end-entity certificates. They also all operate under the same CP, the Federal Common Policy Certificate Policy. Please let me know if posting their CPS and Audit letters will meet your criteria. Ken

(In reply to Ken Myers from comment #65) > I was wondering if we post the Shared Service Providers (SSP) CPS and Audit > letters if that would be sufficient to meet the requirement? We do not want > the SSPs to apply because in several cases they are issuing directly from > the CA that is subordinate to the FCPCA and that would violate the Mozila > requirement that trust roots should not directly issue end-entity > certificates. They also all operate under the same CP, the Federal Common > Policy Certificate Policy. Please let me know if posting their CPS and Audit > letters will meet your criteria. https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs "... until the following has been established and demonstrated: - The Super-CA’s documented policies and audit criteria meet the requirements of Mozilla’s CA Certificate Policy, which includes the CA/Browser Forum’s Baseline Requirements, and includes sufficient information about verification practices and issuance of end-entity certificates. - The Super-CA is at all times completely accountable for their subordinate CAs, and the Super-CA ensures that all subordinate CAs demonstrably adhere to the Super-CA’s documented policies and audit criteria. - The Super-CA provides publicly verifiable documentation and proof of annual audits for each subordinate CA that attest to compliance with the Super-CA’s documented policies and audit criteria." So, the US FPKI CA would need to provide public-facing documentation of the SSPs' CP/CPS and annual audit statements that demonstrate that the SSPs meet Mozilla's policy requirements and the CA/Browser Forum's Baseline Requirements. And the US FPKI CA's policy documentation would need to make these requirements for SSPs clear.

Thank you for helping develop the CPS documents public access and requirements so that there is traceable set of documents. I checked with https://pulse.cio.gov/https/domains/#q=General%20Services%20Administration which rates the SSL/TLS performance of .gov websites and idmanagement.gov has moved it's previous SSL certificate from public facing, to a specific "log in" page. According to the CIO https survey software, a redirect changes the public access from TLS to no encryption. Looking at the "login" page certificate information, it is of course commercial, (which is no problem) however it is also SHA-1 which contradicts earlier comments. I'm making an assumption that the "login" page is not also intended for public use. So I think this makes the point clearly. No HTTPS for the public documents. A warning sign placing it into the following information category. "4. Definitions Access: The ability or opportunity to gain knowledge of information. For Official Use Only (FOUO): The term used within DHS to identify unclassified information of a sensitive nature, not otherwise categorized by statute or regulation, the unauthorized disclosure of which could adversely impact a person's privacy or welfare, the conduct of Federal programs, or other programs or operations essential to the national interest. Information impacting the National Security of the United States and classified Confidential, Secret, or Top Secret under Executive Order 12958, "Classified National Security Information," as amended, or its predecessor or successor orders, is not to be considered FOUO. FOUO is not to be considered classified information. Need-to-know: The determination made by an authorized holder of information that a prospective recipient requires access to specific information in order to perform or assist in a lawful and authorized governmental function, i.e., access is required for the performance of official duties." -------------------- My previous comment regarding "signed CA documents" (using PADES, for example but not limited to that technology), relates to the PDF docs in which I did not see previously digitally signed documents which typically are signed by an authorized signer within the PKI. Apparently these are supposed to be signed, checking back in the comments, so I am going to look again to see if those documents supporting the CPS etc. are in fact signed. I didn't see that. The basic best practice concepts in establishing a document trust chain for the public and Federal Employees are detailed in the NIST 2000 era document SP-800-25, I didn't see any updates that would change these concepts. "Individuals (including Federal employees) or other entities interacting with Federal agencies electronically where there is a need for a secure transaction should have reasonable assurance that: (1) the information sender and recipient both will be identified uniquely so the parties know where the information is coming from and where it is going (identification and authentication); (2) the transmitted information was not altered deliberately or inadvertently (data integrity); (3) there is a way to establish that the sender’s identity is inextricably bound to the information (technical non-repudiation); and (4) The information will be protected from unauthorized access (confidentiality or privacy). This functionality is included for completeness since public key technology and a Public Key Infrastructure provide it; however, confidentiality and privacy concerns are not covered in detail in this guidance." Since the original documents and citations in the thread that were submitted as supporting material to be included in the Trust Bundle can't at this moment be easily proven to be authoritative to the average end user, this leaves an end user in a grey area that should be resolved.

Is there any update to this root CA being published by default in the root store?

Has there been any movement on the part of the US PKI Office to publish their information? We are getting ready to start our transition to https only and without this we will be forced to purchase commercial certificates which is a gross waste of taxpayer dollars.

(In reply to Steve W from comment #69) > Has there been any movement on the part of the US PKI Office to publish > their information? We are getting ready to start our transition to https > only and without this we will be forced to purchase commercial certificates > which is a gross waste of taxpayer dollars. I'd love to see the FPKI be accepted into the Mozilla trusted root program, but so it's clear, even if the FPKI application were accepted today, it would take years for the FPKI's root certificate to get distributed to enough public devices for most US government websites to rely on it being present. And given that Mozilla now requires all unconstrained subordinate CAs to be audited as independent roots, it doesn't seem likely to be accepted immediately. One alternative is for FPKI to pursue an interim cross-signature from a root already trusted throughout the world, which is what Let's Encrypt (letsencrypt.org) has done with Identrust, though I don't believe that would resolve the unconstrained subordinate CA issue (which the cross-signer would be on the hook for). US government agencies transitioning to HTTPS only should not find certificate costs to be a major problem, certainly not to the level that they would be a gross waste of taxpayer dollars. If your agency has internal policies that require the agency to only use highly expensive certificates, that policy is what might waste taxpayer dollars, and should be revised immediately. My US government team, and many others, have found no problem using extremely inexpensive domain-validated certificates from the commercial sector. It should be a negligible cost, and enterprise contracts and outdated internal policies should not be allowed to get in the way. While I'm not endorsing a specific vendor, it's worth noting that yesterday, Let's Encrypt posted a USG-friendly Terms of Service amendment: https://letsencrypt.org/documents/LE-USG-SA-Amendment-Sept-22-2015.pdf It was negotiated with the General Services Administration, and hopefully should contribute positively to providing agency assurance about using inexpensive or free domain-validated certificates during the transition to HTTPS.

(In reply to Eric Mill from comment #70) > (In reply to Steve W from comment #69) > > Has there been any movement on the part of the US PKI Office to publish > > their information? We are getting ready to start our transition to https > > only and without this we will be forced to purchase commercial certificates > > which is a gross waste of taxpayer dollars. > > I'd love to see the FPKI be accepted into the Mozilla trusted root program, > but so it's clear, even if the FPKI application were accepted today, it > would take years for the FPKI's root certificate to get distributed to > enough public devices for most US government websites to rely on it being > present. And given that Mozilla now requires all unconstrained subordinate > CAs to be audited as independent roots, it doesn't seem likely to be > accepted immediately. > > One alternative is for FPKI to pursue an interim cross-signature from a root > already trusted throughout the world, which is what Let's Encrypt > (letsencrypt.org) has done with Identrust, though I don't believe that would > resolve the unconstrained subordinate CA issue (which the cross-signer would > be on the hook for). > > US government agencies transitioning to HTTPS only should not find > certificate costs to be a major problem, certainly not to the level that > they would be a gross waste of taxpayer dollars. If your agency has internal > policies that require the agency to only use highly expensive certificates, > that policy is what might waste taxpayer dollars, and should be revised > immediately. > > My US government team, and many others, have found no problem using > extremely inexpensive domain-validated certificates from the commercial > sector. It should be a negligible cost, and enterprise contracts and > outdated internal policies should not be allowed to get in the way. > > While I'm not endorsing a specific vendor, it's worth noting that yesterday, > Let's Encrypt posted a USG-friendly Terms of Service amendment: > https://letsencrypt.org/documents/LE-USG-SA-Amendment-Sept-22-2015.pdf It > was negotiated with the General Services Administration, and hopefully > should contribute positively to providing agency assurance about using > inexpensive or free domain-validated certificates during the transition to > HTTPS. Thank you for the info. Found it humorous that I received a certificate error when trying to get the pdf mentioned (in IE no less). With 300 websites that need individual certificates within one agency, cost is an issue (especially when you add in the contracting overhead). As a taxpayer, if the government spends money that it shouldn't need to, it is a waste.

(In reply to Kathleen Wilson from comment #66) > (In reply to Ken Myers from comment #65) > > I was wondering if we post the Shared Service Providers (SSP) CPS and Audit > > letters if that would be sufficient to meet the requirement? We do not want > > the SSPs to apply because in several cases they are issuing directly from > > the CA that is subordinate to the FCPCA and that would violate the Mozila > > requirement that trust roots should not directly issue end-entity > > certificates. They also all operate under the same CP, the Federal Common > > Policy Certificate Policy. Please let me know if posting their CPS and Audit > > letters will meet your criteria. > > > https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs > "... until the following has been established and demonstrated: > - The Super-CA’s documented policies and audit criteria meet the > requirements of Mozilla’s CA Certificate Policy, which includes the > CA/Browser Forum’s Baseline Requirements, and includes sufficient > information about verification practices and issuance of end-entity > certificates. > - The Super-CA is at all times completely accountable for their subordinate > CAs, and the Super-CA ensures that all subordinate CAs demonstrably adhere > to the Super-CA’s documented policies and audit criteria. > - The Super-CA provides publicly verifiable documentation and proof of > annual audits for each subordinate CA that attest to compliance with the > Super-CA’s documented policies and audit criteria." > > > So, the US FPKI CA would need to provide public-facing documentation of the > SSPs' CP/CPS and annual audit statements that demonstrate that the SSPs meet > Mozilla's policy requirements and the CA/Browser Forum's Baseline > Requirements. And the US FPKI CA's policy documentation would need to make > these requirements for SSPs clear. Hi Kathleen, Wanted to give a quick update that the Federal PKI continues to work toward meeting the two requirements. 1) Provide public facing documents for SSP CP, CPS, and Audit Letters. Currently, there are six SSPs who are working toward redacting CPS' and posting approved audit letters. I'm tracking this and will report back with the location of the public facing documents as they are updated/posted. 2) Clear statement and demonstration that SSPs meet CAB Forum BRs and Mozilla Policy Requirements A BR Change Proposal has been submitted to the Federal PKI Certificate Policy working group to harmonize the requirements between the CAB Forum BRs and the Federal Common Policy CP. Once this change proposal is approved and implemented, the Federal Common Policy and subordinate SSP CAs will follow CAB Forum and Mozilla Policy requirements for device certificates. Please let me know if you have any questions or I missed anything in the mean time. Thanks!

I found today that NASA Operational CA (which is a subCA of US Treasury Root CA, and US Treasury Root CA is a subCA of FCPCA) kept issuing many SSL certificates without Subject Alternative Names, which I think is a violation of Baseline Requirements. See https://crt.sh/?lint=37&iCAID=5342&opt=cablint,x509lint, and compare https://crt.sh/?dNSName=%25&iCAID=5342 (certs with SAN) with https://crt.sh/?Identity=%25&iCAID=5342 (all certs). Maybe FCPCA should notify NASA CA of this mistake?

Thank you for the notice. A change proposal to incorporate CAB Forum BR is currently in discussion with a US Federal PKI working group. Currently, SAN is an optional extension according to the SSP certificate profile (https://www.idmanagement.gov/IDM/servlet/fileField?entityId=ka0t0000000TNP2AAO&field=File__Body__s). The change proposal includes the requirement that a SAN is a mandatory extension.

(In reply to Xiaoyin Liu from comment #73) > I found today that NASA Operational CA (which is a subCA of US Treasury Root > CA, and US Treasury Root CA is a subCA of FCPCA) kept issuing many SSL > certificates without Subject Alternative Names, which I think is a violation > of Baseline Requirements. See > https://crt.sh/?lint=37&iCAID=5342&opt=cablint,x509lint, and compare > https://crt.sh/?dNSName=%25&iCAID=5342 (certs with SAN) with > https://crt.sh/?Identity=%25&iCAID=5342 (all certs). Maybe FCPCA should > notify NASA CA of this mistake? Thank you for the notice. A change proposal to incorporate CAB Forum BR is currently in discussion with a US Federal PKI working group. Currently, SAN is an optional extension according to the SSP certificate profile (https://www.idmanagement.gov/IDM/servlet/fileField?entityId=ka0t0000000TNP2AAO&field=File__Body__s). The change proposal includes the requirement that a SAN is a mandatory extension.

(In reply to Ken Myers from comment #72) > (In reply to Kathleen Wilson from comment #66) > > (In reply to Ken Myers from comment #65) > > > I was wondering if we post the Shared Service Providers (SSP) CPS and Audit > > > letters if that would be sufficient to meet the requirement? We do not want > > > the SSPs to apply because in several cases they are issuing directly from > > > the CA that is subordinate to the FCPCA and that would violate the Mozila > > > requirement that trust roots should not directly issue end-entity > > > certificates. They also all operate under the same CP, the Federal Common > > > Policy Certificate Policy. Please let me know if posting their CPS and Audit > > > letters will meet your criteria. > > > > > > https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs > > "... until the following has been established and demonstrated: > > - The Super-CA’s documented policies and audit criteria meet the > > requirements of Mozilla’s CA Certificate Policy, which includes the > > CA/Browser Forum’s Baseline Requirements, and includes sufficient > > information about verification practices and issuance of end-entity > > certificates. > > - The Super-CA is at all times completely accountable for their subordinate > > CAs, and the Super-CA ensures that all subordinate CAs demonstrably adhere > > to the Super-CA’s documented policies and audit criteria. > > - The Super-CA provides publicly verifiable documentation and proof of > > annual audits for each subordinate CA that attest to compliance with the > > Super-CA’s documented policies and audit criteria." > > > > > > So, the US FPKI CA would need to provide public-facing documentation of the > > SSPs' CP/CPS and annual audit statements that demonstrate that the SSPs meet > > Mozilla's policy requirements and the CA/Browser Forum's Baseline > > Requirements. And the US FPKI CA's policy documentation would need to make > > these requirements for SSPs clear. > > Hi Kathleen, > > Wanted to give a quick update that the Federal PKI continues to work toward > meeting the two requirements. > > 1) Provide public facing documents for SSP CP, CPS, and Audit Letters. > Currently, there are six SSPs who are working toward redacting CPS' and > posting approved audit letters. I'm tracking this and will report back with > the location of the public facing documents as they are updated/posted. > > > 2) Clear statement and demonstration that SSPs meet CAB Forum BRs and > Mozilla Policy Requirements > A BR Change Proposal has been submitted to the Federal PKI Certificate > Policy working group to harmonize the requirements between the CAB Forum BRs > and the Federal Common Policy CP. Once this change proposal is approved and > implemented, the Federal Common Policy and subordinate SSP CAs will follow > CAB Forum and Mozilla Policy requirements for device certificates. > > Please let me know if you have any questions or I missed anything in the > mean time. Thanks! Good afternoon, Quick update from the Federal PKI. The BR / Device Change Proposal, which incorporated requirements from the CAB Forum BRs v1.3, has completed its internal review period and is now in review by the FPKI Policy Authority. If the change proposal passes, the FCPCA CP will be updated and I will notify when that happens. There are currently seven CAs certified under the FCPCA root and I am working with them to post either a full or redacted CPS and an audit letter. Three of the seven of public documents posted. I'm anticipating a few more to posted by the end of October. FCPCA Information FCPCA CPS - https://www.idmanagement.gov/IDM/s/document_detail?Id=kA0t00000008ObpCAE FCPCA CP - https://www.idmanagement.gov/IDM/s/document_detail?Id=kA0t00000008ObqCAE FCPCA Audit Letter - https://www.idmanagement.gov/IDM/s/article_detail?link=fpki-audit-info Symantec CPS - https://www.symantec.com/content/en/us/about/media/repository/ssp-cps.pdf Verizon CPS - http://cp1.govt.com-strong-id.net/CPS/Verizon-IAM-Federal-Shared-Service-Provider-CPS_v2_1.pdf Let me know if a spreadsheet will be easier to use.

(In reply to Ken Myers from comment #76) > > There are currently seven CAs certified under the FCPCA root and I am > working with them to post either a full or redacted CPS and an audit letter. > Three of the seven of public documents posted. I'm anticipating a few more > to posted by the end of October. Does a redacted CPS satisfy Mozilla policy requirements? Is not the complete CPS required?

(In reply to David E. Ross from comment #77) > Does a redacted CPS satisfy Mozilla policy requirements? Is not the > complete CPS required? That's a good question. I think that if the CA has policy/procedures that cannot be public-facing, that perhaps those belong in a different document. I think it is reasonable to expect that the CP/CPS document(s) provided to meet Mozilla's root inclusion (and maintenance) policy not be redacted.

(In reply to Kathleen Wilson from comment #78) > (In reply to David E. Ross from comment #77) > > Does a redacted CPS satisfy Mozilla policy requirements? Is not the > > complete CPS required? > > That's a good question. > > I think that if the CA has policy/procedures that cannot be public-facing, > that perhaps those belong in a different document. > I think it is reasonable to expect that the CP/CPS document(s) provided to > meet Mozilla's root inclusion (and maintenance) policy not be redacted. The July 2016 version is online and redacted. It has a classification designation which means it is under classification document controls. I don't expect an end user should have to file a FOIA request to get a policy document, it is an unreasonable burden. The redacted version also lacks a valid PDF or even a facsimile of a signature which if one goes back through the thread does not make it a valid document for a relying party. We are talking about a verifiable audit trail. https://www.idmanagement.gov/wp-content/uploads/sites/1171/uploads/fpki-cps-redacted.pdf

I just noticed that the submitter and point of contact for this request does not have a U.S. government E-mail address. Has anyone verified that the owner of the root is indeed a U.S. government agency? If the U.S. government does indeed own the root, has anyone verified that the U.S. government wants the subject root to be added to NSS?

(In reply to David E. Ross from comment #80) > I just noticed that the submitter and point of contact for this request does > not have a U.S. government E-mail address. Has anyone verified that the > owner of the root is indeed a U.S. government agency? If the U.S. > government does indeed own the root, has anyone verified that the U.S. > government wants the subject root to be added to NSS? Yes, this has been verified. Protiviti is a contractor to the US Government who helps manage the US Federal PKI. The CA that is the subject of this bug is listed on https://www.idmanagement.gov/ and https://iase.disa.mil/pki-pke/interoperability/ Given that the Federal PKI has indicated they are creating a new root specifically to be BR compliant (https://github.com/uspki/policies), it is not clear if they are still also requesting inclusion of the Common Policy CA.

I'm going to close this bug. This CA may re-apply by filing a new bug, as described here: https://wiki.mozilla.org/CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request