[cabfpub] Ballot 202 - Underscore and Wildcard Characters

Dean Coclin Dean_Coclin at symantec.com
Fri Jul 21 11:04:36 MST 2017


Symantec votes YES on Ballot 202.

Dean Coclin

-----Original Message-----
From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Rob Stradling via Public
Sent: Thursday, July 20, 2017 5:55 PM
To: public at cabforum.org
Subject: Re: [cabfpub] Ballot 202 - Underscore and Wildcard Characters

Comodo votes Yes.

On 19/07/17 23:39, Peter Bowen via Public wrote:
> Amazon votes Yes.
> 
>> On Jul 19, 2017, at 3:34 PM, Ben Wilson via Public 
>> <public at cabforum.org <mailto:public at cabforum.org>> wrote:
>>
>> DigiCert votes “Yes”
>> *From:*Public [mailto:public-bounces at cabforum.org]*On Behalf Of*Ben 
>> Wilson via Public *Sent:*Wednesday, July 19, 2017 4:34 PM *To:*Peter 
>> Bowen <pzb at amzn.com <mailto:pzb at amzn.com>>; CA/Browser Forum Public 
>> Discussion List <public at cabforum.org <mailto:public at cabforum.org>>; 
>> Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com>>
>> *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 <pzb at amzn.com 
>> <mailto:pzb at amzn.com>> 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 <pzb at amzn.como v
>>     <mailto:pzb at amzn.com>> 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
>>         <public at cabforum.org <mailto:public at cabforum.org>> 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
>>         ashttps://clicktime.symantec.com/a/1/NdY1c7PMg3zhLCTnp4Aq76rPjifgv2JCXEXnEU8QmWo=?d=Nh9QyZqndsbi8b0G4DEDxgT00U6MjqmsmAc8GRLhMeeaC1ejEiBiDBMcJuzg2_mc1CaqNB6ZL_D6EiPD6XIHXX2F4QfyOrhbd4h30voNw-GZ-o5aL5axtVy5CZvINtCekI3MSBymKY-jKr9vXxC7dTLlbHZBhxZ--nufPEXr6e8lUCJnQSCZekitLUHnVnNRgpdC9-0VpGjKyj0_hYQ8-wDWgrJKt7DqAHIsuH_2ORXhhIs1CE-ddfPOZmkj2BV8Sfbu0gzT9oRxy777uEpZQlpe31E3hYlq3ba5UxpX7HPotgnWux6696S2AjEvseT3xDiph003gcYMIpvKQ7au03PsTjDpVjkpp900infdVQ5I4vC8h71FX5QmoS9AEa-WK3uZXc03etg5rngdN0Sra6BrehMkdWt2cqeTYHqo&u=http%3A%2F%2Fpublicsuffix.org%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://clicktime.symantec.com/a/1/Epx1gy85jc6fILw3p4kaq4-L9z1n2
>> MUGSt_u7W_gIeM=?d=Nh9QyZqndsbi8b0G4DEDxgT00U6MjqmsmAc8GRLhMeeaC1ejEiB
>> iDBMcJuzg2_mc1CaqNB6ZL_D6EiPD6XIHXX2F4QfyOrhbd4h30voNw-GZ-o5aL5axtVy5
>> CZvINtCekI3MSBymKY-jKr9vXxC7dTLlbHZBhxZ--nufPEXr6e8lUCJnQSCZekitLUHnV
>> nNRgpdC9-0VpGjKyj0_hYQ8-wDWgrJKt7DqAHIsuH_2ORXhhIs1CE-ddfPOZmkj2BV8Sf
>> bu0gzT9oRxy777uEpZQlpe31E3hYlq3ba5UxpX7HPotgnWux6696S2AjEvseT3xDiph00
>> 3gcYMIpvKQ7au03PsTjDpVjkpp900infdVQ5I4vC8h71FX5QmoS9AEa-WK3uZXc03etg5
>> rngdN0Sra6BrehMkdWt2cqeTYHqo&u=https%3A%2F%2Fcabforum.org%2Fmembers%2
>> F
>>
>>         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
>>         Public at cabforum.org <mailto:Public at cabforum.org>
>>         
>> https://clicktime.symantec.com/a/1/yzTDlvzToc9ltiD9L3vpjfsy_HKBWxlffd
>> n9ZKv3JEM=?d=Nh9QyZqndsbi8b0G4DEDxgT00U6MjqmsmAc8GRLhMeeaC1ejEiBiDBMc
>> Juzg2_mc1CaqNB6ZL_D6EiPD6XIHXX2F4QfyOrhbd4h30voNw-GZ-o5aL5axtVy5CZvIN
>> tCekI3MSBymKY-jKr9vXxC7dTLlbHZBhxZ--nufPEXr6e8lUCJnQSCZekitLUHnVnNRgp
>> dC9-0VpGjKyj0_hYQ8-wDWgrJKt7DqAHIsuH_2ORXhhIs1CE-ddfPOZmkj2BV8Sfbu0gz
>> T9oRxy777uEpZQlpe31E3hYlq3ba5UxpX7HPotgnWux6696S2AjEvseT3xDiph003gcYM
>> IpvKQ7au03PsTjDpVjkpp900infdVQ5I4vC8h71FX5QmoS9AEa-WK3uZXc03etg5rngdN
>> 0Sra6BrehMkdWt2cqeTYHqo&u=https%3A%2F%2Fcabforum.org%2Fmailman%2Flist
>> info%2Fpublic
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org <mailto:Public at cabforum.org> 
>> https://clicktime.symantec.com/a/1/yzTDlvzToc9ltiD9L3vpjfsy_HKBWxlffd
>> n9ZKv3JEM=?d=Nh9QyZqndsbi8b0G4DEDxgT00U6MjqmsmAc8GRLhMeeaC1ejEiBiDBMc
>> Juzg2_mc1CaqNB6ZL_D6EiPD6XIHXX2F4QfyOrhbd4h30voNw-GZ-o5aL5axtVy5CZvIN
>> tCekI3MSBymKY-jKr9vXxC7dTLlbHZBhxZ--nufPEXr6e8lUCJnQSCZekitLUHnVnNRgp
>> dC9-0VpGjKyj0_hYQ8-wDWgrJKt7DqAHIsuH_2ORXhhIs1CE-ddfPOZmkj2BV8Sfbu0gz
>> T9oRxy777uEpZQlpe31E3hYlq3ba5UxpX7HPotgnWux6696S2AjEvseT3xDiph003gcYM
>> IpvKQ7au03PsTjDpVjkpp900infdVQ5I4vC8h71FX5QmoS9AEa-WK3uZXc03etg5rngdN
>> 0Sra6BrehMkdWt2cqeTYHqo&u=https%3A%2F%2Fcabforum.org%2Fmailman%2Flist
>> info%2Fpublic
> 
> 
> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://clicktime.symantec.com/a/1/yzTDlvzToc9ltiD9L3vpjfsy_HKBWxlffdn
> 9ZKv3JEM=?d=Nh9QyZqndsbi8b0G4DEDxgT00U6MjqmsmAc8GRLhMeeaC1ejEiBiDBMcJu
> zg2_mc1CaqNB6ZL_D6EiPD6XIHXX2F4QfyOrhbd4h30voNw-GZ-o5aL5axtVy5CZvINtCe
> kI3MSBymKY-jKr9vXxC7dTLlbHZBhxZ--nufPEXr6e8lUCJnQSCZekitLUHnVnNRgpdC9-
> 0VpGjKyj0_hYQ8-wDWgrJKt7DqAHIsuH_2ORXhhIs1CE-ddfPOZmkj2BV8Sfbu0gzT9oRx
> y777uEpZQlpe31E3hYlq3ba5UxpX7HPotgnWux6696S2AjEvseT3xDiph003gcYMIpvKQ7
> au03PsTjDpVjkpp900infdVQ5I4vC8h71FX5QmoS9AEa-WK3uZXc03etg5rngdN0Sra6Br
> ehMkdWt2cqeTYHqo&u=https%3A%2F%2Fcabforum.org%2Fmailman%2Flistinfo%2Fp
> ublic
> 

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690 Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.  If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software.
_______________________________________________
Public mailing list
Public at cabforum.org
https://clicktime.symantec.com/a/1/yzTDlvzToc9ltiD9L3vpjfsy_HKBWxlffdn9ZKv3JEM=?d=Nh9QyZqndsbi8b0G4DEDxgT00U6MjqmsmAc8GRLhMeeaC1ejEiBiDBMcJuzg2_mc1CaqNB6ZL_D6EiPD6XIHXX2F4QfyOrhbd4h30voNw-GZ-o5aL5axtVy5CZvINtCekI3MSBymKY-jKr9vXxC7dTLlbHZBhxZ--nufPEXr6e8lUCJnQSCZekitLUHnVnNRgpdC9-0VpGjKyj0_hYQ8-wDWgrJKt7DqAHIsuH_2ORXhhIs1CE-ddfPOZmkj2BV8Sfbu0gzT9oRxy777uEpZQlpe31E3hYlq3ba5UxpX7HPotgnWux6696S2AjEvseT3xDiph003gcYMIpvKQ7au03PsTjDpVjkpp900infdVQ5I4vC8h71FX5QmoS9AEa-WK3uZXc03etg5rngdN0Sra6BrehMkdWt2cqeTYHqo&u=https%3A%2F%2Fcabforum.org%2Fmailman%2Flistinfo%2Fpublic


More information about the Public mailing list