[cabfpub] Ballot 188 - Clarify use of term "CA" in Baseline Requirements
Dimitris Zacharopoulos
jimmy at it.auth.gr
Thu Feb 16 20:39:52 UTC 2017
Trying to fix formatting issues. Let's hope this goes through correctly.
Dimitris.
**
*Ballot 188 - Clarify use of term "CA" in Baseline Requirements*
The following motion has been proposed by Dimitris Zacharopoulos of
HARICA and endorsed by Ben Wilson of Digicert and Tim Hollebeek of
Trustwave.
*Background*:
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. The term "CA" is used in the Baseline Requirements and
other documents to refer to "CA" as an organization or "CA" as a CA
Certificate. The Policy Review WG decided to update the Baseline
Requirements first, and then update the EV Guidelines and other
documents so that the updated terms are used consistently in all CA/B
Forum documents.
One of the proposed changes is not related to "CA" terminology. That
proposed change is in Section 4.9.10. Also, in section 6.1.7, some
legacy language related to 1024-bit RSA usage from Root CA, was removed.
Some incorrect references (pointing to Section 3.3.1 instead of 4.2.1)
are corrected in Sections 3.2.2.4 and 4.1.2
In accordance with the Bylaws, a PDF with redlines to the Baseline
Requirements as they currently exist is attached to assist your review.
*-- MOTION BEGINS --*
In Section 1.1 (Overview)
* 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 CA Operators."
* 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 Operator, 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 Operator, 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 Operator
or the Subordinate CA Operator 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. See also,
Online Certificate Status Protocol."
* 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 Operator" as "A
Certification Authority in possession or control of the Private Key
associated with a Subordinate CA Certificate. A Subordinate CA
Operator 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 the definition of "Technically Constrained Subordinate CA
Certificate" with: "A Subordinate CA Certificate which uses a
combination of Extended Key Usage settings and Name Constraint
settings to limit the scope within which the Subordinate CA
Certificate may issue Subscriber or additional Subordinate CA
Certificates."
In Section 1.6.2 (Acronyms)
*
Insert a new acronym EKU --> "Extended Key Usage"
In Section 3.2.2.4 (Validation of Domain Authorization or Control)
* In the third paragraph, replace "Section 3.3.1" with "Section 4.2.1".
In Section 3.2.2.4.6 (Agreed-Upon Change to Website)
* In the 2nd paragraph, replace "Section 3.3.1 of these Guidelines"
with "Section 4.2.1 of this document".
In Section 4.1.2 (Enrollment Process and Responsibilities)
* In the 3rd paragraph, replace "Section 3.3.1" with "Section 4.2.1".
In Section 4.9.1.1 (Reasons for Revoking a Subscriber Certificate)
* Replace subsection 13 with: "The CA is made aware of a possible
compromise of the Private Key that signed the Certificate".
In Section 4.9.1.2 (Reasons for Revoking a Subordinate CA Certificate)
Replace 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).
In Section 4.9.9 (On-line revocation/status checking availability)
Replace 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-nochec/k, as defined by RFC6960.
In Section 4.9.10 (On-line revocation checking requirements)
* Replace the first sentense with "Each CA SHALL support an OCSP
capability using the GET method for Certificates issued in
accordance with these Requirements".
* Replace the last sentence, 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."
In Section 5.2.2 (Number of Individuals Required per Task)
* Replace 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."
In Section 5.4.1 (Types of events recorded)
Replace subsections 1 and 2 in the second paragraph of so that they read:
The CA SHALL record at least the following events:
1. Private Key lifecycle management events for the Root CA Certificate
or Subordinate CA Certificate, including:
2. Certificate lifecycle management events for the Root CA Certificate,
Subordinate CA Certificate, and Subscriber Certificates, including:
1. Certificate requests, renewal, and re-key requests, and revocation;
2. All verification activities stipulated in these Requirements and the
CA's Certification Practice Statement;
3. Date, time, phone number used, persons spoken to, and end results of
verification telephone calls;
4. Acceptance and rejection of certificate requests; Frequency of
Processing Log
5. Issuance of Certificates; and
6. Generation of Certificate Revocation Lists and OCSP entries.
In Section 5.7.1 (Incident and compromise handling procedures)
* Delete the word "organizations" in the first sentence of so that it
reads, "CAs shall have an Incident Response Plan and a Disaster Recovery
Plan."
In Section 6.1.1.1 (CA Key Pair Generation)
Replace the first two paragraphs 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 generated 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 Key in a physically secured environment as described in
the CA's Certificate Policy and/or Certification Practice Statement;
2. generate the Key using personnel in trusted roles under the
principles of multiple person control and split knowledge;
3. generate the Key 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.
Change the title of Section 6.1.7 as "Key usage purposes (as per
X.509 v3 key usage field)"
In Section 6.1.7 replace 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.
In Section 6.2.5 (Private key archival)
Replace with:
"Parties other than the Subordinate CA Operator SHALL NOT archive the
Private Keys associated with the Subordinate CA Certificate without
authorization by the Subordinate CA Operator."
In Section 6.2.6 (Private key transfer into or from a
cryptographic module)
Replace with:
If the Issuing CA generated the Private Key on behalf of an Externally
Operated Subordinate CA, then the Issuing CA SHALL encrypt the Private
Key for transport to the Externally Operated Subordinate CA.
If the Issuing 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 Issuing CA SHALL revoke all Subordinate CA Certificates that
include the Public Key corresponding to the communicated Private Key.
In Section 7.1.2.1 (Root CA Certificate)
Replace subsection b. (keyUsage), 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."
In Section 7.1.2.2 (Subordinate CA Certificate)
Replace subsection a. through c, subsections e. and g. 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].
e. keyUsage
*
This extension MUST be present and MUST be marked critical. Bit
positions for /keyCertSign /and /cRLSign /MUST be set. If the
Private Key that corresponds to the Subordinate CA Certificate is
used for signing OCSP responses, then the /digitalSignature /bit
MUST be set.
g. extkeyUsage (optional)
For Subordinate CA Certificates to be Technically constrained in line
with section 7.1.5, then either the value id-kp-serverAuth [RFC5280] or
id-kp-clientAuth [RFC5280] or both values MUST be present**.
Other values MAY be present.
If present, this extension SHOULD be marked non-critical.
** Generally Extended Key Usage will only appear within end entity
certificates (as highlighted in RFC 5280 (4.2.1.12)), however,
Subordinate CA Operators MAY include the extension to further protect
relying parties until the use of the extension is consistent between
Application Software Suppliers whose software is used by a substantial
portion of Relying Parties worldwide.
In Section 7.1.2.3 (Subscriber Certificate)
Replace subsection a. with the following:
a. certificatePolicies
This extension MUST be present and SHOULD NOT be marked critical.
* certificatePolicies:policyIdentifier (Required)
* A Policy Identifier, defined by the issuing CA, that indicates a
Certificate Policy asserting the issuing CA's adherence to and
compliance with these Requirements. The following extensions MAY be
present: certificatePolicies:policyQualifiers:policyQualifierId
(Recommended)
* id-qt 1 [RFC 5280].
certificatePolicies:policyQualifiers:qualifier:cPSuri (Optional)
* HTTP URL for the Subordinate CA Operator's Certification Practice
Statement, Relying Party Agreement or other pointer to online
information provided by the CA.
Replace subsection c. 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].
In Section 7.1.3 (Algorithm object identifiers)
Replace the first paragraph 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".
In Section 7.1.4.1 (Issuing CA Certificate Subject)
Replace 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."
In Section 7.1.5 (Name Constraints)
Replace the last paragraph with:
If the Subordinate CA Operator is not allowed to issue certificates with
dNSNames, then the Subordinate CA Certificate MUST include a zero-length
dNSName in excludedSubtrees. Otherwise, the Subordinate CA Certificate
MUST include at least one dNSName in permittedSubtrees.
In Section 7.1.6.1 (Reserved Certificate Policy Identifiers)
Replace the first sentence 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.
In Section 7.1.6.3 (Subordinate CA Certificates)
Replace 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
Subordinate 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.
In Section 8.1 (Frequency or circumstances of assessment)
Replace the first paragraph 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) be
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
/id-kp-anyExtendedKeyUsage/ [RFC5280] EKU, or the /id-kp-serverAuth/
[RFC5280] EKU.
In Section 8.7 (Self-Audits)
Replace the last paragraph with:
During the period in which a Technically Constrained Externally Operated
Subordinate CA issues Certificates, the Issuing CA SHALL monitor
adherence to the Issuing 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.
In Section 9.6.1 (CA representations and warranties)
Replace subsection 2 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 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.
*-- MOTION ENDS --*
The procedure for this ballot is as follows (exact start and end times
may be adjusted to comply with applicable Bylaws and IPR Agreement):
BALLOT 188 Status: Clarify use of term "CA" in Baseline Requirements
Start time (22:00 UTC)
End time (22:00 UTC)
Discussion (7 days)
16 Feb. 2017
23 Feb. 2017
Vote for approval (7 days)
23 Feb. 2017
2 Mar. 2017
If vote approves ballot: Review Period (Chair to send Review Notice) (30
calendar days). If Exclusion Notice(s) filed, ballot approval is
rescinded and PAG to be created. If no Exclusion Notices filed, ballot
becomes effective at end of Review Period.
Upon filing of Review Notice by Chair
30 days after filing of Review Notice by Chair
This is a Draft Guideline Ballot that proposes a Final Maintenance
Guideline. In accordance with Section 2.3 of the Bylaws this ballot
includes a full set of the Baseline Requirements with a redline or
comparison showing the set of changes from the Final Guideline
section(s) intended to become a Final Maintenance Guideline. Such
redline or comparison has been made against the Final Guideline
section(s) as they exist at the time that this ballot is proposed.
Votes must be cast by posting an on-list reply to this thread on the
Public Mail List.
A vote in favor of the ballot must indicate a clear 'yes' in the
response. A vote against must indicate a clear 'no' in the response. A
vote to abstain must indicate a clear 'abstain' in the response. Unclear
responses will not be counted. The latest vote received from any
representative of a voting Member before the close of the voting period
will be counted. Voting Members are listed here:
https://cabforum.org/members/
In order for the ballot to be adopted, two thirds or more of the votes
cast by Members in the CA category and greater than 50% of the votes
cast by members in the browser category must be in favor. Quorum is
currently ten (10) Members – at least ten Members must participate in
the ballot, either by voting in favor, voting against, or abstaining.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170216/a80f4790/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ballot 188 - Clarify the term CA in BR 1.4.2 red-lined-final draft.pdf
Type: application/pdf
Size: 607714 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170216/a80f4790/attachment-0003.pdf>
More information about the Public
mailing list