<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 8, 2016 at 9:44 PM, Peter Bowen <span dir="ltr"><<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><div>You are correct that 7.1.5 needs updating, as a (d) needs to be added that starts “For each SRVName in permittedSubtrees …”.  That being said, the sentence I proposed above references “named constrained” CAs not “technically constrained” CAs.  My intent was to say that any CA that has dNSName constraints but does not have SRVName constraints (which is likely almost all current name constrained CAs) does not have carte blanche to issue certificates with SRVNames but can do so for subtrees they are already allowed.<br></div></span></div></blockquote><div><br></div><div>What will clients do? My understanding is that clients won't name-constrain SRVNames to the dNSName constraints, so as a practical matter, a technically constrained subCA would be able to issue arbitrary SRVNames.</div><div><br></div><div>Certainly, of the APIs represented by the vendors in the Forum, it would be problematic to implement this support correctly in the application layer, due to the lack of influence in the path building API.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I think there are three options for when NC do not include SRVName constraints: 1) As above, they can include SRVNames only where the Name portion is allowed as a dNSName or 2) forbid them from issuing unless at SRVName is present in at least on of the constraint subtrees or 3) the CA is allowed to issue anything.  Do you think it would be better to forbid existing name constrained CAs from including SRVNames in certificates?</div></div></blockquote><div><br></div><div>That's where I lean, yes.</div><div><br></div><div>This is the admitted downside to technically constrained sub-CAs (and, in general, the nameConstraints extension), in that every existing certificate has carte blanche, from a client PKI perspective, to issue whatever they want for the new name.</div><div><br></div><div>I suppose one solution would be if clients rejected a name type if it appeared in a SAN but did not appear in permittedSubtrees, but for which permittedSubtrees was present, but... </div></div><br></div></div>