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

Thu Aug 13 06:57:02 MST 2020

That seems reasonable - we haven't even started the discussion period yet
because Corey's been sending corrections on GitHub :)

On Thu, Aug 13, 2020 at 9:53 AM Mads Egil Henriksveen <
Mads.Henriksveen at buypass.no> wrote:

> 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/00374de9/attachment-0001.html>