<div dir="ltr"><div>Here is version 3 of this ballot, incorporating changes to v2 suggested by Bruce and Ryan (thanks!).</div><div><br></div><div>I noticed that our current bylaws have reverted back to a fixed-length discussion period, so I have changed this version to comply.<br></div><br>==========================================<br><br><div>Ballot SC6 version 3: Revocation Timeline Extension</div><div><br></div>Purpose of Ballot:<br>Section
 4.9.1.1 of the Baseline Requirements currently requires CAs to revoke a
 Subscriber certificate within 24 hours of identifying any of 15 issues 
affecting the certificate. In cases where there is not an immediate 
threat of misuse of the certificate, this requirement can cause undue 
harm to a Subscriber that isn't capable of replacing the certificate 
prior to revocation. This ballot makes a number of improvements to the 
revocation rules imposed by the Baseline Requirements:<br>* Primarily, 
it creates a tiered timeline for revocations. The most critical 
"reasons" still require revocation within 24 hours, but for many others 
24 hours becomes a SHOULD and the CA has 5 days before they MUST revoke.<br>*
 A new "reason for revocation" was added to address the fact that there 
is currently no requirement for CAs to revoke a certificate when 
requested by the domain name registrant. After considering some more 
specific language that required CAs to follow 3.2.2.4 to validate domain
 control, I settled on the following more general "reason": "The CA 
obtains evidence that the validation of domain authorization or control 
for any Fully-Qualified Domain Name or IP address in the Certificate 
should not be relied upon."<br>* Reason #10 states "The CA determines 
that any of the information appearing in the Certificate is inaccurate 
or misleading;" This ballot removes "or misleading" because that is a 
subjective judgement that could effectively be used to justify 
censorship, as discussed at length in relation to the "Stripe, Inc of 
Kentucky" EV certificates.<br>* Current reasons #11 and #13 were removed
 from the section on subscriber certificates because they address cases 
where the intermediate and/or root must be revoked, so there isn't much 
sense (and some possible harm) in requiring revocation of all the leaf 
certs.<br>* It requires CAs to disclose their problem reporting mechanisms in a standard location: CPS section 1.5.2.<br>*
 Within 24 hours of receiving a problem report, the CA is now required 
to report back to both the entity reporting the problem and the 
Subscriber on the CA's findings, and to work with the reporter and 
Subscriber to establish a date by which the CA will revoke the 
certificate.<br><br>The following motion has been proposed by  Wayne 
Thayer of Mozilla and endorsed by Tim Hollebeek of DigiCert and Dimitris
 Zacharopoulos of Harica.<br>
<br><div>--- MOTION BEGINS ---

This 
ballot modifies the “Baseline Requirements for the Issuance and 
Management of Publicly-Trusted Certificates” as follows, based on 
Version 1.6.0:

</div><div><br></div><div>** Modify the definition of Key Compromise as follows: **</div>Key
 Compromise: A Private Key is said to be compromised if its value has 
been disclosed to an unauthorized person or an unauthorized person has 
had access to it.<br><div><br></div><div>** Modify Section 4.9.1 to read as follows: **

</div><div><br></div><div>4.9.1.1 Reasons for Revoking a Subscriber Certificate<br></div><div><br> </div><div>The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:<br></div>1. The Subscriber requests in writing that the CA revoke the Certificate;<br>2.
 The Subscriber notifies the CA that the original certificate request 
was not authorized and does not retroactively grant authorization;<br>3.
 The CA obtains evidence that the Subscriber's Private Key corresponding
 to the Public Key in the Certificate suffered a Key Compromise; or<br>4.
 The CA obtains evidence that the validation of domain authorization or 
control for any Fully-Qualified Domain Name or IP address in the 
Certificate should not be relied upon.<br><br>The CA SHOULD revoke a 
certificate within 24 hours and MUST revoke a Certificate within 5 days 
if one or more of the following occurs:<br>1. The Certificate no longer complies with the requirements of Sections 6.1.5 and 6.1.6;<br>2. The CA obtains evidence that the Certificate was misused;<br>3.
 The CA is made aware that a Subscriber has violated one or more of its 
material obligations under the Subscriber Agreement or Terms of Use;<br>4.
 The CA is made aware of any circumstance indicating that use of a 
Fully-Qualified Domain Name or IP address in the Certificate is no 
longer legally permitted (e.g. a court or arbitrator has revoked a 
Domain Name Registrant's right to use the Domain Name, a relevant 
licensing or services agreement between the Domain Name Registrant and 
the Applicant has terminated, or the Domain Name Registrant has failed 
to renew the Domain Name);<br>5. The CA is made aware that a Wildcard 
Certificate has been used to authenticate a fraudulently misleading 
subordinate Fully-Qualified Domain Name;<br>6. The CA is made aware of a material change in the information contained in the Certificate;<br>7.
 The CA is made aware that the Certificate was not issued in accordance 
with these Requirements or the CA's Certificate Policy or Certification 
Practice Statement;<br>8. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate;<br>9.
 The CA's right to issue Certificates under these Requirements expires 
or is revoked or terminated, unless the CA has made arrangements to 
continue maintaining the CRL/OCSP Repository;<br>10. Revocation is required by the CA's Certificate Policy and/or Certification Practice Statement; or<br>11.
 The CA is made aware of a demonstrated or proven method that exposes 
the Subscriber's Private Key to compromise, methods have been developed 
that can easily calculate it based on the Public Key (such as a Debian 
weak key, see <a href="http://wiki.debian.org/SSLkeys" target="_blank">http://wiki.debian.org/SSLkeys</a>), or if there is clear evidence that the specific method used to generate the Private Key was flawed.
<br><div><br></div><div>4.9.1.2 Reasons for Revoking a Subordinate CA Certificate</div><div><br></div><div>The Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7) days if one or more of the following occurs:</div>1. The Subordinate CA requests revocation in writing;<br>2.
 The Subordinate CA notifies the Issuing CA that the original 
certificate request was not authorized and does not retroactively grant 
authorization;<br>3. The Issuing CA obtains evidence that the 
Subordinate CA's Private Key corresponding to the Public Key in the 
Certificate suffered a Key Compromise or no longer complies with the 
requirements of Sections 6.1.5 and 6.1.6;<br>4. The Issuing CA obtains evidence that the Certificate was misused;<br>5.
 The Issuing CA is made aware that the Certificate was not issued in 
accordance with or that Subordinate CA has not complied with this 
document or the applicable Certificate Policy or Certification Practice 
Statement;<br>6. The Issuing CA determines that any of the information appearing in the Certificate is inaccurate or misleading;<br>7.
 The Issuing CA or Subordinate CA ceases operations for any reason and 
has not made arrangements for another CA to provide revocation support 
for the Certificate;<br>8. The Issuing CA's or 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; or<br>9. Revocation is required by the Issuing CA's Certificate Policy and/or Certification Practice Statement.<br><br><div>** Modify section 4.9.3 as follows: **</div><div><br></div><div>

The
 CA SHALL provide a process for Subscribers to request revocation of 
their own Certificates. The process MUST be described in the CA's 
Certificate Policy or Certification Practice Statement. The CA SHALL 
maintain a continuous 24x7 ability to accept and respond to revocation 
requests and Certificate Problem Reports.</div><br><div>The CA SHALL 
provide Subscribers, Relying Parties, Application Software Suppliers, 
and other third parties with clear instructions for reporting suspected 
Private Key Compromise, Certificate misuse, or other types of fraud, 
compromise, misuse, inappropriate conduct, or any other matter related 
to Certificates. The CA SHALL publicly disclose the instructions through
 a readily accessible online means and in section 1.5.2 of their CPS.</div><div><br></div><div>** Modify section 4.9.5 to read as follows: **</div><div><br></div><div>

Within
 24 hours after receiving a Certificate Problem Report, the CA SHALL 
investigate the facts and circumstances related to a Certificate Problem
 Report and provide a preliminary report on its findings to both the 
Subscriber and the entity who filed the Certificate Problem Report.</div><div><br></div>After reviewing the facts and circumstances, the CA SHALL work with the 
Subscriber and any entity reporting the Certificate Problem Report or 
other revocation-related notice to establish whether or not the 
certificate will be revoked, and if so, a date which the CA will revoke 
the certificate. The period from receipt of the Certificate Problem 
Report or revocation-related notice to published revocation MUST NOT 
exceed the time frame set forth in Section 4.9.1.1. The date selected by
 the CA SHOULD consider the following criteria:<br>1. The nature of the alleged problem (scope, context, severity, magnitude, risk of harm);<br>2. The consequences of revocation (direct and collateral impacts to Subscribers and Relying Parties);<br>3. The number of Certificate Problem Reports received about a particular Certificate or Subscriber;<br>4.
 The entity making the complaint (for example, a complaint from a law 
enforcement official that a Web site is engaged in illegal activities 
should carry more weight than a complaint from a consumer alleging that 
she didn't receive the goods she ordered); and<br>5. Relevant legislation.<br><div>
</div><div>--- MOTION ENDS ---</div><div><br></div><div>This ballot proposes a Final Maintenance Guideline.<br></div><div><br></div><div>

A comparison of the changes can be found at: <a href="https://github.com/cabforum/documents/compare/master...wthayer:patch-1" target="_blank">https://github.com/cabforum/documents/compare/master...wthayer:patch-1</a>
</div><div><br></div><div>The procedure for approval of this ballot is as follows:</div>Discussion (7 days)<br>Start Time: 2018-08-31  20:00 UTC<br>End Time: 2018-09-07  20:00 UTC<br>Vote for approval (7 days)<br>Start Time: 2018-09-07  20:00 UTC<br>End Time: 2018-09-14  20:00 UTC</div>