[Servercert-wg] Ballot SC##: Cleanups and Clarifications

Thu Aug 13 06:53:00 MST 2020

Hi Ryan

Buypass has been working with improvements to the language in EVGL 9.8.2 to remove a possible ambiguity and to clarify what to be included in the cabfOrganizationIdentifier extension.

Our current proposal for improvement is a minor change and as this ballot addresses clarification for language that has been viewed as ambiguous, we suggest to include our proposal in this ballot. We acknowledge that this change may be too late in the process for this ballot.

We propose to change the last paragraph of EVGL 9.8.2 from:
“where the subfields and have the same meanings and restrictions described in Section 9.2.8. The CA SHALL validate the contents using the requirements in Section 9.2.8.“
to
“where the subfields have the same values, meanings and restrictions described in Section 9.2.8. The CA SHALL validate the contents using the requirements in Section 9.2.8.”

Regards
Mads

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: torsdag 6. august 2020 18:57
To: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: [Servercert-wg] Ballot SC##: Cleanups and Clarifications

Per our call today, I've created draft versions of the Cleanups and Clarifications ballot and opened them as PRs in the main CA/Browser Forum repository

I'm seeking two endorsers for this ballot.

https://github.com/cabforum/documents/pull/207<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fpull%2F207&data=02%7C01%7C%7C88d6160f7cdf4956a68a08d83a29ef0d%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637323299089262280&sdata=foXC0r%2FIMu0r1t4juU7%2FHenwSRoSoPdTdp8xWeS5j%2BU%3D&reserved=0> is the version of the ballot against the completed SC30 and SC31 (i.e. assuming no IP exclusions are filed that necessitate the formation of a PAG). That is, this is the version folks "should" review.
  - https://github.com/cabforum/documents/pull/208<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fpull%2F208&data=02%7C01%7C%7C88d6160f7cdf4956a68a08d83a29ef0d%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637323299089272232&sdata=0gqvbAtn7bvKHRry413Cev1GLKqFBHej9PUiffos4HI%3D&reserved=0> is the version **without** SC30 and SC31. It's provided in the event something happens re: SC30/SC31, but will almost certainly be closed without action assuming all is well with those ballots.

I am copy/pasting the description of changes and their explanation from the PR at the bottom of this e-mail, although certainly viewing it on the PR is likely easier for folks.

=============
Purpose of Ballot:

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, multiple, or conflicting interpretations.

CAs SHOULD carefully review each change, to ensure no normative impact upon their CA operations and practices that may have resulted from these ambiguities and consistency issues.

The following motion has been proposed by Ryan Sleevi of Google and endorsed by xxx of yyy and xxx of yyy.

-- MOTION BEGINS --

This ballot modifies the "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" ("Baseline Requirements"), based on Draft Version 1.7.x with SC30 and SC31:

MODIFY the Baseline Requirements as defined in the following redline:
https://github.com/cabforum/documents/compare/1e0f7662c909c983bc4f534469fb0f01a5120f39...6bf0eec61a8ba4d9f97e33134da09ef4d2936b5c<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fcompare%2F1e0f7662c909c983bc4f534469fb0f01a5120f39...6bf0eec61a8ba4d9f97e33134da09ef4d2936b5c&data=02%7C01%7C%7C88d6160f7cdf4956a68a08d83a29ef0d%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637323299089272232&sdata=ZbCEihhKqDiH%2FzKKqAGsLwHY6GFoOhJxKi2b%2Bd0aPQo%3D&reserved=0>

This ballot modifies the "Guidelines for the Issuance and Management of Extended Validation Certificates" ("EV Guidelines") as follows, based on Draft Version 1.7.x with SC30 and SC31:

MODIFY the EV Guidelines as defined in the following redline:
https://github.com/cabforum/documents/compare/1e0f7662c909c983bc4f534469fb0f01a5120f39...6bf0eec61a8ba4d9f97e33134da09ef4d2936b5c<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fcompare%2F1e0f7662c909c983bc4f534469fb0f01a5120f39...6bf0eec61a8ba4d9f97e33134da09ef4d2936b5c&data=02%7C01%7C%7C88d6160f7cdf4956a68a08d83a29ef0d%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637323299089272232&sdata=ZbCEihhKqDiH%2FzKKqAGsLwHY6GFoOhJxKi2b%2Bd0aPQo%3D&reserved=0>

The above modifications assumes the successful completion of the IP review period of Ballots SC30 and SC31, as announced at https://archive.cabforum.org/pipermail/servercert-wg/2020-July/002117.html<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.cabforum.org%2Fpipermail%2Fservercert-wg%2F2020-July%2F002117.html&data=02%7C01%7C%7C88d6160f7cdf4956a68a08d83a29ef0d%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637323299089282189&sdata=1qGqbGN9pp5T%2BM9dTcxwLeAHP3zlcnmbfu67MEcuWHQ%3D&reserved=0> , and reflect changes to overlapping sections on that assumption. Per CA/Browser Forum Bylaws 2.4(10), should those ballots fail to be finally adopted, the following modifications shall be made, as based upon the Version 1.7.0 of the Baseline Requirements and 1.7.2 of the EV Guidelines, as accounting for changes within these overlapping sections:

MODIFY the Baseline Requirements as defined in the following redline:
https://github.com/cabforum/documents/compare/5f804ccd4a202036a9868d1c43849e43e4c4853d...9cb110f792228d8ac5d618a32a39767d0b24d679<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fcompare%2F5f804ccd4a202036a9868d1c43849e43e4c4853d...9cb110f792228d8ac5d618a32a39767d0b24d679&data=02%7C01%7C%7C88d6160f7cdf4956a68a08d83a29ef0d%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637323299089282189&sdata=bCf9jxNUXh%2FgmjpvZAhVNwzojdTITZFfjGT%2BvGOHH3M%3D&reserved=0>

MODIFY the EV Guidelines as defined in the following redline:
https://github.com/cabforum/documents/compare/5f804ccd4a202036a9868d1c43849e43e4c4853d...9cb110f792228d8ac5d618a32a39767d0b24d679<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fcompare%2F5f804ccd4a202036a9868d1c43849e43e4c4853d...9cb110f792228d8ac5d618a32a39767d0b24d679&data=02%7C01%7C%7C88d6160f7cdf4956a68a08d83a29ef0d%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637323299089292145&sdata=CW5%2BFVhNZ%2F065wVNlqJmrqY%2B0I1fQb4jyFrYL%2BZZXOY%3D&reserved=0>

-- MOTION ENDS --

This ballot proposes two Final Maintenance Guidelines.

The procedure for approval of this ballot is as follows:

Discussion (7+ days)
Start Time: TBD
End Time: TBD

Vote for approval (7 days)
Start Time: TBD
End Time: TBD

Description from the PR:

# 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, multiple, or conflicting 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 ( https://github.com/cabforum/documents/issues/152<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fissues%2F152&data=02%7C01%7C%7C88d6160f7cdf4956a68a08d83a29ef0d%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637323299089292145&sdata=20xDGbpAKvNqJdSzMRlZrEXS9bdMX5rtlTf0jObtiOQ%3D&reserved=0> )
* The effective dates in Section 8.2.2 have been removed, as the last effective date was 31 May 2018. ( https://github.com/cabforum/documents/issues/161<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fissues%2F161&data=02%7C01%7C%7C88d6160f7cdf4956a68a08d83a29ef0d%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637323299089292145&sdata=6U5SfPuwxIlskiVY8NsN9RppH61zCtDB44FpYg01%2FjE%3D&reserved=0> )
* Section 9.8.2 misspelled "Forum" as "Form"
* The effective date in Section 9.8.2 has been removed, as it was effective 31 January 2020 ( https://github.com/cabforum/documents/issues/161<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fissues%2F161&data=02%7C01%7C%7C88d6160f7cdf4956a68a08d83a29ef0d%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637323299089302105&sdata=VKMvUl8ybQKOduRQcAH%2BGqJXOB4J7lebqVU52D%2FIBhk%3D&reserved=0> )
* Section 11.12.2 is corrected to point to the latest IFAC and BIS lists ( https://github.com/cabforum/documents/issues/76<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fissues%2F76&data=02%7C01%7C%7C88d6160f7cdf4956a68a08d83a29ef0d%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637323299089302105&sdata=yJ1K5atnOVMZ59Su1E6hXe8SWjrzI0ICLf8NOwOQPSI%3D&reserved=0> )
* Appendix H is corrected to refer to Section 9.8.2, not Section 9.8.1 ( https://github.com/cabforum/documents/issues/152<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fissues%2F152&data=02%7C01%7C%7C88d6160f7cdf4956a68a08d83a29ef0d%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637323299089312063&sdata=uBPFoPTTRgMJPmHMTWca96fERZY2uJUbONR13n9cHyw%3D&reserved=0> )

### Baseline Requirements
* The references to CAA are updated to refer to RFC 8659, which incorporates CABF feedback ( https://github.com/cabforum/documents/issues/168<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fissues%2F168&data=02%7C01%7C%7C88d6160f7cdf4956a68a08d83a29ef0d%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637323299089312063&sdata=8uukJQw%2BGmQmUtKetoQ%2Bt2H%2BZQKcGsY5DP4lvXsPA%2Fw%3D&reserved=0> ).
  * 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. ( https://github.com/cabforum/documents/issues/163<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fissues%2F163&data=02%7C01%7C%7C88d6160f7cdf4956a68a08d83a29ef0d%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637323299089312063&sdata=pWMMAsBM5qw9aEu0fU6wCdIc84TehXdocedjiQm5ElU%3D&reserved=0> )
* An incorrect reference to 3.2.5 in Section 3.2.2.5 has been fixed to say Section 3.2.2.5 ( https://github.com/cabforum/documents/issues/155<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fissues%2F155&data=02%7C01%7C%7C88d6160f7cdf4956a68a08d83a29ef0d%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637323299089322018&sdata=9CtvhkLVv400bEgEpxRc71wIAa3huCmeUWkQEDc0eqU%3D&reserved=0> )
* A typo in Section 7.1.5 is fixed ("compliancy" -> "compliance") ( https://github.com/cabforum/documents/issues/159<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fissues%2F159&data=02%7C01%7C%7C88d6160f7cdf4956a68a08d83a29ef0d%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637323299089322018&sdata=elZ1c6IBTIhzJ3pieu2QfI%2F9E92kemp8i21bKkL6i5Q%3D&reserved=0> )
* 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) ( https://github.com/cabforum/documents/issues/179<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fissues%2F179&data=02%7C01%7C%7C88d6160f7cdf4956a68a08d83a29ef0d%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637323299089322018&sdata=UyCD3RC5hI2o1Qk08xHMpRs8hBZXzmW4RccfvwSDcFo%3D&reserved=0> )

## Revocation Clarifications
The following are an attempt to clarify the logical consequences of the various policies surrounding weak and compromised keys ( https://github.com/cabforum/documents/issues/164<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fissues%2F164&data=02%7C01%7C%7C88d6160f7cdf4956a68a08d83a29ef0d%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637323299089331976&sdata=nKdNlkF8QRFZcwSn8uJYwhm5%2FUrrzPea51TbZn%2BoljM%3D&reserved=0> )
* 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 similarly 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). ( https://github.com/cabforum/documents/issues/171<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fissues%2F171&data=02%7C01%7C%7C88d6160f7cdf4956a68a08d83a29ef0d%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637323299089331976&sdata=RDqjBcXQJxq82UnmJtfZx50OnjrbriZ7sEMyILA7R4s%3D&reserved=0> )

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 https://github.com/cabforum/documents/issues/172<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fissues%2F172&data=02%7C01%7C%7C88d6160f7cdf4956a68a08d83a29ef0d%7C57919b2e6d5b40b9a34a55bddb02dfee%7C0%7C0%7C637323299089331976&sdata=Y3QEDJr2EEO2z8Ce7xG4W4hoE%2BDNbSWzzZvcYAyVRG4%3D&reserved=0> .

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200813/e0d74e35/attachment-0001.html>