[Servercert-wg] VOTING BEGINS: Ballot SC31v3: Browser Alignment

[Dimitris Zacharopoulos (HARICA)]

HARICA votes "yes" to ballot SC31v3.

Overall the ballot is valuable and creates the proper policy alignment 
which is needed to improve the overall security and consistency of the 
TLS ecosystem.

As a side note, we believe the introduction of SHOULD requirements for 
end-entity certificate revocation reasons are quite challenging and need 
further discussion before they become widely adopted as an industry 
agreed policy/practice. We expect to see different interpretations of 
what each revocation reason (per RFC 5280 and ITU-T X.509) means for 
each CA and we would prefer reaching some common understanding in the 
Server Certificate Working Group before implementing it.

Finally, voting "yes" for this rather "overloaded" ballot, with 
controversial issues like the 398-validity period, doesn't alter in any 
way the agreed scope of the Forum as captured in the Bylaws and the 
Chartered Working Groups that operated under those rules. HARICA remains 
committed to the spirit of the Forum, as described in the Bylaws and in 
the industry consensus driven process that it promotes.


On 2020-07-09 8:00 μ.μ., Ryan Sleevi via Servercert-wg wrote:
> This begins the voting period for Ballot SC31v3: Browser Alignment
>
> *Purpose of Ballot:*
> *
> *
> As a regular part of Root Program maintenance, and reflecting the 
> independent nature of each Root Programs' needs and requirements, Root 
> Programs have introduced a number of requirements above and beyond 
> those captured in the Baseline Requirements. For Root Programs, this 
> approach results in a lack of certainty, as the requirements are not 
> independently audited and assessed, unless otherwise provided for. For 
> CAs, this introduces confusion when applying to have the same CA 
> certificate trusted by multiple Root Programs, as the effective 
> requirements that the CA and certificates need to comply with are the 
> union of the most-restrictive policies.
>
> The following ballot attempts to resolve this uncertainty for Root 
> Programs, and ambiguity for CAs, by incorporating Root 
> Program-specific requirements that are either effective or will, in 
> the future, be effective.*
> *
>
> This was originally drafted in 
> https://github.com/sleevi/cabforum-docs/pull/10 , and as a pull 
> request is available at https://github.com/cabforum/documents/pull/195
>
> The full description, and motivation, of each change, along with the 
> effective dates, are available at the above pull request.
>
> The following motion has been proposed by Ryan Sleevi of Google and 
> endorsed by Clint Wilson of Apple and Mike Reilly of Microsoft.
>
> The changes between SC31v1 and SC31v2 can be viewed at 
> https://github.com/cabforum/documents/compare/90a7dfe95d32ae8c76a4fa55c7b038d4928872c6...1bb3be897213b21d15b837befa885b0ba34bfd3d . 
> This corrects "Not applicable" to "No stipulation", updates the 
> formatting/markup for Pandoc and provides additional example text to 
> the effective date table for the Chair or Vice-Chair.
>
> The changes between SC31v2 and SC31v3 can be viewed at
> https://github.com/cabforum/documents/compare/1bb3be897213b21d15b837befa885b0ba34bfd3d...a9a7814da2328c3d3d54d8355eff6fe398354af8 . 
> This addresses an issue with certificate suspension for pre-existing, 
> non-TLS certificates from TLS-capable subordinate CAs, and attempts to 
> clarify the expectations around the use of CRL reason codes by 
> requiring they be documented in the CA's CP/CPS. This also shuffles a 
> requirement already present in the BRs and the RFCs, regarding 
> Delegated Responders being conflated with TLS-capable CAs, into the 
> "Cleanup and Clarification" ballot.
>
> *--- MOTION BEGINS ---
> *
> This ballot modifies "Baseline Requirements for the Issuance and 
> Management of Publicly-Trusted Certificates" ("Baseline Requirements") 
> as follows, based on Version 1.7.0
>
> MODIFY the Baseline Requirements as defined in the following redline:
> https://github.com/cabforum/documents/compare/d5067bbbfb46906c65e476ef3d55dd3b2c505a09...a9a7814da2328c3d3d54d8355eff6fe398354af8
>
> This ballot modifies the “Guidelines for the Issuance and Management 
> of Extended Validation Certificates” (“EV Guidelines”) as follows, 
> based on version 1.7.2:
>
> MODIFY the EV Guidelines as defined in the following redline:
> https://github.com/cabforum/documents/compare/d5067bbbfb46906c65e476ef3d55dd3b2c505a09...a9a7814da2328c3d3d54d8355eff6fe398354af8
>
> The Chair or Vice-Chair is permitted to update the Relevant Dates of 
> the Baseline Requirements and the EV Guidelines to reflect these changes.
>
> *--- MOTION ENDS ---
> *
> This ballot proposes two Final Maintenance Guidelines.
>
> The procedure for approval of this ballot is as follows:
>
> Discussion (7+ days)
> Start Time: 2-July 2020 00:00 UTC
> End Time: after 9-July 2020 00:00 UTC
>
> Vote for approval (7 days)
> Start Time: 9-July 2020 17:00 UTC
> End Time: 16-July 2020 17:00 UTC
>
> _______________________________________________
> 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/20200713/d2674229/attachment.html>