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

[Ben Wilson]

I'll endorse.

On Thu, Aug 6, 2020 at 11:26 AM Doug Beattie via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> 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.
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200806/fdd21e53/attachment.html>