[Servercert-wg] [cabfpub] [EXTERNAL] Reviving Ballot 213 - Revocation Timeline Extension

Thu Aug 9 13:22:39 MST 2018

Still endorsing.

Dimitris. 

-----Original Message-----
From: Wayne Thayer via Servercert-wg <servercert-wg at cabforum.org>
To: CA/Browser Forum Public Discussion List <public at cabforum.org>, CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Sent: Thu, 09 Aug 2018 20:51
Subject: Re: [Servercert-wg] [cabfpub] [EXTERNAL] Reviving Ballot 213 - Revocation Timeline Extension

Now that governance reform is mostly behind us, I would like to move
forward with this ballot. Jeremy originally proposed this last year, then I
reintroduced it in May and we discussed it at the London F2F, resulting in
one minor change to the language.

Tim and Dimitris, will you please confirm that you will still endorse this?
I would like to begin the discussion period on Monday.

Here is the formal ballot language for review:

Ballot SC6: 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 to establish a date by
which the CA will revoke the certificate.

The following motion has been proposed by  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 Section 4.9.1.1 to read as follows: **

The CA SHALL revoke a Certificate within 24 hours if:

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 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;
11. The technical content or format of the 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 Certificates should be revoked and replaced by CAs within a
given period of time);
12. The CA is made aware of a vulnerability that exposes the Subscriber's
Private Key to compromise; or
13. The CA is made aware that the Subscriber's Private Key is being
publicly distributed in a software package.

** 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 any
entity reporting the Certificate Problem Report or other revocation-related
notice to establish a date when the CA will revoke the Certificate which
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 ---

A comparison of the changes can be found at:
https://github.com/cabforum/documents/compare/master...wthayer:patch-1?short_path=7f6d14a#diff-7f6d14a20e7f3beb696b45e1bf8196f2

The procedure for approval of this ballot is as follows:

Discussion (7+ days)

Start Time: 2018-08-13  19:00 UTC

End Time: Not before 2018-08-20  19:00 UTC

Vote for approval (7 days)

Start Time: 2018-08-20  19:00 UTC

End Time: 2018-08-27  19:00 UTC

On Sat, Jun 23, 2018 at 5:54 AM <jimmy at it.auth.gr> wrote:

> I'll also endorse.
>
>
> Dimitris.
>
> -----Original Message-----
> From: Tim Hollebeek via Public <public at cabforum.org>
> To: Wayne Thayer <wthayer at mozilla.com>, CA/Browser Forum Public Discussion
> List <public at cabforum.org>
> Sent: Fri, 22 Jun 2018 9:13
> Subject: Re: [cabfpub] [EXTERNAL] Reviving Ballot 213 - Revocation
> Timeline Extension
>
> I’ll endorse this.
>
>
>
> -Tim
>
>
>
> *From:* Public [mailto:public-bounces at cabforum.org] *On Behalf Of *Wayne
> Thayer via Public
> *Sent:* Thursday, June 21, 2018 6:24 PM
> *To:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject:* Re: [cabfpub] [EXTERNAL] Reviving Ballot 213 - Revocation
> Timeline Extension
>
>
>
> Our discussion of this proposal at the F2F uncovered two issues:
>
>
>
> 1. A minor update to section 4.9.5 clarifying that the report the CA must
> produce within 24 hours of receiving a problem report is meant to be a
> report on the current status of their investigation. This is now described
> as a "preliminary report". [1]
>
> 2. A long discussion [2] about removing revocation reason 4.9.1.1(4): The
> CA obtains evidence that the Certificate was misused; The scope of this
> change (including Geoff's observation about the definition of key
> compromise and the desire to allow use/misuse to be defined in accordance
> with RFC 3647) is big enough that I've decided to leave those changes for a
> separate ballot (that I will propose unless someone else beats me to it).
>
>
>
> Are two members willing to endorse the current ballot proposal [3]?
>
>
>
> I will convert this to a formal ballot and begin the discussion period
> after the July 2nd governance change.
>
>
>
> Thanks,
>
>
>
> Wayne
>
>
>
> [1]
> https://github.com/wthayer/documents/commit/0a214f0bb5a09db4d12e2dc6f19463dcdef6c82a
>
> [2] https://cabforum.org/pipermail/public/2018-June/013547.html
>
> [3] https://github.com/cabforum/documents/compare/master...wthayer:patch-1
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180809/7f51bb87/attachment-0001.html>