Thanks Ben!
In the Domain Name definition, I forgot to send you a second sentence:
"Fully-Qualified Domain Names and Wildcard Domain Names are Domain Names.”
So D. would read: 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 ("."). Fully-Qualified
Domain Names and Wildcard Domain Names are Domain Names.”
This helps clarify that the term “Domain Name” means both FQDNs and Wildcard
DNs.
Thanks,
Peter
> On Jul 12, 2017, at 10:24 AM, Ben Wilson via Public <[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, 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://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 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 <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>
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
