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

[Wayne Thayer]

On Tue, Aug 14, 2018 at 11:15 AM Bruce Morton <
Bruce.Morton at entrustdatacard.com> wrote:

> Hi Wayne,
>
>
>
> The term “misleading” is used in item 5 below. Should this also be removed?
>
>
>
Great question Bruce. My opinion is that the language in #5 "fraudulently
misleading" (presumably describing phishing) is somewhat better than the
use of "misleading" that was removed. I'm not certain how to fix #5 without
removing it completely, and I'm not confident there is consensus for that.
I'm open to suggestions but my preference is to avoid any change that could
derail this ballot.

Thanks, Bruce.
>
>
>
> *From:* Public [mailto:public-bounces at cabforum.org] *On Behalf Of *Wayne
> Thayer via Public
> *Sent:* August 13, 2018 4:58 PM
> *To:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg at cabforum.org>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject:* [EXTERNAL][cabfpub] Ballot SC6 - Revocation Timeline Extension
>
>
>
> This begins the formal discussion period for ballot SC6.
>
>
>
> ==========================================
>
>
>
> 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  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 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: TBD
>
> End Time: TBD
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180815/cb9954cc/attachment.html>