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

Thu Aug 6 10:26:18 MST 2020

Ryan - GlobalSign will endorse.

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan 
Sleevi via Servercert-wg
Sent: Thursday, August 6, 2020 12:57 PM
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 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 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

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

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 , 
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

MODIFY the EV Guidelines as defined in the following redline:

https://github.com/cabforum/documents/compare/5f804ccd4a202036a9868d1c43849e43e4c4853d...9cb110f792228d8ac5d618a32a39767d0b24d679

-- 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 )
* 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 )
* 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 )
* Section 11.12.2 is corrected to point to the latest IFAC and BIS lists ( 
https://github.com/cabforum/documents/issues/76 )
* Appendix H is corrected to refer to Section 9.8.2, not Section 9.8.1 ( 
https://github.com/cabforum/documents/issues/152 )

### Baseline Requirements
* The references to CAA are updated to refer to RFC 8659, which incorporates 
CABF feedback ( https://github.com/cabforum/documents/issues/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. ( 
https://github.com/cabforum/documents/issues/163 )
* 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 )
* A typo in Section 7.1.5 is fixed ("compliancy" -> "compliance") ( 
https://github.com/cabforum/documents/issues/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) ( 
https://github.com/cabforum/documents/issues/179 )

## 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 )
* 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 )

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 .

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/20200806/082cd799/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5688 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200806/082cd799/attachment-0001.p7s>