uspki / policies Goto Github PK

I suggest we only accept RFC 3647 format and not 2527 as well

Is FPKI going to allow a grace period? How long? If not say so. Recommend using current COMMON language:
“There is no revocation grace period. Responsible parties must request revocation as soon as they identify the need for revocation.”

https://github.com/uspki/policies/blob/section6/certificate-policy.md#617-key-usage-purposes-as-per-x509-v3-key-usage-field

remove bullet 5 in entirety

• clauses referenced in bullet 5 are old (pre-dates the effective date) and should not be allowed

change from MUST NOT to SHALL NOT per #17

Section 1.6.4. and throughout.

I know that RFCs typically says " The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

My preference (which is what DoD does) is that we not mix words. Choose and stick with specific words and not switch around. Despite what the RFCs says, people get confused when different words are used.

Recommend changing 1.6.4 to say that This CP SHALL:
Use SHALL and SHALL NOT for requirements;
Not use "SHOULD and SHOULD NOT"; and,
Use MAY when something is optional.

SHOULD and SHOULD NOT are not anything in a policy. People confuse them with requirements when they are really options (MAY).

And, yes, I know CA/B forum uses all of the above... Still not good policy language.

Needs to be updated to align with NIST SP 800-131A and FIPS 186-4 AND larger key sizes and dates

Currently, Section 6.1.5 for subscriber certificates states:

(3) Subscriber Certificates

Needs to be updated to align with NIST SP 800-131A and FIPS 186-4 AND larger key size for the root (minimum 4096)

Currently in Section 6.1.5

(1) Root CA Certificates

This section cites Section 9.6.3 provisions 2 and 4. Section 9.6.3 is the Subscriber agreement. This seems backwards to me - the subscriber agreement is developed from the CP requirements not the other way around. Recommend Applicant/Applicant Representative obligations/limitations associated with usage of these device certificates be stipulated here for inclusion in subscriber agreement.

Recommend some information on the criteria and contents for submitting a certificate application be included here. FPKI COMMON Policy provides good candidate language.
"The Certificate application process must provide sufficient information to:
 Establish the applicant’s authorization to obtain a certificate.
 Establish and record identity of the applicant.
 Obtain the applicant’s public key and verify the applicant’s possession of the private key for each certificate required."

Recommend adopting FPKI COMMON language here:
"Failure to object to the certificate or its contents shall constitute acceptance of the certificate."

The CA/Browser Forum documents are at a minimum licensed under CC-BY. ("This work is licensed under the Creative Commons Attribution 4.0 International license.")

Further, each contributor to the CABF documents has agreed to "license to all, worldwide, whether or not they are CAB Forum Participants to reproduce, distribute, make derivative works and display" the documents.

So CC-ND is never in play.

Federal PKI Device Policy needs to respond to this requirement not parrot it:
"The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate's approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements."
e.g. "The FPKI SHALL maintain a list of names at higher risk for phishing or other fraudulent usage, names contained in previously rejected certificate requests or revoked Certificates, or names that have been identified using an FPKI risk-mitigation criteria. The CA SHALL review all certificate requests against this identify High Risk Certificate Requests. Once identified, High Risk Certificate Requests SHALL be flagged for additional review, which SHALL include contacting the Applicant Representative for certificate request verification and obtaining a secondary authorization from an Agency Authorizing Official."
(note: this is suggested place-holder language only).

See: https://github.com/uspki/policies/blob/master/certificate-policy.md#323-authentication-of-individual-identity

As far as I understand, this CP is for issuing device certificates, and not certificates to humans. The only time I assume individuals are authenticated, is if they are a POC/device sponsor/etc.

If this is the case, the policy requirements for "Authentication of individual identity" appears limited, and based on traditional/analog means derived in 1876. ( I.e., photo ID ) Further, is there any value of understanding the Individual's address?

The current language is below:

If an Applicant subject to this Section is a natural person, then the CA SHALL verify the Applicant's name, Applicant's address, and the authenticity of the certificate request.

The CA SHALL verify the Applicant's name using a legible copy, which discernibly shows the Applicant's face, of at least one currently valid government-issued photo ID (passport, drivers license, military ID, national ID, or equivalent document type). The CA SHALL inspect the copy for any indication of alteration or falsification.

The CA SHALL verify the Applicant's address using a form of identification that the CA determines to be reliable, such as a government ID, utility bill, or bank or credit card statement. The CA MAY rely on the same government-issued ID that was used to verify the Applicant's name.

The CA SHALL verify the certificate request with the Applicant using a Reliable Method of Communication.

We have spent a lot of time and public funds for PIV and PIV-I credentials. Could a digital signature from any of those credentials suffice for this requirement? Further, consider an automated certificate management protocol, such as ACME, and authentication of the administrator. See:

https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme.md

Adding emphasis on the item below:

Receive CA challenge at a (hopefully) administrator-controlled e-mail address corresponding to the domain and then respond to it on the CA's web page.

Could the administrator benefit by receiving an encrypted email from the CA that can only be decrypted using the PIV credential? It does add privacy, and authentication of individual identity, to the automated process for first time retrieval. Updates/Rekeys could then be fully automated with much less concern.

The 2.0 protection profile from NIAP for operating CA's is here:
https://www.niap-ccevs.org/Profile/Info.cfm?id=404

Shall we adopt some of the guidance? The Key Protection and Security Assurance requirements look particularly useful.

Section 1.2

The following Certificate Policy identifiers are reserved for use by CAs as an optional means of asserting compliance with this CP (OID arc 2.23.140.1.2) as follows:

Pull request #10 comment / question on whether to assert a policy mapping / federal OIDs

Nothing super substantive to discuss here.

From @techliaison and Section 2 comments:

• Do we want to mandate checking CAA records and honoring them?
• Do we expect in the future that there would be CAA records for .gov and .mil limiting certificate issuance to this PKI?

Since the FPKI Device Root is the CA cited in this section, it must respond to this requirement not repeat it. Recommend using FPKI COMMON language (at a minimum):
"A request to revoke a certificate shall identify the certificate to be revoked, explain the reason for revocation, and allow the request to be authenticated (e.g., digitally or manually signed). The steps involved in the process of requesting a certification revocation are detailed in the CPS."

In general, the FPKI Device CP should not indicate No Stipulation for any requirement. Recommend a decision be made as to whether the FPKI requires the CA to notify the subscriber of certificate issuance. This should be either:
"The CA shall notify the Applicant Representative of certificate issuance."
or
"Notification of certificate issuance is at the discretion of the issuing CA."

Needs to be updated to align with NIST SP 800-131A and FIPS 186-4 AND possibly larger key size for the intermediates.

Currently in Section 6.1.5

(2) Subordinate CA Certificates

Currently, Section 6.1.5 for subscriber certificates states:

We must include Code Signing certificates, and because some vendors require Time Stamping for Code Signing this is also required as a core capability in this CP iteration. A clear path for broadly accepted USG issued Code Signing certificates is critical capability to include in the CP, otherwise as we have existing mobile code web services, we are right back where we are with Device TLS certificates for Code Signing Certificates.

For better or worse, the US Forest Service has long used the fs.fed.us domain. We are actively (albeit slowly) moving the public facing web infrastructure to fs.usda.gov (forestservice.gov is not an option at this point) but we will likely have public web sites in the fs.fed.us domain for a while, and redirects from fs.fed.us to fs.usda.gov for substantially longer.

Could the fed.us domain be added to the *.mil and *.gov domains?

Brad

Again - recommend the FPKI decide whether it will publish certificates, under what circumstances it might not publish, etc. and make this statement here.

@techliaison @weirdscience @tkpk @konklone

without over-engineering, I wanted to start some additional pull requests which incorporate the basic additions that you had drafted. Includes:

• Section 1: Updating the Authority, who owns the doc, who owns the process, etc
• Section 2: Publication and Responsibility
• Section 3: Identity and Authentication

Rather than having a single PR with too many changes that apply to different sections - why not separate branches for each section (1, 2, 3) to start?

Not long term proposal! Just to jumpstart applying proposed updates to each section...

thoughts?

Recommend adding "“when the binding between the subject and the subject’s public key defined within a certificate is no longer considered valid (e.g. identifying information in the certificate is no longer valid)”
Item 13 - this is a non-sequitur. The CA cannot revoke a certificate issued by a subordinate CA. It can revoke the subordinate CA. Revocation of CA certificates is handled in Section 4.9.1.2.
If the intent is that revocation of a subordinate CA for the reason of compromise occurs in 24 hours, then rephrase item 13, or rename the section.

The current language in Section 4.1.1 does not really address the subject of who can submit a certificate application. It is more about who cannot. In addition to this language, recommend this section address who can submit a request. Since this CP is for the FPKI Device Root, will certificate issuance be limited to Federal agencies? Authorized representatives of Federal agencies? Web Server Owners? Anyone authoritative for a .gov or .mil web resource?

Is the Device Root going to employ certificate renewal, rekey or modification for the certificates it issues? If so, these sections need to say so and the associated subsections need to be specified (by whom, under what circumstances, etc). If not, make that statement and the associated subsections become N/A.
If the Device Root does not intend to renew, rekey or modify, but will allow subordinate CAs to do so, then this needs to be explicit.

See PR #14

Included:

• Section 2 (top)
• Section 2.2 - did not specify "where" the CP would be posted yet
• Section 2.3 - partial

Did not include Section 2.4 Access Controls on Repositories edits. <-- worthy of discussion!

BRD:

• https://github.com/uspki/policies/blob/master/certificate-policy.md#632-certificate-operational-periods-and-key-pair-usage-periods
• Only specifies Subscriber and "no greater than 39 months"

Common:

• Specific to subscriber
• For OCSP responders operating under this policy and all other subscriber public keys, the
  maximum usage period is three years. Subscriber signature private keys have the same usage
  period as their corresponding public key

NIST 800-57:

• http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57Pt3r1.pdf
• No specification found

It seems we have "39" versus "36" for subscriber keys; in this scenario, since enterprise device certificates may be issued under Common (non-Public Trust) and have a maximum of 36 months:

• Suggest using the minimum of the two (36) as the maximum in the CP
• Promotes both alignment and ease for engineers trying to rectify the two (public trust versus enterprise)

Discuss CPS Approval Procedures

@LarryFrank

having the compliance auditor do compliance analysis is too late. Need an approved CPS to stand up operation - audit happens (at best) just prior to commencing operation - at which time, it may be very expensive to fix thing. DoD has someone actually do a compliance analysis before the PMA approves the CPS - then the auditor checks against that.

Per @LarryFrank - Issue opened to discuss inclusion of EV
#9

• EV included (explicitly)?
• EV as required?
• EV as optional?

12 month validity period for a Root CA that issues certificates to subordinate CAs seems excessive. Is this the industry standard for device roots?
Recommend FPKI Device Root follow the same CRL issuance as the other FPKI CPS (30 days).

While it is generally true that we can't control the actions of the relying parties, we should at least set expectations. Recommend a statement be included here that sets expectations: e.g. not trusting certificates when used in situations for which they were not intended (violate basic constraints on key usage/extended key usage); verifying validity prior to trusting certificates; etc.

If we want SCT obtainment and embedding in certificates to be required for all issuing CAs, where is the appropriate place to include this process in the CP or CPS?

Section 6.1.6 specifies references to NIST standards under crypto. This seems a bit out of date - and for government public trust PKI and a policy, we can be more prescriptive within the SHOULD and MAY boundaries.

Currently Section 6.1.6 states:

6.1.6 Public key parameters generation and quality checking

RSA: The CA SHALL confirm that the value of the public exponent is an odd number equal to 3 or more. Additionally, the public exponent SHOULD be in the range between 2¹⁶+1 and 2²⁵⁶-1. The modulus SHOULD also have the following characteristics: an odd number, not the power of a prime, and have no factors smaller than 752. [Source: Section 5.3.3, NIST SP 800-89]

DSA: Although FIPS 800-57 says that domain parameters may be made available at some accessible site, compliant DSA certificates MUST include all domain parameters. This is to insure maximum interoperability among relying party software. The CA MUST confirm that the value of the public key has the unique correct representation and range in the field, and that the key has the correct order in the subgroup. [Source: Section 5.3.1, NIST SP 800-89]

ECC: The CA SHOULD confirm the validity of all keys using either the ECC Full Public Key Validation Routine or the ECC Partial Public Key Validation Routine. [Source: Sections 5.6.2.3.2 and 5.6.2.3.3, respectively, of NIST SP 800-56A: Revision 2]

A certificate problem report is defined as "Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates."
It does not appear that a Certificate Problem Report is the same thing as a revocation request? Is it authoritative? Or does it lead to a revocation request? The existing statement describes processing a certificate problem report, but doesn't address the timing for revocation. FPKI should set a time-certain for the revocation of a certificate once a revocation request has been received. The CP already requires 24 hours and 7 days in Section 4.9.1. For this section, I recommend the statement is made that revocation requests should be processed before next CRL is issued (exception for situations where CRL issuance is imminent, e.g. within 2 hours).

Name Constraints

• Issuing certificates for US government properties
• Name constraints will include .gov and .mil
• any others?

Per comments in #43 - all CAs shall be required to generate their own keys. how should Section 6.2.6 be rewritten?

BRD:

If the Issuing CA generated the Private Key on behalf of the Subordinate CA, then the Issuing CA SHALL encrypt the Private Key for transport to the Subordinate CA. If the Issuing CA becomes aware that a Subordinate CA's Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subordinate CA, then the Issuing CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key.

Common:

CA private keys may be exported from the cryptographic module only to perform CA key
backup procedures as described in section 6.2.4.1. At no time shall the CA private key exist in
plaintext outside the cryptographic module.
All other keys shall be generated by and in a cryptographic module. In the event that a private
key is to be transported from one cryptographic module to another, the private key must be
encrypted during transport; private keys must never exist in plaintext form outside the
cryptographic module boundary.
Private or symmetric keys used to encrypt other private keys for transport must be protected
from disclosure

#1.5 and #1.5.1 appear contradictory to me.
Although I agree CABForum created the BRs and can modify them following their procedures the term "This certificate policy" should be referring to the CP being written and not the BRs - maybe modify 1.5 as follows:
This Certificate Policy is based on the Baseline Requirements (BR) for the Issuance and Management of Publicly-Trusted Certificates present criteria established by the CA/Browser Forum for use by Certification Authorities when issuing, maintaining, and revoking publicly-trusted Certificates. The BR may be revised from time to time, as appropriate, in accordance with procedures adopted by the CA/Browser Forum.

Discuss debian weak key checks

6.1.1.3 Subscriber Key Pair Generation

The CA SHALL reject a certificate request if the requested Public Key does not meet the requirements set forth in Sections 6.1.5 and 6.1.6 or if it has a known weak Private Key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys).

For the FPKI Device Root, should the FPKIPA or other governing body be identified as authorized to request revocation?

We have different edits (from docs!) for the Subject Distinguished Name Fields:

• https://github.com/uspki/policies/blob/master/certificate-policy.md#71422-subject-distinguished-name-fields

Opening issue to collect and discuss the various edits.

Comparing the Federal Common Policy Framework, Section 6.1.1.1 to the BRD Section 6.1.1.1

BRD:

6.1.1.1 CA Key Pair Generation

For Root CA Key Pairs created after the Effective Date that are either (i) used as Root CA Key Pairs or (ii) Key Pairs generated for a subordinate CA that is not the operator of the Root CA or an Affiliate of the Root CA, the CA SHALL:

1. prepare and follow a Key Generation Script,
2. have a Qualified Auditor witness the Root CA Key Pair generation process or record a video of the entire Root CA Key Pair generation process, and
3. have a Qualified Auditor issue a report opining that the CA followed its key ceremony during its Key and Certificate generation process and the controls used to ensure the integrity and confidentiality of the Key Pair.

For other CA Key Pairs created after the Effective Date that are for the operator of the Root CA or an Affiliate of the Root CA, the CA SHOULD:

1. prepare and follow a Key Generation Script and
2. have a Qualified Auditor witness the Root CA Key Pair generation process or record a video of the entire Root CA Key Pair generation process.

In all cases, the CA SHALL:

1. generate the keys in a physically secured environment as described in the CA's Certification Practice Statement;
2. generate the CA keys using personnel in Trusted Roles under the principles of multiple person control and split knowledge;
3. generate the CA keys within cryptographic modules meeting the applicable technical and business requirements as disclosed in the CA's Certificate Policy and/or Certification Practice Statement;
4. log its CA key generation activities; and
5. maintain effective controls to provide reasonable assurance that the Private Key was generated and protected in conformance with the procedures described in its Certificate Policy and/or Certification Practice Statement and (if applicable) its Key Generation Script.

referencing #6 and comments; moving here:

• Staring in Section 1.1 - remove text starting at "Notice to Readers" to the end of the paragraph - this is boiler plate from the CA/B Forum and not applicable for an operational CP.
• Remove Section 1.2.1 - which is the CA/B forum Revision history.
• Remove Section 1.2.2 Relevant dates - also only applicable to CA/B forum version. CP should state the requirements.
• Consider pulling the appropriate sections for the Fed Bridge CP (or Common) to replace all of Section 1.3., 1.4 and 1.5.

@LarryFrank

Name Redaction

• Scope: Name Redaction for publishing to CT Logs
• Allowing for name redaction is not expected to be included

Please add references to open discussions, browser policies, and technical constraints here.

#1.4.1 - primary goal for appropriate certificate use seems a bit too generic
“efficient and secure electronic communication” includes email, user authentication, digital signature, and various other uses of person certificates – we should narrow this down to appropriate uses for TLS certificates (and code signing, timestamp when they are added)

#1.4.2 - we should somehow specify what is out of scope - for example all "person certificate uses" like digitally signing documents, protection of email, person authentication, etc.

The term "certificate request" is not defined in Section 1.6. Is this the pkcs#10 request? If so, it will be signed by the device (web server) that is the subject of the certificate request, not by the "appropriate Applicant Representative on behalf of the Applicant".
Is the paragraph that starts: "One certificate request MAY suffice. . ." correct? or should it say ". . .provided that each Certificate is supported by a valid, current subscriber agreement. . ."

Recommend this is N/A, unless FPKI Device Root is required to notify any third party when a certificate is issued, in which case describe that here.

See #34

BRD:

• https://github.com/uspki/policies/blob/master/certificate-policy.md#621-cryptographic-module-standards-and-controls
• No specification explicitly in this section;
• inferred in 6.2.7 which specifies FIPS 140-2 Level 3 for CAs: https://github.com/uspki/policies/blob/master/certificate-policy.md#627-private-key-storage-on-cryptographic-module

Common:

• Allows both FIPS 140-2 Level 2 and Level 3 for the CAs and OCSP
• Subscribers "lowest" allowed is FIPS 140-2 Level 1
  • Inference is FIPS 140-2 is required at a minimum for any participant

NIST:

• http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57Pt3r1.pdf
• Section 2.2.3
• Ensure that Cryptographic modules for CAs, Key Recovery Servers, and OCSP
  responders are hardware modules validated as meeting FIPS 140-2 Level 3 or higher

BRD leaves open the Computer, Network, Lifecycle and Time-stamping security controls:

• https://github.com/uspki/policies/blob/section6/certificate-policy.md#65-computer-security-controls

Suggest first edits / drafts be taken directly from Common for these sections:

• https://www.idmanagement.gov/IDM/servlet/fileField?entityId=ka0t0000000TN9iAAG&field=File__Body__s

Any thoughts? @weirdscience @tkpk @LarryFrank @techliaison @twbaldridge @konklone @TLSrUS