<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">Bonsoir,</div>
<div class=""><br class="">
</div>
<div class="">I’m opposed to the underscore character for DNS host names, either in SAN:dNSName or in this SAN:otherName(SRVName):Name. The underscore set in SRVName has precisely been added to avoid collisions with DNS host names. This non collision is extremely
 important for NameConstraints to work with SRVName.</div>
<div class=""><br class="">
</div>
<div class="">Since this ballot adds another name type, it has an impact on the definition of a technically constrained CA (section 7.1.5), not reflected here.</div>
<div class="">At a minimum, add an item (d) in section 7.1.5:</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">
<div class="">(d) For each otherName of type SRVName in permittedSubtrees, , the CA MUST confirm that the Applicant has registered the Name or has been authorized by the domain registrant to act on the registrant’s behalf in line with the verification practices
 of section 3.2.2.4.</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">and change the phrase </div>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><span class="">If the Subordinate CA Certificate includes the id‐kp‐serverAuth extended key usage, then the Subordinate CA Certificate MUST include the Name Constraints X.509v3 extension
 with constraints on dNSName, iPAddress and DirectoryName as follows:‐</span></blockquote>
<div class=""><span class="">to</span></div>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><span class="">If the Subordinate CA Certificate includes the id‐kp‐serverAuth extended key usage, then the Subordinate CA Certificate MUST include the Name Constraints X.509v3 extension
 with constraints on dNSName, iPAddress, DirectoryName, and otherName of type SRVName as follows:‐ </span></blockquote>
<span class=""><br class="">
Should we also add specific requirements when such a CA is not allowed to issue certificates with an otherName of type SRVName, as it was defined for iPAddress and dNSName (setting these types in the excludedSubtrees portion of NC)?</span>
<div class=""><br class="">
</div>
<div class="">Reading RFC4985, it’s impossible to have an empty SRVName (the ASN.1 definition forbids it). The logic described in section 4 doesn’t consider the case where both Name and Service are absent. We could specify that a CA not allowed to issue otherName:SRVName
 certificates must have a single « . » in this entry, but I’m not sure the logic described in section 4 is ok with this.</div>
<div class=""><br class="">
<div class=""><span class="">
<div class="">Cordialement,<br class="">
Erwann Abalea<br class="">
</div>
<br class="">
<blockquote type="cite" class="">Le 10 juin 2016 à 19:28, Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" class="">jeremy.rowley@digicert.com</a>> a écrit :<br class="">
<br class="">
Looking for two endorsers for the following ballot:<br class="">
 <br class="">
The following motion has been proposed by Jeremy Rowley, from DigiCert, and endorsed by ____________________:<br class="">
 <br class="">
-- MOTION BEGINS –<br class="">
 <br class="">
Effective immediately, the follow changes are made to the Baseline Requirements:<br class="">
 <br class="">
A)    Section 4.2.2 of the Baseline Requirements is replaced with “No Stipulation”<br class="">
 <br class="">
B)    Add the following definition to Section 1.6.1: <br class="">
Wildcard Domain Name: A Domain Name formed by prepending '*.' to a FQDN.<br class="">
 <br class="">
C)    Section 7.1.4.2.1 is amended as follows: <br class="">
Certificate Field: extensions:subjectAltName <br class="">
Required/Optional: Required <br class="">
Contents: This extension MUST contain at least one entry. Each entry MUST be either a dNSName containing the Fully‐Qualified Domain Name, Wildcard Domain Name, or an iPAddress containing the IP address of a server, or an otherName of type SRVName as defined
 in RFC4985. An entry MUST NOT be an Internal name or Reserved IP Address. The CA MUST confirm the entry as follows:<br class="">
a)      For a Fully‐Qualified Domain Name or Wildcard Domain Name entry, the CA MUST verify the entry in accordance with Section 3.2.2.4;<br class="">
b)     For a SRVName entry, the CA MUST verify the Name portion of the entry in accordance with Section 3.2.2.4; and <br class="">
c)      For an IP address entry, the CA MUST verify the entry in accordance with Section 3.2.2.5 or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. Wildcard FQDNs are permitted.<br class="">
As exceptions to RFC5280 and X.509, dNSName entries MAY contain Wildcard Domain Names, and FQDNs and Wildcard Domain Names MAY contain the underscore character ("_") in any location where the hyphen character ("-") is allowed. SRVName entries MUST NOT contain
 Wildcard Domain Names.<br class="">
<br class="">
If a name constrained CA has a dNSName constraint but does not have a constraint for SRVNames, the CA MUST NOT issue certificates containing SRVNames.<br class="">
 <br class="">
As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, 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. Also as of the Effective Date, the CAs SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName
 extension or Subject commonName field containing a Reserved IP Address or Internal 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 Name. Effective May 1, 2015, each CA SHALL revoke all unexpired Certificates with an Internal Name using onion as the right‐most label in an entry in the subjectAltName Extension or commonName field unless such Certificate was issued in accordance
 with Appendix F of the EV Guidelines.<br class="">
 <br class="">
---- END BALLOT ----<br class="">
 <br class="">
 <br class="">
 <br class="">
_______________________________________________<br class="">
Public mailing list<br class="">
<a href="mailto:Public@cabforum.org" class="">Public@cabforum.org</a><br class="">
https://cabforum.org/mailman/listinfo/public<br class="">
</blockquote>
<br class="">
</span></div>
</div>
</body>
</html>