<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 15, 2017 at 2:26 PM, Gervase Markham <span dir="ltr"><<a href="mailto:gerv@mozilla.org" target="_blank">gerv@mozilla.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 15/11/17 10:00, Ryan Sleevi wrote:<br>
> Could you clarify what you view "enabling SRVNames" as?<br>
><br>
> - Browsers/client software: In supporting them<br>
> - The CA/Browser Forum: In dictating validation rules<br>
<br>
</span>This one...<br>
<span class=""><br>
> - (Unconstrained) CAs: In issuing them<br>
> - TCSCs: In issuing them<br>
<br>
</span>...which allows these two. Without issuance, it seems unlikely client<br>
software will support.<br></blockquote><div><br></div><div>I would actually suggest the inverse - without client desire/support with appropriate protections, then allowing issuance seems like it will further salt-the-field and prevent SRVnames from being safely deployed in the future.</div><div><br></div><div>As it stands today:</div><div>TCSCs can issue SRVNames in violation of the BRs, but that's "ok" because no one trusts them <br></div><div><br></div><div>As it would stand with Peter's proposals:</div><div>TCSCs can issue SRVNames in violation of the BRs, but as long as no one trusts SRVNames, that's "ok"</div><div><br></div><div><br></div><div>However, it would seem unwise for any browser software (or any software, for that matter) to support SRVNames under either scheme, because of the risk posed by TCSCs having global issuance capability, and no appropriate supervision.</div><div><br></div><div>So one option is require that TCSCs include SRVNames - and that requires revoking all existing TCSCs and issuign new ones with new constraints. That's... unappealing. For everyone.</div><div>Another option is to introduce some further signal to indicate that 'this' SRVName is safe to trust. This was the proposal I sketched out for you.</div><div>  - It means that existing software that supports SRVNames is unaffected (and, for the record, also arguably insecure)</div><div>  - It means that future software wanting to consider SRVName support can minimize the risk of TCSCs being unconstrained, and have some degree of assurance re: what the CA has issued</div><div><br></div><div>Can we add to the BRs SRVName validation? Absolutely.</div><div>Is it meaningful/sufficiently secure without addressing the TCSC loophole? Nope</div><div>Should client software support w/o addressing that loophole? Heck no.</div></div></div></div>