[cabfpub] [Servercert-wg] Ballot SC6 v3 - Revocation Timeline Extension

Fotis Loukos fotisl at ssl.com
Wed Sep 12 13:33:09 UTC 2018


SSL.com votes YES on Ballot SC6 v3.

Regards,
Fotis

On 10/09/2018 09:54 μμ, Wayne Thayer via Servercert-wg wrote:
> This ballot entered the voting period late on Friday. Voting ends this
> Friday 2018-09-14 at 20:00 UTC.
> 
> On Fri, Aug 31, 2018 at 12:51 PM Wayne Thayer <wthayer at mozilla.com
> <mailto:wthayer at mozilla.com>> wrote:
> 
>     Here is version 3 of this ballot, incorporating changes to v2
>     suggested by Bruce and Ryan (thanks!).
> 
>     I noticed that our current bylaws have reverted back to a
>     fixed-length discussion period, so I have changed this version to
>     comply.
> 
>     ==========================================
> 
>     Ballot SC6 version 3: Revocation Timeline Extension
> 
>     Purpose of Ballot:
>     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:
>     * 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.
>     * 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."
>     * 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.
>     * 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.
>     * It requires CAs to disclose their problem reporting mechanisms in
>     a standard location: CPS section 1.5.2.
>     * 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.
> 
>     The following motion has been proposed by  Wayne Thayer of Mozilla
>     and endorsed by Tim Hollebeek of DigiCert and Dimitris Zacharopoulos
>     of Harica.
>     

>     --- 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:


> 
>     ** Modify the definition of Key Compromise as follows: **
>     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.
> 
>     ** Modify Section 4.9.1 to read as follows: **


> 
>     4.9.1.1 Reasons for Revoking a Subscriber Certificate
> 
>     The CA SHALL revoke a Certificate within 24 hours if one or more of
>     the following occurs:
>     1. The Subscriber requests in writing that the CA revoke the
>     Certificate;
>     2. The Subscriber notifies the CA that the original certificate
>     request was not authorized and does not retroactively grant
>     authorization;
>     3. The CA obtains evidence that the Subscriber's Private Key
>     corresponding to the Public Key in the Certificate suffered a Key
>     Compromise; or
>     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.
> 
>     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:
>     1. The Certificate no longer complies with the requirements of
>     Sections 6.1.5 and 6.1.6;
>     2. The CA obtains evidence that the Certificate was misused;
>     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;
>     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);
>     5. The CA is made aware that a Wildcard Certificate has been used to
>     authenticate a fraudulently misleading subordinate Fully-Qualified
>     Domain Name;
>     6. The CA is made aware of a material change in the information
>     contained in the Certificate;
>     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;
>     8. The CA determines or is made aware that any of the information
>     appearing in the Certificate is inaccurate;
>     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;
>     10. Revocation is required by the CA's Certificate Policy and/or
>     Certification Practice Statement; or
>     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 http://wiki.debian.org/SSLkeys), or
>     if there is clear evidence that the specific method used to generate
>     the Private Key was flawed.

> 
>     4.9.1.2 Reasons for Revoking a Subordinate CA Certificate
> 
>     The Issuing CA SHALL revoke a Subordinate CA Certificate within
>     seven (7) days if one or more of the following occurs:
>     1. The Subordinate CA requests revocation in writing;
>     2. The 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 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;
>     4. The Issuing CA obtains evidence that the Certificate was misused;
>     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;
>     6. The Issuing CA determines that any of the information appearing
>     in the Certificate is inaccurate or misleading;
>     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;
>     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
>     9. Revocation is required by the Issuing CA's Certificate Policy
>     and/or Certification Practice Statement.
> 
>     ** Modify section 4.9.3 as follows: **
> 
>     

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.
> 
>     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.
> 
>     ** Modify section 4.9.5 to read as follows: **
> 
>     

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.
> 
>     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:
>     1. The nature of the alleged problem (scope, context, severity,
>     magnitude, risk of harm);
>     2. The consequences of revocation (direct and collateral impacts to
>     Subscribers and Relying Parties);
>     3. The number of Certificate Problem Reports received about a
>     particular Certificate or Subscriber;
>     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
>     5. Relevant legislation.
>     

>     --- MOTION ENDS ---
> 
>     This ballot proposes a Final Maintenance Guideline.
> 
>     

A comparison of the changes can be found at:
>     https://github.com/cabforum/documents/compare/master...wthayer:patch-1

> 
>     The procedure for approval of this ballot is as follows:
>     Discussion (7 days)
>     Start Time: 2018-08-31  20:00 UTC
>     End Time: 2018-09-07  20:00 UTC
>     Vote for approval (7 days)
>     Start Time: 2018-09-07  20:00 UTC
>     End Time: 2018-09-14  20:00 UTC
> 
> 
> 
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
> 


-- 
Fotis Loukos, PhD
Director of Security Architecture
SSL Corp
e: fotisl at ssl.com
w: https://www.ssl.com



More information about the Public mailing list