[cabfpub] Policy Review Working Group's Pre-Ballot to Clarify Use of "CA"

Ben Wilson ben.wilson at digicert.com
Thu Jan 19 09:44:46 MST 2017


All,

 

The Policy Review Working Group has completed its review of the Baseline Requirements for purposes of clarifying use of the term "CA" and related terminology.  Please review and comment on the following pre-ballot.  A redlined version of the Baseline Requirements is attached to facilitate your review and comment.  

 

I did want to highlight one of the proposed changes that is not related to "CA" terminology.   That proposed change is in Section 4.9.10.  The current language is ambiguous, and it doesn't say what was originally intended when it was adopted.  The current language says, "Effective 1 August 2013, OCSP responders for CAs which are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "good" status for such certificates."  

 

The proposed change would rephrase this sentence to say what was originally intended.  It would say, "OCSP responders for Subordinate CA Certificates that are Technically Constrained in accordance with Section 7.1.5 are exempt from this prohibition on responding with a "good" to OCSP requests for the status for such certificates."

 

I don't know if anyone is relying on this provision, but its original intent was to address concerns by users of legacy CA software / OCSP responder software who complained that they could not meet this requirement because their OCSP responders were built to rely only on CRLs.

 

If this proposed change presents a problem for anybody, it will be removed from this ballot and put into its own separate ballot.

 

Thanks,

 

Ben

 

---- DRAFT MOTION BEGINS ---

Delete the last sentence of section 1.1, which reads, "These Requirements are applicable to all Certification Authorities within a chain of trust. They are to be flowed down from the Root Certification Authority through successive Subordinate Certification Authorities."

Insert as the last sentence of section 1.1 the following:  "These requirements are applicable to all CAs that can issue a Certificate that appears in a particular certificate chain from a Root Certificate that is publicly trusted.  They are to be flowed down from a Root Certificate through successive Subordinate CA Certificates."

In Section 1.6.1 (Definitions):

               Insert a new definition for "CA Certificate" as: "A Certificate in which the basicConstraints field has the cA attribute set to TRUE."

Replace the definition of "Certificate Revocation List" with: "A regularly updated time-stamped list of revoked Certificates that is created and digitally signed by the Private Key associated with the Root CA Certificate or Subordinate CA Certificate that issued the revoked Certificates." 

Replace the definition of "Certification Authority" with: "An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to Root CA Operators and Subordinate CAs."

Replace the definition of "Cross Certificate" with: "A CA Certificate that is used to establish a trust relationship between two Root CA Certificates."

Insert a new definition for "Externally Operated Subordinate CA" as: "A third party Subordinate CA, not the Root CA Operator or its Affiliate, that is in possession or control of the Private Key associated with the Subordinate CA Certificate."

Insert a new definition for "Internally Operated Subordinate CA" as: "A Subordinate CA operated by a Root CA Operator or its Affiliate, that is in possession or control of the Private Key associated with the Subordinate CA Certificate."

Replace the definition of "Issuing CA" with: "The Root CA or the Subordinate CA that is in possession or control of the Private Key of the "Issuer" named in a particular Certificate."

Replace the definition of "Key Generation Script" with:  "A documented plan of procedures for the generation of the Key Pair to be associated with a CA Certificate."

Replace the definition of "OCSP Responder" with:  "A system that provides Online Certificate Status Protocol responses."

Replace the definition of "Root CA" with a new definition for "Root CA Operator" as:  "The top-level Certification Authority (i.e. an organization) whose CA Certificate (or associated Public Key) is distributed by Application Software Suppliers as a trust anchor."

Replace the defined term "Root Certificate" with "Root CA Certificate" and replace the definition with:  "A CA Certificate in which the Public Key has been digitally signed by its corresponding Private Key." 

Insert a new definition for "Subordinate CA" as "A Certification Authority in possession or control of the Private Key associated with a Subordinate CA Certificate. A Subordinate CA is either an Externally Operated Subordinate CA or an Internally Operated Subordinate CA."

Replace the definition for "Subordinate CA" with "Subordinate CA Certificate" as: "A CA Certificate that has been signed by the Private Key associated with a Root CA Certificate or a different Subordinate CA Certificate."

-----

Replace subsection 13 in Section 4.9.1.1 (Reasons for Revoking a Subscriber Certificate) with:  "The CA is made aware of a possible compromise of the Private Key that signed the Certificate."

Replace Section 4.9.1.2 (Reasons for Revoking a Subordinate CA Certificate) with:  

The Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7) days if one or more of the following occurs:

1.            The Externally Operated Subordinate CA requests revocation in writing;

2.            The Externally Operated Subordinate CA notifies the Issuing CA that the original certificate request was not authorized and does not retroactively grant authorization;

3.            The Issuing CA obtains evidence that the Private Key corresponding to the Public Key in the Subordinate CA Certificate suffered a Key Compromise or no longer complies with the requirements of Sections 6.1.5 and 6.1.6;

4.            The Issuing CA obtains evidence that the Private Key corresponding to the Public Key in the Subordinate CA Certificate was misused;

5.            The Issuing CA is made aware that the Subordinate CA Certificate was not issued in accordance with, or that the Externally Operated Subordinate CA has not complied with, these Requirements  or the applicable Certificate Policy or Certification Practice Statement;

6.            The Issuing CA determines that any of the information appearing in the Subordinate CA Certificate is inaccurate or misleading;

7.            The Issuing CA or the Subordinate CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the Subordinate CA Certificate;

8.            The Issuing CA's or Externally Operated Subordinate CA's right to issue Certificates under these Requirements expires or is revoked or terminated, unless the Issuing CA has made arrangements to continue maintaining the CRL/OCSP Repository;

9.            Revocation is required by the Issuing CA's Certificate Policy and/or Certification Practice Statement; or

10.         The technical content or format of the Subordinate CA Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Subordinate CA Certificates should be revoked and replaced by CAs within a given period of time).

Replace Section 4.9.9 (On-line revocation/status checking availability) with:

OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST either:

1.            Be signed by the Private Key associated with the Root CA Certificate or the Subordinate CA  Certificate that issued the Certificates whose revocation status is being checked, or

2.            Be signed by an OCSP Responder whose Certificate is issued by the Root CA Certificate or Subordinate CA Certificate that issued the Certificate whose revocation status is being checked.

In the latter case, the OCSP signing Certificate MUST contain an extension of type id-pkix-ocsp-nocheck, as defined by RFC6960.

Replace the last sentence in Section 4.9.10 (On-line revocation checking requirements), which currently reads: "Effective 1 August 2013, OCSP responders for CAs which are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a 'good' status for such certificates."  with:  "OCSP Responders for Subordinate CA Certificates that are Technically Constrained in accordance with Section 7.1.5 are exempt from this prohibition on responding "good" to OCSP requests for the status on Certificates that have not been issued."

Replace Section 5.2.2 (Number of Individuals Required per Task) with: "The Private Key associated with a Root CA Certificate or Subordinate CA Certificate SHALL be backed up, stored, and recovered only by personnel in trusted roles using, at least, dual control in a physically secured environment."

Replace subsections 1 and 2 in the second paragraph of Section 5.4.1 (Types of events recorded) so that they read:

The CA SHALL record at least the following events:

1.	CA Private Key lifecycle management events for the Root CA Certificate or Subordinate CA Certificate, including:

a.	Key generation, backup, storage, recovery, archival, and destruction; and
b.	Cryptographic device lifecycle management events.

 

2.	Certificate lifecycle management events for the Root CA Certificate, Subordinate CA Certificate, and Subscriber Certificates, including:

a.   Certificate requests, renewal, and re-key requests, and revocation;

b.   All verification activities stipulated in these Requirements and the CA's Certification Practice Statement;

c.   Date, time, phone number used, persons spoken to, and end results of verification telephone calls;

d.   Acceptance and rejection of certificate requests; Frequency of Processing Log

e.   Issuance of Certificates; and

f.    Generation of Certificate Revocation Lists and OCSP entries.

 

Delete the word "organizations" in the first sentence of section 5.7.1 (Incident and compromise handling procedures) so that it reads, "CAs shall have an Incident Response Plan and a Disaster Recovery Plan."

 

Replace the first two paragraphs of Section 6.1.1.1 (CA Key Pair Generation) with the following:

 

For a Key Pair generated to be associated with either (i) a Root CA Certificate or (ii) a Subordinate CA Certificate to be operated by an Externally Operated Subordinate CA, the CA SHALL:

1.           prepare and follow a Key Generation Script,

2.           have a Qualified Auditor witness the Key Pair generation process or record a video of the entire 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 a Key Pair to be associated with a Subordinate CA Certificate to be operated by the Root CA Operator or its Affiliates, the CA SHOULD:

 

1.            prepare and follow a Key Generation Script and

2.            have a Qualified Auditor witness the Key Pair generation process or record a video of the entire 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 Certificate Policy and/or Certification Practice Statement;

2. generate the keys using personnel in trusted roles under the principles of multiple person control and split knowledge;

3. generate the 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 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.

 

Replace Section 6.1.7 (Key usage purposes (as per X.509 v3 key usage field)) with:

 

Private Keys associated with Root CA Certificates MUST NOT be used to sign Certificates except in the following cases:

 

1.            Self-signed Root CA Certificates themselves;

2.            Subordinate CA Certificates and Cross Certificates;

3.            Certificates for infrastructure purposes (e.g. administrative role certificates, internal CA operational device certificates, and OCSP Response verification Certificates); and

4.            Certificates issued solely for the purpose of testing products with Certificates issued by a Root CA Certificate.

 

Replace Section 6.2.5 (Private key archival) with:  

Parties other than the Subordinate CA SHALL NOT archive the Private Keys associated with the Subordinate CA Certificate without authorization by the Subordinate CA.

Replace Section 6.2.6 (Private key transfer into or from a cryptographic module) with:

If the CA generated the Private Key on behalf of an Externally Operated Subordinate CA, then the CA SHALL encrypt the Private Key for transport to the Externally Operated Subordinate CA. 

If a  CA becomes aware that an Externally Operated Subordinate CA's Private Key has been communicated to an unauthorized person or an organization not affiliated with the Externally Operated Subordinate CA, then the CA SHALL revoke all Subordinate CA Certificates that include the Public Key corresponding to the communicated Private Key.

Replace subsection b. (keyUsage) in Section 7.1.2.1 (Root CA Certificate), with: 

 

This extension MUST be present and MUST be marked critical. Bit positions for keyCertSign and cRLSign MUST be set. If the Private Key associated with the Root CA Certificate is to be used for signing OCSP responses, then the digitalSignature bit MUST be set.

Replace subsection a. through c. of Section 7.1.2.2 (Subordinate CA Certificate) with the following:

 

a.	certificatePolicies

        This extension MUST be present and SHOULD NOT be marked critical.

       certificatePolicies:policyIdentifier (Required)

The following fields MAY be present:

certificatePolicies:policyQualifiers:policyQualifierId (Optional)

                      *   id-qt 1 [RFC 5280].

                       *   certificatePolicies:policyQualifiers:qualifier:cPSuri (Optional)

                       *   HTTP URL for the CA's Certificate Policy, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the CA.

b.    cRLDistributionPoints

       This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the Issuing CA's CRL service where revocation of the Subordinate CA Certificate will be published.

c.    authorityInformationAccess

       With the exception of stapling, which is noted below, this extension MUST be present. It MUST NOT be marked critical, and it MUST contain the HTTP URL of the Issuing CA's OCSP responder that provides the status of the Subordinate CA Certificate (accessMethod = 1.3.6.1.5.5.7.48.1). It SHOULD also contain the HTTP URL of the Issuing CA's CA Certificate (accessMethod = 1.3.6.1.5.5.7.48.2).

       The HTTP URL of the Issuing CA's OCSP responder MAY be omitted, provided that the Subscriber "staples" the OCSP response for the Certificate in its TLS handshakes [RFC4366].

 

Replace subsection c. of Section 7.1.2.3 (Subordinate CA Certificate) with the following:

c.    authorityInformationAccess

With the exception of stapling, which is noted below, this extension MUST be present.  It MUST NOT be marked critical, and it MUST contain the HTTP URL of the Issuing CA's OCSP responder that provides the status of the Certificate (accessMethod = 1.3.6.1.5.5.7.48.1).  It SHOULD also contain the HTTP URL of the Issuing CA's CA Certificate (accessMethod = 1.3.6.1.5.5.7.48.2).

 

The HTTP URL of the Issuing CA's OCSP responder MAY be omitted provided that the Subscriber "staples" OCSP responses for the Certificate in its TLS handshakes [RFC4366].

 

Replace Section 7.1.3 (Algorithm object identifiers) with:

CAs MUST NOT sign Certificates using the SHA-1 hash algorithm. This Section 7.1.3 does not apply to existing Root CA Certificates or Cross Certificates. CAs MAY continue to use their existing SHA-1 Root CA Certificates. SHA-2 Subscriber Certificates SHOULD NOT chain up to a SHA-1 Subordinate CA Certificate.

 

Replace Section 7.1.4.1 (Issuing CA Certificate Subject) with:

The content of the Certificate Issuer Distinguished Name field MUST match the Subject DN of the Issuing CA's CA Certificate to support name chaining as specified in RFC 5280, section 4.1.2.4.

 

Replace the first sentence of Section 7.1.6.1 (Reserved Certificate Policy Identifiers) with:

This section describes the content requirements for the Root CA Certificates, Subordinate CA Certificates, and Subscriber Certificates, as they relate to the identification of Certificate Policy.

 

Replace Section 7.1.6.3 (Subordinate CA Certificates) with:

A Subordinate CA Certificate issued after the Effective Date to an Externally Operated Subordinate CA:

1.           MUST include one or more explicit policy identifiers that indicates the Externally Operated Subordinate CA's adherence to and compliance with these Requirements (i.e. either the CA/Browser Forum reserved identifiers or identifiers defined by the CA in its Certificate Policy and/or Certification Practice Statement) and

2.           MUST NOT contain the "anyPolicy" identifier (2.5.29.32.0).

A Subordinate CA Certificate issued after the Effective Date to an Internally Operated Subordinate CA:

1.  MAY include the CA/Browser Forum reserved identifiers or an identifier defined by the CA in its Certificate Policy and/or Certification Practice Statement to indicate the Internally Operated CA's compliance with these Requirements and

2.  MAY contain the "anyPolicy" identifier (2.5.29.32.0) in place of an explicit policy identifier.

All CAs SHALL represent, in their Certificate Policy and/or Certification Practice Statement, that all Certificates containing a policy identifier indicating compliance with these Requirements are issued and managed in accordance with these Requirements.

Replace the first paragraph of Section 8.1 (Frequency or circumstances of assessment) with:

CA Certificates MUST either be (a) Technically Constrained in line with section 7.1.5 and be audited in line with section 8.7 only, or (b) fully audited in line with all requirements of this section 8.  A Certificate is deemed capable of being used to issue certificates for server authentication if it contains an X.509v3 basicConstraints extension with the CA boolean set to true and has no EKU, the "anyEKU" EKU, or the serverAuth EKU.

 

Replace the third paragraph of Section 8.7 (Self-Audits) with:

During the period in which a Technically Constrained Externally Operated Subordinate CA issues Certificates, the CA which issued the Externally Operated Subordinate CA's CA Certificate SHALL monitor adherence to the CA's Certificate Policy and/or Certification Practice Statement and the Externally Operated Subordinate CA's Certificate Policy and/or Certification Practice Statement. On at least a quarterly basis, against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by the Externally Operated Subordinate CA, during the period commencing immediately after the previous audit sample was taken, the CA SHALL ensure adherence to all applicable Certificate Policies and/or Certification Practice Statements.

 

Replace subsection 2 of Section 9.6.1 (CA representations and warranties) with:

2.            All Application Software Suppliers with whom the Root CA Operator has entered into a contract for inclusion of its Root CA Certificate in software distributed by such Application Software Supplier; and

 

Replace the last paragraph of Section 9.6.1 (CA representations and warranties) with:

The Root CA Operator SHALL be responsible for the performance and warranties of its Externally Operated Subordinate CAs, for the Externally Operated Subordinate CAs' compliance with these Requirements, and for all liabilities and indemnification obligations of the Externally Operated Subordinate CAs under these Requirements, as if the Root CA Operator were the Externally Operated Subordinate CA issuing the Certificates.

---- DRAFT MOTION ENDS ---

 

 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Baseline Requirements - Policy Review WG .doc
Type: image/jpeg
Size: 616448 bytes
Desc: Baseline Requirements - Policy Review WG .doc
URL: <http://cabforum.org/pipermail/public/attachments/20170119/9e6abb00/attachment-0001.jpe>


More information about the Public mailing list