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 <[email protected]> wrote: > > > On Mon, Aug 20, 2018 at 9:17 AM Doug Beattie via Servercert-wg < > [email protected]> 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 <[email protected]> *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 < >> [email protected]> >> *Cc:* CA/Browser Forum Public Discussion List <[email protected]> >> *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 >> [email protected] >> http://cabforum.org/mailman/listinfo/servercert-wg >> >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
