19 votes total, with no abstentions:
- 19 Issuers voting YES: TrustCor, Disig, Entrust, JPRS, Kamu SM, SECOM, Chunghwa Telecom, Fastly, SecureTrust, GDCA, HARICA, Let’s Encrypt, Sectigo, SSL.com, eMudhra, Certinomis, Izenpe, Digicert, OISTE
- 0 Issuers voting NO
- 0 Issuers ABSTAIN
3 votes total, with no abstentions:
- 3 Consumers voting YES: Apple, Google, Mozilla
- 0 Consumers voting NO
- 0 Consumers ABSTAIN
- Bylaw 2.3(f) requires:
- A “yes” vote by two-thirds of Certificate Issuer votes and by 50%-plus-one of Certificate Consumer votes. Votes to abstain are not counted for this purpose. This requirement was MET for Certificate Issuers and MET for Certificate Consumers.
- At least one Certificate Issuer and one Certificate Consumer Member must vote in favor of a ballot for the ballot to be adopted. This requirement was MET.
- Bylaw 2.3(g) requires that a ballot result only be considered valid when “more than half of the number of currently active Members has participated”. Votes to abstain are counted in determining quorum. Half of the currently active members at the start of voting was 14, so the quorum was 15 for this ballot. This requirement was MET.
Recently, several conversations around the necessity of the distributionPoint field (and its containing Issuing Distribution Point extension) in sharded CRLs have come to the conclusion that, although the distributionPoint field serves an important purpose in defending against substitution attacks, RFC 5280’s language does not actually require its presence.
This ballot augments the Baseline Requirements’ CRL Profile to ensure that all sharded CRLs contain the distributionPoint field.
The following motion has been proposed by Aaron Gable of ISRG / Let’s Encrypt, and endorsed by Clint Wilson of Apple, Corey Bonnell of DigiCert, and Dmitris Zacharopoulos of HARICA.
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” (“Baseline Requirements”), based on Version 1.8.4.
MODIFY the Baseline Requirements as specified in the following Redline:
This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:
Discussion (7+ days)
Start time: 2022-10-22 00:00:00 UTC
End time: Not before 2022-10-29 00:00:00 UTC
Vote for approval (7 days)
Start time: 2022-10-31 16:00:00 UTC
End time: 2022-11-07 16:00:00 UTC
This ballot now enters the IP Rights Review Period to permit members to review the ballot for relevant IP rights issues.