On Jul 19, 2017, at 3:34 PM, Ben Wilson via Public
<[email protected] <mailto:[email protected]>> wrote:
DigiCert votes “Yes”
*From:*Public [mailto:[email protected]]*On Behalf Of*Ben
Wilson via Public
*Sent:*Wednesday, July 19, 2017 4:34 PM
*To:*Peter Bowen <[email protected] <mailto:[email protected]>>; CA/Browser
Forum Public Discussion List <[email protected]
<mailto:[email protected]>>; Ryan Sleevi <[email protected]
<mailto:[email protected]>>
*Subject:*Re: [cabfpub] Ballot 202 - Underscore and Wildcard Characters
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] v
<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
theDomain Namereturned 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 oftherequested 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 aDomainName,
as defined in RFC 5890 section 2.2; for example, theDomainName
"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,
withDomain 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
CHANGEthe 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.xhtmlor
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
ashttp://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/
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
_______________________________________________
Public mailing list
[email protected] <mailto:[email protected]>
https://cabforum.org/mailman/listinfo/public
