<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 10, 2016 at 12:02 PM, Erwann Abalea <span dir="ltr"><<a href="mailto:Erwann.Abalea@docusign.com">Erwann.Abalea@docusign.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">



<div style="word-wrap:break-word">
<div>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.<br></div>
<div>At a minimum, add an item (d) in section 7.1.5:</div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">
<div>(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><br>
</div>
<div>and change the phrase </div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><span>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><span>to</span></div>
<blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><span>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></div></blockquote><div><br></div><div>Erwann, the rationale for this decision was covered the previous time this ballot was discussed. </div><div><br></div><div>See my reply <a href="https://cabforum.org/pipermail/public/2016-April/007211.html">https://cabforum.org/pipermail/public/2016-April/007211.html</a> , Peter's follow-up, and mine, and see if that provides sufficient context.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><span>
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><br>
</div>
<div>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></blockquote><div><br></div><div>I'm not sure the answers here, but thanks for bringing them  up, as I hadn't considered fully the implications for this aspect. </div></div><br></div></div>