[cabfpub] Ballot 188 - Clarify use of term "CA" in Baseline Requirements
Doug Beattie
doug.beattie at globalsign.com
Tue Feb 28 21:37:35 UTC 2017
GlobalSIgn votes Yes.
> -----Original Message-----
> From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Ben
> Wilson via Public
> Sent: Thursday, February 16, 2017 2:09 PM
> To: CABFPub <public at cabforum.org>
> Cc: Ben Wilson <ben.wilson at digicert.com>
> Subject: [cabfpub] Ballot 188 - Clarify use of term "CA" in Baseline
> Requirements
>
> 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 also
> 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-nocheck, as defined by RFC6960.
>
>
> In Section 4.9.10 (On-line revocation checking requirements)
>
>
> * Replace the first sentence 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:
>
> 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.
>
>
> 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.
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
More information about the Public
mailing list