<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 15, 2017, at 10:00 AM, Ryan Sleevi <<a href="mailto:sleevi@google.com" class="">sleevi@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Nov 15, 2017 at 12:55 PM, Peter Bowen <span dir="ltr" class=""><<a href="mailto:pzb@amzn.com" target="_blank" class="">pzb@amzn.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br class="">
<br class="">
> On Nov 15, 2017, at 9:46 AM, Gervase Markham via Public <<a href="mailto:public@cabforum.org" class="">public@cabforum.org</a>> wrote:<br class="">
><br class="">
> On 15/11/17 09:38, Ryan Sleevi wrote:<br class="">
>> I gave an option immediately preceding the text you snipped, along with<br class="">
>> the trade-offs such options come with.<br class="">
><br class="">
> So you are suggesting we don't enable SRVnames until someone has specced<br class="">
> such an extension and it's been implemented?<br class=""></span></blockquote><div class=""><br class=""></div><div class="">Could you clarify what you view "enabling SRVNames" as?</div><div class=""><br class=""></div><div class="">- Browsers/client software: In supporting them</div><div class="">- The CA/Browser Forum: In dictating validation rules</div><div class="">- (Unconstrained) CAs: In issuing them</div><div class="">- TCSCs: In issuing them</div></div></div></div></div></blockquote><div><br class=""></div><div>By “enabling SRVNames” I mean allowing unconstrained CAs to include them in certificates they sign.   We know that certain client software already support checking them, and the request here is not to have browsers check them.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Another option is to just forbid CAs with DNS name constraints from issuing SRVname certificates unless they have SRVname constraints defined as well.  That doesn’t change things compared to today — the only thing preventing them from issuing SRVname certificates is the BRs.<br class=""></blockquote><div class=""><br class=""></div><div class="">I'm not sure that's entirely an accurate picture.</div><div class=""><br class=""></div><div class="">That is, I think programs that use TCSCs to allow for less oversight would, effectively, be prohibited from supporting SRVNames without some degree that misissuance would not pose risk.</div><div class=""><br class=""></div><div class="">The approach you describe wouldn't actually mitigate that risk, so I don't think would reasonably achieve Gerv's goal of saying that they're adequately constrained.</div><div class=""><br class=""></div><div class="">It very much is a chicken-and-egg problem here.</div><div class=""><br class=""></div><div class="">Browsers cannot safely support SRVNames without having assurance about how those SRVNames are validated. Because they don't support them, this isn't an issue, but if they were, it would be.</div><div class="">So you need the CA/Browser Forum (or equivalent) to define an acceptable way of validating them. <br class=""></div><div class="">TCSCs exist, in part, because they limit the risk of improper validation. Thus, allowing a new type without adding it to the TCSC means the new type is at risk of improper validation.</div><div class="">There is not an easy way, due to RFC 5280, to add a new type without granting that capability to existing TCSCs, thus introducing risk (of improper validation).</div><div class=""><br class=""></div><div class="">I don't think your proposal mitigates any of that risk - it just says "that's misissuance", but doesn't minimize the (global) risk such misissuance would pose, and as a result, doesn't provide a safe way for browsers to add support.</div><div class=""><br class=""></div><div class="">There's a further wrinkle that if you try to permit issuance prior to describing the mitigation issues, or prior to implementation, then there's an ecosystem concern that you may see adoption of the insecure practice prior to the development of the secure practice, or the insecure practices' existence used to drain resources from the secure practice. </div></div></div></div>
</div></blockquote><br class=""></div><div>I’m still confused by “mitigation”.  There is client software today that supports SRVNames.  The request is to allow public CAs to issue certs with SRVNames type SANs, not for browsers to look at them.</div><div><br class=""></div><div>Thanks,</div><div>Peter</div><br class=""></body></html>