I see no problem with this amendment. Dimitris.
On 23/2/2017 7:46 μμ, Ben Wilson wrote: > Voting starts at 2200 UTC today. One of the changes proposed by Ballot 188 > is to replace all instances of “Root Certificate” with “Root CA Certificate”, > but I just noticed that there are nine (9) places where “Root Certificate” > still appears, so I am proposing that Ballot 188 be deemed amended to > include those instances as well: > > > > Four (4) instances in Section 1.1, Overview; > > Three (3) in section 1.6.1 Definitions – in the definitions of “Application > Software Supplier,” “Publicly-Trusted Certificate,” and “Test Certificate”; > > One (1) in section 2.2; and > > One (1) in section 9.9.1. > > > > I believe Dimitris and Tim are OK with this amendment. > > > > Ben > > > > From: Public [mailto:[email protected]] On Behalf Of Ben Wilson via > Public > Sent: Tuesday, February 21, 2017 11:21 AM > To: [email protected] > Cc: Ben Wilson <[email protected]> > Subject: Re: [cabfpub] Ballot 188 - Clarify use of term "CA" in Baseline > Requirements > > > > This is a reminder that discussion is currently open on Ballot 188. > > The discussion period closes and voting begins at 2200 UTC on Thursday. > > Please take time to review the proposed changes before then. > > > > From: Public [mailto:[email protected]] On Behalf Of Dimitris > Zacharopoulos via Public > Sent: Thursday, February 16, 2017 1:40 PM > To: [email protected]<mailto:[email protected]> > Cc: Dimitris Zacharopoulos <[email protected]<mailto:[email protected]>> > Subject: [cabfpub] Ballot 188 - Clarify use of term "CA" in Baseline > Requirements > > > > 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-nocheck, 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: > > 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 [email protected] https://cabforum.org/mailman/listinfo/public
