<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=windows-1251"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
p.line867, li.line867, div.line867
{mso-style-name:line867;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.line874, li.line874, div.line874
{mso-style-name:line874;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.line862, li.line862, div.line862
{mso-style-name:line862;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=line867><strong>Ballot 92 - Implications of RFC 6125 and Subject Alternative Names</strong> <o:p></o:p></p><p class=line874>Steve Roylance made the following motion and Robin Alden and Jeremy Rowley endorsed it: <o:p></o:p></p><p class=line874>... Motion begins... <o:p></o:p></p><p class=line874>Effective immediately <o:p></o:p></p><p class=line874>... Erratum begins ... <o:p></o:p></p><p class=line874>The following sections will be amended in the Baseline Requirements document. <o:p></o:p></p><p class=line867><strong>INSERT</strong> in Section 4. Definitions the following: <o:p></o:p></p><p class=line874>Public IP Address: An IP Address that is not a Reserved IP Address. <o:p></o:p></p><p class=line874>Root Domain Name: A registry-controlled or public suffix and the label immediately to its left. <o:p></o:p></p><p class=line862>U-label: As defined in RFC 5890 (<a href="http://tools.ietf.org/html/rfc5890#section-2.3.2.1">http://tools.ietf.org/html/rfc5890#section-2.3.2.1</a>) <o:p></o:p></p><p class=line867><strong>REPLACE</strong> Section 9.2.1 (Subject Alternative Name Extension) with the following: <o:p></o:p></p><p class=line874>9.2.1 Subject Alternative Name Extension <o:p></o:p></p><p class=line874>Certificate Field: extensions:subjectAltName <o:p></o:p></p><p class=line874>Required/Optional: Required <o:p></o:p></p><p class=line874>Contents: This extension MUST contain at least one entry that is either a Fully-Qualified Domain Name or Public IP Address. Each subjectAltName entry MUST be a Domain Name or IP Address. The CA MUST confirm the Applicant’s control of each dNSName or Public IP Address entry in accordance with Section 11.1. <o:p></o:p></p><p class=line867>SubjectAltName entries MAY include domain Names containing wildcard characters. <o:p></o:p></p><p class=line874>A Certificate MUST contain Subject Identity Information verified in accordance with Section 9.2.4 if any subjectAltName entry is: <o:p></o:p></p><p class=line874>1) a Public IP Address, <o:p></o:p></p><p class=line874>2) a Domain Name containing a Root Domain Name which is different from the Root Domain Name of any other Domain Name included within the subjectAltName extension, or <o:p></o:p></p><p class=line874>3) a Reserved IP Address or Internal Server Name. <o:p></o:p></p><p class=line874>If all subjectAltName entries contain the same Root Domain Name, the CA MAY omit the Subject Identity Information. For example, the entries of:- www.domain.com, domain.com, example.domain.com, *.level.domain.com all contain the same Root Domain Name and a corresponding certificate MAY omit the Subject Identity Information. However, adding domain.co.uk will cause the certificate to include multiple Root Domains and require inclusion of Subject Identity Information. <o:p></o:p></p><p class=line874>Prior to issuing a Certificate containing an Internal Server Name or Reserved IP Address, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. As of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 if the subjectAlternativeName contains a Reserved IP Address or Internal Server Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Server Name. <o:p></o:p></p><p class=line867><strong>REPLACE</strong> Section 9.2.2 (Subject Common Name Field) with the following: <o:p></o:p></p><p class=line874>9.2.2 Subject Common Name Field <o:p></o:p></p><p class=line874>Certificate Field: subject:commonName (OID 2.5.4.3) <o:p></o:p></p><p class=line874>Required/Optional: Deprecated (Discouraged, but not prohibited) <o:p></o:p></p><p class=line874>Contents: If present, this field MUST contain a single Public IP address or single Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension (see Section 9.2.1). Reserved IP Addresses and Internal Server Names are prohibited. <o:p></o:p></p><p class=line867><strong>INSERT</strong> at the end of Section 9.2.7 (Other Subject Attributes) the following new language: <o:p></o:p></p><p class=line874>All label components in a Fully-Qualified Domain Name as part of a Subject Alternative Name of type dNSName or Subject commonName attribute that are not part of the registry-assigned name (e.g. the “foo”, “bar”, and “baz” labels of “foo.bar.baz.example.com”) must meet the following guidelines: <o:p></o:p></p><p class=line862>1. Hostname labels SHALL be valid according to either RFC3490 rules for Internationalized Domain Names. (IDNA 2003) [<a href="http://tools.ietf.org/html/rfc3490">http://tools.ietf.org/html/rfc3490</a>] or RFC5890 rules for Internationalized Domain Names (IDNA 2008) [<a href="http://tools.ietf.org/html/rfc5890">http://tools.ietf.org/html/rfc5890</a>]. <o:p></o:p></p><p class=line862>2. Hostname U-label components SHALL follow the “Moderately Restrictive” behavior described by Unicode Technical Standard #39, “UNICODE SECURITY MECHANISMS” [<a href="http://www.unicode.org/reports/tr39/#Restriction_Level_Detection">http://www.unicode.org/reports/tr39/#Restriction_Level_Detection</a>]. <o:p></o:p></p><p class=line862>3. Hostname U-label components SHALL NOT include confusable bidirectional text. [<a href="http://unicode.org/reports/tr36/#Bidirectional_Text_Spoofing">http://unicode.org/reports/tr36/#Bidirectional_Text_Spoofing</a>] and [<a href="http://www.ietf.org/rfc/rfc3987.txt">http://www.ietf.org/rfc/rfc3987.txt</a>] <o:p></o:p></p><p class=line874>a. Hostname label components SHALL NOT include left-to-right override characters, U+200E, U+202E. <o:p></o:p></p><p class=line874>b. Hostname label components SHALL NOT include both left-to-right and right-to-left characters. <o:p></o:p></p><p class=line874>c. Hostname label components using a right-to-left character must start and end with right-to-left characters, with the exception that labels using right-to-left characters may end with combining marks or numbers. <o:p></o:p></p><p class=line867><strong>REPLACE</strong> Section 10.2.3 (Information Requirements) with the following: <o:p></o:p></p><p class=line874>10.2.3 Information Requirements <o:p></o:p></p><p class=line874>The certificate request MAY include all factual information about the Applicant to be included in the Certificate, and such additional information as is necessary for the CA to obtain from the Applicant in order to comply with these Requirements and the CA’s Certificate Policy and/or Certification Practice Statement. In cases where the certificate request does not contain all the necessary information about the Applicant, the CA SHALL obtain the remaining information from the Applicant or, having obtained it from a reliable, independent, third-party data source, confirm it with the Applicant. <o:p></o:p></p><p class=line874>Applicant information MUST include, but not be limited to, at least one Subject Alternative Extension Name as defined in Section 9.2.1. <o:p></o:p></p><p class=line867><strong>INSERT</strong> in Section 11.1 (Authorization by Domain Name Registrant) the following two new sections: <o:p></o:p></p><p class=line874>11.1.3 Wildcard Domain Validation <o:p></o:p></p><p class=line874>Before issuing a certificate with a wildcard character (*) in a CN or subjectAltName of type DNS-ID, the CA MUST establish and follow a documented procedure† that determines if the wildcard character occurs in the first label position to the left of a “registry-controlled” label or “public suffix”. (e.g. “*.com”, “*.co.uk”, see RFC 6454 Section 8.2 for further explanation.) <o:p></o:p></p><p class=line874>If a wildcard would fall within the label immediately to the left of a registry-controlled or public suffix, CAs SHALL refuse issuance unless the applicant can prove its rightful control of the entire segment of the DNS space. (e.g. CAs SHALL NOT issue “*.co.uk”, but MAY issue “*.appspot.com” to Google, Inc.) <o:p></o:p></p><p class=line862>†Determination of what suffixes are “registry-controlled” 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 <a href="http://publicsuffix.org/">http://publicsuffix.org/</a>. If the process for making this determination is standardized by a future Internet Draft, such a procedure SHOULD be preferred. <o:p></o:p></p><p class=line874>11.1.4 New gTLD Domains <o:p></o:p></p><p class=line874>ICANN will begin the process of issuing new generic Top Level Domains (gTLDs) beginning in 2012, therefore certain Certificates for non-public names will need to be revoked on an accelerated schedule. CAs SHALL review the proposed new gTLDs and compare them against their records for issued certificates. Where the locally-qualified subject or subject alternative name of a previously issued Certificate would be a valid FQDN under a new gTLD, the CA SHALL re-verify that the Subscriber is the Domain Name Registrant or the Applicant has control over the FQDN in accordance with Section 11 of this document. If the CA cannot verify the customer’s right to use, or control of, the Fully-Qualified Domain Name(s) in the Certificate, the CA SHALL notify the Customer that: <o:p></o:p></p><p class=line874>1. The subscriber must take action to prevent the Certificate from being presented in response to any requests originating from the public Internet following the ability to publicly resolve in the DNS a new gTLD. <o:p></o:p></p><p class=line874>2. The Certificate will be revoked no later than 6 months following the ability to publicly resolve in the DNS a new gTLD if the Subscriber cannot prove their right to use or control of the FQDN. <o:p></o:p></p><p class=line874>The CA SHALL revoke the certificate no later than 6 months following the ability to publicly resolve in the DNS a new gTLD if the Subscriber fails to prove their right to use or control of the FQDN. <o:p></o:p></p><p class=line874>Should any such certificate be found to be visible from the public Internet after the new gTLD is operational, the issuing CA SHALL immediately revoke all such certificates for the subscriber. <o:p></o:p></p><p class=line874>... Erratum ends ... <o:p></o:p></p><p class=line874>The review period for this ballot shall commence at 21:00 UTC on 17 October 2012 and will close at 21:00 UTC on 24 October 2012. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 21:00 UTC on 31 October 2012. Votes must be cast by posting an on-list reply to this thread. <o:p></o:p></p><p class=line874>... Motions ends ... <o:p></o:p></p><p class=line874>A vote in favor of the motion must indicate a clear 'yes' in the response. <o:p></o:p></p><p class=line874>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. <o:p></o:p></p><p class=line862>Voting members are listed here: <a href="http://www.cabforum.org/forum.html">http://www.cabforum.org/forum.html</a> <o:p></o:p></p><p class=line874>In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and one half or more of the votes cast by members in the browser category must be in favor. Also, at least six members must participate in the ballot, either by voting in favor, voting against or abstaining.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>