QuoVadis votes YES to Ballot 202


Regards, Stephen Davidson

QuoVadis







From: Public <[email protected]<mailto:[email protected]>> 
on behalf of Ben Wilson via Public 
<[email protected]<mailto:[email protected]>>
Reply-To: Ben Wilson <[email protected]<mailto:[email protected]>>, 
CA/Browser Forum Public Discussion List 
<[email protected]<mailto:[email protected]>>
Date: Wednesday, 12 July, 2017 at 13:24
To: CABFPub <[email protected]<mailto:[email protected]>>
Subject: [cabfpub] Ballot 202 - Underscore and Wildcard Characters



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, REPLACE the definition for 
"Authorization Domain Name" with the following: The Domain Name used to obtain 
authorization for certificate issuance for a given Domain Name. The CA may use 
the FQDN 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 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: An individual component of a Domain Name."

D. In Section 1.6.1 of the Baseline Requirements, REPLACE the definition for 
"Domain Name" with the following: A set of one or more Domain Labels, each 
separated by a single full stop character (".").

E. In Section 1.6.1 of the Baseline Requirements, REPLACE the definition for 
"Fully-Qualified Domain Name" with the following: A Domain Name that includes 
the Domain Labels of all superior nodes in the Internet Domain Name System.

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://scanmail.trustwave.com/?c=4062&d=3JT32YPtheum4NfcIBGzi8POvhKk4WRqKKtN0zOKbw&s=5&u=https%3a%2f%2fwww%2eiana%2eorg%2fassignments%2fiana-ipv4-special-registry%2fiana-ipv4-special-registry%2exhtml>
 or

https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml<https://scanmail.trustwave.com/?c=4062&d=3JT32YPtheum4NfcIBGzi8POvhKk4WRqKPtCgmCIbw&s=5&u=https%3a%2f%2fwww%2eiana%2eorg%2fassignments%2fiana-ipv6-special-registry%2fiana-ipv6-special-registry%2exhtml>

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 Domain Name consisting of a single 
asterisk character ("*") followed by a single full stop character (".") 
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. REPLACE the second paragraph of Section 3.2.2.4 of the Baseline Requirements 
so 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”, 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" or "*.local", but MAY issue "*.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://scanmail.trustwave.com/?c=4062&d=3JT32YPtheum4NfcIBGzi8POvhKk4WRqKKxC1mDcbQ&s=5&u=http%3a%2f%2fpublicsuffix%2eorg%2f>
 (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://scanmail.trustwave.com/?c=4062&d=3JT32YPtheum4NfcIBGzi8POvhKk4WRqKKtN2jbfaA&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmembers%2f>

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.



_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public

Reply via email to