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

[Wayne Thayer]

This has the potential to cause confusion, so I'd like to attempt to fix
it. Given that a reasonable interpretation of the existing definition of
key compromise encompasses reasons 12 and 13, but I want to leave those two
reasons in the document for the sake of clarity as Ryan suggests, maybe I
should just move those two up to the 24-hour section? I could also be
persuaded that a vulnerability is different than proof of key compromise,
in which case 12 could stay in the 5-day section and we could move "or
there exists a practical technique by which an unauthorized person may
discover its value" from the definition of key compromise to 12. What do
others think?

- Wayne

On Mon, Aug 20, 2018 at 7:04 AM Ryan Sleevi <sleevi at google.com> wrote:

>
>
> On Mon, Aug 20, 2018 at 9:17 AM Doug Beattie via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
>> We’re having a hard time determining the differences between the
>> following:
>>
>>
>>
>> The CA SHALL revoke a Certificate within 24 hours if:
>>
>> 3. The CA obtains evidence that the Subscriber's Private Key
>> corresponding to the Public Key in the Certificate suffered a Key
>> Compromise; or
>>
>>
>>
>> and
>>
>>
>>
>> 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:
>>
>>
>>
>> 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.
>>
>>
>>
>> If  “Subscriber's Private Key is being publicly distributed in a
>> software package”, isn’t that the same as #3: “obtains evidence that the
>> Subscriber's Private Key corresponding to the Public Key in the Certificate
>> suffered a Key Compromise”?
>>
>
>>
>> How do you see #12 in reality?  What types of vulnerabilities do you
>> envision that could expose a subscribers Private Key that are not also
>> consistent with #3?
>>
>
> While this is the same argument that I've made in the past, I think the
> goal here is to reduce ambiguity for those that might take a tortured
> reading of the text.
>
> For example, at least one vendor 'obfuscated' the private key within their
> binary, requiring running the embedded private key through a transformation
> (I hesitate to say decryption, since the passphrase was itself fixed within
> the binary). Such a vendor might argue that the key has not been
> compromised until someone reverses the binary. This resolves that ambiguity
> by saying that the distribution within the binary itself constitutes a
> compromise, regardless of whether a passphrase is used.
>
>
>> Also, the definition of Private Key Compromise is very broad, and the
>> scenarios in #12 and #13 would appear to fall into “Key Compromise” which
>> further causes confusion about them.  What constitutes a “*practical
>> technique*”?  If we applied this definition to #12 and #13, wouldn’t
>> these all fall into the 24 hour rule?
>>
>>
>>
>> *Key Compromise:* A Private Key is said to be compromised if its value
>> has been disclosed to an unauthorized person, an unauthorized person has
>> had access to it, or there exists a practical technique by which an
>> unauthorized person may discover its value.  A Private Key is also
>> considered compromised if 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.
>>
>>
>>
>>
>>
>> Doug
>>
>>
>>
>> *From:* Public <public-bounces at cabforum.org> *On Behalf Of *Wayne Thayer
>> via Public
>> *Sent:* Monday, 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:* [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
>> _______________________________________________
>> Servercert-wg mailing list
>> Servercert-wg at cabforum.org
>> http://cabforum.org/mailman/listinfo/servercert-wg
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20180820/1431158e/attachment-0001.html>