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

Manchanda, Mayur mmanchan at visa.com
Thu Jul 16 12:44:07 MST 2020


VISA votes NO on Ballot SC31v3: Browser Alignment
Best regards,

Mayur Manchanda, CISSP, CISM  |  Director, Applied Cryptography - Cybersecurity, Security Architecture
O 571.439.7773  |  M 571.335.3014  |  E mmanchan at visa.com<mailto:mmanchan at visa.com>

[cid:image001.png at 01D65B87.F0218710]

The information contained in this transmission (including any attachments) is confidential and may be privileged. It is intended only for the use of the individual or entity named above. If you are not the intended recipient, dissemination, distribution, or copy of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of this message and its attachments and notify me immediately.

From: Servercert-wg <servercert-wg-bounces at cabforum.org<mailto:servercert-wg-bounces at cabforum.org>> On Behalf Of Neil Dunbar via Servercert-wg
Sent: Thursday, July 16, 2020 12:44 PM
To: servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] VOTING BEGINS: Ballot SC31v3: Browser Alignment

On 09/07/2020 18: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<mailto: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/20200716/803b895b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 11876 bytes
Desc: image001.png
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200716/803b895b/attachment-0001.png>


More information about the Servercert-wg mailing list