(Draft Ballot) Cleanups and Clarifications

[sleevi]

Overview

This ballot attempts to fix the numerous typographical and editorial issues that have been identified in the SCWG documents ("spring cleanup"), such as incorrect section references, expired effective dates, or spelling and grammatical mistakes. Additionally, it attempts to provide guidance and clarification for language that has been viewed as ambiguous or having multiple interpretations.

Changes

EV Guidelines

• The "Subject Organization Identifier Extension" is not a defined term, and is corrected to "CA/Browser Forum Organization Identifier Extension" throughout ( EV Guidelines: SC17 cleanups cabforum/servercert#152 )
• The effective dates in Section 8.2.2 have been removed, as the last effective date was 31 May 2018. ( EV Guidelines: Past compliance dates cabforum/servercert#161 )
• Section 9.8.2 mispelled "Forum" as "Form"
• The effective date in Section 9.8.2 has been removed, as it was effective 31 January 2020 ( EV Guidelines: Past compliance dates cabforum/servercert#161 )
• Section 11.12.2 is corrected to point to the latest IFAC and BIS lists ( Broken links in "Guidelines for the issuance and management of extended validation certificates" cabforum/servercert#76 )
• Appendix H is corrected to refer to Section 9.8.2, not Section 9.8.1 ( EV Guidelines: SC17 cleanups cabforum/servercert#152 )

Baseline Requirements

• The references to CAA are updated to refer to RFC 8659, which incorporates CABF feedback ( Baseline Requirements: Update CAA from 6844 to 8659 cabforum/servercert#168 ).
  • Note: This removes Appendix A, and renumbers accordingly
• 3.2.2.4.6's language on sunset/effective date is brought into consistency with our other sections in 3.2.2.4 on sunsets. ( Baseline Requirements: Add explicit date in Section 3.2.2.4.6 cabforum/servercert#163 )
• An incorrect reference to 3.2.5 in Section 3.2.2.5 has been fixed to say Section 3.2.2.5 ( Baseline Requirements: Incorrect reference in 3.2.2.5 cabforum/servercert#155 )
• A typo in Section 7.1.5 is fixed ("compliancy" -> "compliance") ( Baseline Requirements: Typo in Section 7.1.5 cabforum/servercert#159 )
• The handling of Certificate Policy OIDs for Intermediates/Roots is restructured, so that it's clear that their presence in a Subordinate/Root makes them subject to the BRs (and EVGs, if appropriate), but their presence in a Subscriber certificate make them subject to the certificate profile, and in particular, the Subject profile (e.g. DV/OV/IV/EV)

Revocation Clarifications

The following are an attempt to clarify the logical consequences of the various policies surrounding weak and compromised keys ( cabforum#164 )

• 4.9.1.1's revocation requirements are updated to express their logical consequences.
  • Namely, CAs are required to revoke a certificate within 24 hours if a Private Key has suffered a Key Compromise
  • Implicitly, if there is a demonstrated or proven method to easily compute the Private Key, then the private key has suffered a Key Compromise
  • Therefore, explicitly specify that keys using such methods also require 24 hours revocation

However, keys that may have been generated with a flawed method, or there's a method which exposes a key to compromise (e.g. a signing oracle, Heartbleed), those remain at 5 days.

The distinction between these two sets is whether the public key alone is sufficient to compromise the key; if it is, the CA MUST treat it as compromised. However, if there are other factors (e.g. it requires additional state from an RNG, requires interacting with a service or use of the key), then those are left at 5 days, unless someone has already done so, at which point, it's a Key Compromise.

Section 6.1.1.3 is similar reworked, to make it clearer that if a certificate will be immediately revoked due to one of the Private Key (flawed, weak, compromised), then the CA MUST NOT issue the certificate. A CA that continually issued certificates to weak keys, and then revoked them, effectively bypasses revocation by allowing such keys to be used for between 72 hours and 10 days (depending on the lifetime of the CRL/OCSP and response times of the CA). ( cabforum#171 )

Section 4.9.1.1 places requirements on when a CA MUST revoke certificates. These obligations are then documented within the CA's CP/CPS, either implicitly through a statement of compliance with the Baseline Requirements or explicitly through enumerating these. However, at various points, CAs have raised concern that their Subscriber Agreement prevents them from adhering to their CP/CPS and the Baseline Requirements, because their Subscriber Agreement does not permit them to revoke as required by Section 4.9.1.1. This updates Section 9.6.3 to instead bind the Subscriber Agreement to the CA's CP, CPS, and the Baseline Requirements, as discussed at cabforum#172 .

The existing provisions within Section 9.6.3 regarding specific uses of the certificate are then folded into this requirement, by allowing the CA's CP/CPS to detail the cases they revoke within Section 4.9.1.1, or, optionally, within their Subscriber Agreement of Terms of Use. This ensures consistency with the primary objective, of ensuring that the Subscriber acknowledges that the CA MAY revoke the Certificate at any time, for the reasons specified by the CA.

[sleevi]

While it would appear this is moving from 5 day to 24 hour, this is really just a clarified restatement of 3 (that is, demonstration of easy, arbitrary recovery IS a Key Compromise)

[wthayer]

IMO, this change along with the 6.1.1.3 and 9.6.3(8) proposals are more than a clarification and should be combined into a separate 'revocation improvements' ballot.

[sleevi]

Thanks. I appreciate the feedback, although I (clearly :P) disagree. This was covered on the posting at https://cabforum.org/pipermail/servercert-wg/2020-April/001815.html about how this is:

"Clarify an existing /implicit/ requirement by making it /explicit", and
then secondarily "Clarify the logical consequences of an existing
requirement".

I can understand a desire to have a ballot that is only "uncontroversial" changes, but the value of that is largely dependent on the urgency of fixing the issues. Given that these areas have caused significant confusion and issues, I think they're important to clarify, and I don't think the remaining changes are particularly harmed by having that discussion sooner than later. So if you disagree with the substance, such as disagree that they logically follow or that they're reasonable expectations, and not just the process points, I think it'd be useful to have on the list.

[mpalmer]

I'm concerned that this wording is still confusing, because a Debian weak key isn't a "method", as such, unless you want to get all reductionist and say that "looking up the public key in a hash table" is a "method". If you asked me "give me an example of a method to easily compute a private key based on a public key", I'd think "RoCA" long before I thought "Debian weak key".

That being said, I don't have an immediate suggestion as to better wording that isn't either as specific as "don't issue certificates that use Debian weak keys", or so broad as to be meaningless, like "any key which is included in a widely-publicised list of unsuitable keys". I am inclined to think that a better description of Debian weak keys is actually the definition still under the "5 day" time period: "the specific method used to generate the Private Key was flawed". I think we can all agree that seeding your RNG with a 15 bit number is a flawed method with which to generate a private key...

[sleevi]

@mpalmer Thanks for your feedback. I don’t think it’s as black or white as you suggest, however. Computing the private key by looking up in a table of known weak public keys is a method, as would generating a set of known weak keys by reproducing the code in question for its permutations.

[sleevi]

Ok, that makes sense, and I’ll work to restore this, and see about clarifying a bit more the scenarios.

[BenWilson-Mozilla]

Mozilla will endorse this as a ballot.