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

Thu Aug 6 09:57:23 MST 2020

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/4b7ffabd/attachment.html>