So far I’ve seen votes on the public list from: Amazon Comodo DigiCert GlobalSign Symantec
Kirk’s note said the public list was out over the weekend, so anyone on not on this list needs to re-submit their vote if they voted. We have two more days for voting and need at least seven more votes (including at least one browser) to hit quorum. Thanks, Peter > On Jul 19, 2017, at 3:33 PM, Ben Wilson <[email protected]> wrote: > > Also, I have capitalized “Domain Name” in the definition of “Domain Label”, > as shown below and in the attached PDF document. > > On Jul 19, 2017, at 3:52 PM, Peter Bowen <[email protected] > <mailto:[email protected]>> wrote: > > One more update before voting starts, based on a request from Adriano. The > definition of the term Wildcard Domain Name has been updated. > > On Jul 18, 2017, at 8:28 PM, Peter Bowen <[email protected] > <mailto:[email protected]>> wrote: > > Thanks to all who provided comments. I’ve integrated the feedback from Kirk, > Geoff, and Wayne, including using the definitions that Geoff proposed. BR > text that has changed is in red. Additionally we dropping the proposed > change for fully qualified domain name. > > Ryan and Ben have agreed to these changes. Voting is scheduled to start in > about 18 hours. > > Thanks for the all the feedback! > > On Jul 12, 2017, at 10:24 AM, Ben Wilson via Public <[email protected] > <mailto:[email protected]>> wrote: > > Ballot 202 - Underscore and Wildcard Characters > > The current Baseline Requirements do not expressly allow underscore > characters in Subject Alternative Names. This ballot seeks to clarify that > one or more underscore characters (“_”) are allowed in FQDNs. In many places > it also replaces the term "FQDN" with "Domain Name" because "Domain Name" now > means either "FQDN" or "Wildcard Domain Name". The ballot clarifies > validation of wildcard domain names. It also cleans up some of the language > in Sections 3.2.2.4 and 7.1.4.2.1 of the Baseline Requirements. > > The following motion has been proposed by Ben Wilson of DigiCert and endorsed > by Peter Bowen of Amazon and Ryan Sleevi of Google to introduce new Final > Maintenance Guidelines for the "Baseline Requirements Certificate Policy for > the Issuance and Management of Publicly-Trusted Certificates" (Baseline > Requirements). > > --Motion Begins-- > > A. In Sections 1.3.2, 1.6 (Base Domain Name), 2.2, 3.2.2.4, 3.2.2.4.5, > 3.2.2.4.6, 3.2.2.4.10, 3.2.2.4.11, 4.2.1, 4.9.1.1.6, and 4.9.11 of the > Baseline Requirements, REPLACE the words "Fully Qualified Domain Name" and > "FQDN" with "Domain Name". > > B. In Section 1.6.1 of the Baseline Requirements, in the definition for > "Authorization Domain Name”, replace “FQDN” with “Domain Name” and change the > third sentence to utilize the term “Wildcard Domain Name” such that the > definition reads as follows: The Domain Name used to obtain authorization for > certificate issuance for a given Domain Name. The CA may use the Domain Name > returned from a DNS CNAME lookup as the Domain Name for the purposes of > domain validation. If the Domain Name is a Wildcard Domain Name, then the CA > MUST remove “*.” from the left most portion of the requested Domain Name. The > CA may prune zero or more labels from left to right until encountering a Base > Domain Name and may use any one of the intermediate values for the purpose of > domain validation. > > C. In Section 1.6.1 of the Baseline Requirements, INSERT the following > definition: "Domain Label: A label of a Domain Name, as defined in RFC 5890 > section 2.2; for example, the Domain Name "www.example.com > <http://www.example.com/>" is composed of three labels: "www", "example", and > "com”. " > > D. In Section 1.6.1 of the Baseline Requirements, REPLACE the definition for > "Domain Name" with the following: A string which is a ‘domain name’, as > defined in RFC 5890 section 2.2, with Domain Labels separated by dots, or a > Wildcard Domain Name. For example “www.example.com > <http://www.example.com/>” and “*.example.net <http://example.net/>” are > Domain Names. > > E. In Section 1.6.1 of the Baseline Requirements, DO NOT CHANGE the > definition for "Fully-Qualified Domain Name” > > F. In Section 1.6.1 of the Baseline Requirements, REPLACE the definition for > "Reserved IP Address" with the following: An IPv4 or IPv6 address that the > IANA has "False" for Globally Reachable in either of the IANA Special-Purpose > IP Address Registries: > > https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml > > <https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml> > or > > https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml > > <https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml> > G. In Section 1.6.1 of the Baseline Requirements, REPLACE the definition for > "Wildcard Certificate" with the following: A Certificate containing a > Wildcard Domain Name in any of the Subject Alternative Names in the > Certificate. > > H. In Section 1.6.1 of the Baseline Requirements, INSERT the following > definition: "Wildcard Domain Name: A string starting with "*." (U+002A > ASTERISK, U+002E FULL STOP) immediately followed by a Fully-Qualified Domain > Name." > > I. In Section 2.2 of the Baseline Requirements, INSERT the word "requested" > in the fourth sentence between the words "processing CAA records for" and > "Domain Names" so that it reads, "processing CAA records for requested Domain > Names". > > J. In the second paragraph of Section 3.2.2.4 of the Baseline Requirements, > replace the first instance of “Full Qualified Domain Name (FQDN)” with > “Domain Name” such that it reads, "The CA SHALL confirm that, as of the date > the Certificate issues, the CA has validated each Domain Name listed in the > Certificate using at least one of the methods listed below, or is within the > Domain Namespace of a Fully Qualified Domain Name (FQDN) that has been > validated using at least one of the methods listed below (not including the > method defined in section 3.2.2.4.8)." > > K. REPLACE Section 3.2.2.6 of the Baseline Requirements in its entirety with: > > 3.2.2.6. Additional Validation for Wildcard Certificates > > Before issuing a Wildcard Certificate, the CA MUST establish and follow a > documented procedure[^pubsuffix] that determines if the FQDN portion of any > Wildcard Domain Name in the certificate is “registry-controlled” or is a > “public suffix” (e.g. “*.com”, “*.co.uk <http://co.uk/>”, see RFC 6454 > Section 8.2 for further explanation). > > If the FQDN portion of any Wildcard Domain Name in the certificate is > "registry-controlled" or is a "public suffix", CAs MUST refuse issuance > unless the applicant proves its rightful control of the entire Domain > Namespace. (e.g. CAs MUST NOT issue "*.co.uk <http://co.uk/>" or "*.local", > but MAY issue "*.example.com <http://example.com/>" to Example Co.). > > [^pubsuffix] Determination of what is “registry-controlled” versus the > registerable portion of a Country Code Top-Level Domain Namespace is not > standardized at the time of writing and is not a property of the DNS itself. > Current best practice is to consult a “public suffix list” such as > http://publicsuffix.org/ <http://publicsuffix.org/> (PSL), and to retrieve a > fresh copy regularly. If using the PSL, a CA SHOULD consult the "ICANN > DOMAINS" section only, not the "PRIVATE DOMAINS" section. The PSL is updated > regularly to contain new gTLDs delegated by ICANN, which are listed in the > "ICANN DOMAINS" section. A CA is not prohibited from issuing a Wildcard > Certificate to the Registrant of an entire gTLD, provided that control of the > entire namespace is demonstrated in an appropriate way. > > L. REPLACE Section 7.1.4.2.1 of the Baseline Requirements in its entirety > with: > > 7.1.4.2.1 Subject Alternative Name Extension > > Certificate Field: extensions:subjectAltName > > Required/Optional: Required > > Contents: This extension MUST contain at least one entry. Each entry MUST be > one of the following types: > > 1. dNSName: the entry MUST contain either a Fully-Qualified Domain Name or > Wildcard Domain Name that the CA has validated in accordance with section > 3.2.2.4. FQDNs and the FQDN portion of Wildcard DNs must comply with RFC 5280 > section 4.2.1.6 with the following exception: underscore characters ("_") are > allowed in Domain Labels such that replacing all underscore characters with > hyphen characters ("-") would result in a valid Domain Label. CAs MUST NOT > include Domain Labels which have hyphens as the third and fourth characters > unless the first character is "x" or "X", the second character is "n" or "N", > and the fifth and later characters are a valid Punycode string. CAs MUST > additionally validate that Wildcard DNs are consistent with section 3.2.2.6. > The entry MUST NOT contain an Internal Name. > > 2. iPAddress: the entry MUST contain an IP address that the CA has validated > in accordance with Section 3.2.2.5. The entry MUST NOT contain a Reserved IP > Address. > > M. REPLACE subsection a. of Section 7.1.4.2.2 of the Baseline Requirements > with: > > a. Certificate Field: subject:commonName (OID 2.5.4.3) > > Required/Optional: Deprecated (Discouraged, but not prohibited) > > Contents: If present, this field MUST contain a single IP address or Domain > Name that is one of the values contained in the Certificate’s subjectAltName > extension (see Section 7.1.4.2.1). When including a Domain Name in a common > name, CAs MUST only use LDH labels as defined in RFC 5890 and MUST NOT use > U-labels. When including an IPv6 address in a common name, CAs MUST use a > format conforming to Section 4 or Section 5 of RFC 5952. When including an > IPv4 address in a common name, CAs MUST encode the name as an IPv4Address as > defined in RFC 3986. > > --Motion Ends-- > > The procedure for approval of this Final Maintenance Guideline ballot is as > follows (exact start and end times may be adjusted to comply with applicable > Bylaws and IPR Agreement): > > BALLOT 202 Status: Final Maintenance Guideline Start time (22:00 UTC) End > time (22:00 UTC) > > Discussion (7 to 14 days) July 12, 2017 to July 19, 2017 > > Vote for approval (7 days) July 19, 2017 to July 26, 2017 > > If a vote of the Forum approves this ballot, the Chair will initiate a 30-day > IPR Review Period by sending out an IPR Review Notice. > > After 30 days of announcing the IPR Review period by the Chair: > > (a) If Exclusion Notice(s) are filed, this ballot approval is rescinded and a > PAG will be created; or (b) If no Exclusion Notices are filed, this ballot > becomes effective at end of the IPR Review Period. > > From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final > Maintenance Guideline, such ballot will include a redline or comparison > showing the set of changes from the Final Guideline section(s) intended to > become a Final Maintenance Guideline, and need not include a copy of the full > set of guidelines. Such redline or comparison shall be made against the Final > Guideline section(s) as they exist at the time a ballot is proposed, and need > not take into consideration other ballots that may be proposed subsequently, > except as provided in Bylaw Section 2.3(j). > > Votes must be cast by posting an on-list reply to this thread on the Public > list. A vote in favor of the motion must indicate a clear 'yes' in the > response. A vote against must indicate a clear 'no' in the response. A vote > to abstain must indicate a clear 'abstain' in the response. Unclear responses > will not be counted. The latest vote received from any representative of a > voting member before the close of the voting period will be counted. Voting > members are listed here: https://cabforum.org/members/ > <https://cabforum.org/members/> > In order for the motion to be adopted, two thirds or more of the votes cast > by members in the CA category and greater than 50% of the votes cast by > members in the browser category must be in favor. Quorum is half of the > number of currently active Members, which is the average number of Member > organizations that have participated in the previous three Forum-wide > meetings (both teleconferences and face-to-face meetings). Under Bylaw > 2.2(g), at least the required quorum number must participate in the ballot > for the ballot to be valid, either by voting in favor, voting against, or > abstaining. > > > <Ballot 202.pdf>_______________________________________________ > Public mailing list > [email protected] <mailto:[email protected]> > https://cabforum.org/mailman/listinfo/public > <https://cabforum.org/mailman/listinfo/public> > > > <CA-Browser Forum BR 1.5.0 Ballot 202 draft.pdf>
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
