<div dir="ltr"><div>Hi Jeremy,</div><div><br></div><div>It sounds like you're either confused about HotSpot 2.0, making very contradictory arguments, or I'm simply not having any ability to follow your logic.</div><div><br></div><div>HotSpot 2.0 (aka Passpoint) defines its own PKI program ( <a href="https://www.wi-fi.org/download.php?file=/sites/default/files/private/Passpoint_R2_Deployment_Guidelines-v1.1.pdf">https://www.wi-fi.org/download.php?file=/sites/default/files/private/Passpoint_R2_Deployment_Guidelines-v1.1.pdf</a> direct link w/ no shrinkwrap)</div><div>As part of that profile, Section 4.2 details the requirements for that PKI</div><div>HotSpot 2.0 <b>requires</b> that an OSU (Online Sign Up) server use a server certificate from a HS 2.0 Trust Root CA Certificate.</div><div><br></div><div>That's acceptable for the limited use case of HotSpot 2.0 being used with proprietary (vendor) apps, which is apparently what is was designed for. That is, this is situations like Time Warner Cable's "Wifi Finder" app or the Boingo app. These applications can specify the trust stores they use, as part of their applications, and just like the Point-of-Sale/Cablebox/etc problem, this is not an issue for the CA/Browser Forum to deal with.</div><div><br></div><div>However, if the argument is (and, unfortunately, from the WFA it is), that common off-the-shelf browsers should also communicate with the OSU - this is the Starbucks example Jeremy gave - then it's a problem. Browsers maintain their own trust stores - and do not recognize that of the HS 2.0 CAs (which, if memory serves, also included a WFA-operated CA)</div><div><br></div><div>The view of this particular browser vendor is that if you want Chrome to load a page, you should use a publicly trusted CA server. The need for HS 2.0 to require and define its own PKI is inherently sketchy, but I can appreciate the arguments for the EAP-TLS / AP exchange / OOB communication. However, requiring that the OSU use it is, in my view, problematic.</div><div><br></div><div>Jeremy works for one of the only two CA vendors that are recognized by HS 2.0, and AFAIK, the only one which also has a publicly trusted CA.</div><div>Jeremy's proposal has the effect of allowing the publicly trusted CA to be used for the HS 2.0 OSU - allowing DigiCert certificates to be 'dual use', as it were - usable both in HS 2.0 apps (like the TWC or Boingo apps) and in browsers.</div><div><br></div><div>I can understand why that would be appealing to DigiCert. What I don't understand is why that would be appealing or desirable to browsers. I imagine that the argument goes is that HS 2.0 has more momentum then the web, ergo unless browsers allow this, they'll be "forced" to add the HS 2.0 Trust Root Root CA Certificates to their browser stores. I find that extremely unlikely.</div><div><br></div><div>However, if we do believe it's good - that DigiCert should be able to share infrastructure with both publicly trusted PKI and with such private PKIs as HS 2.0 - then I would argue that it's something we absolutely shouldn't be taking on until we get to a point where HS 2.0 participants can participate. That is, until we've completed GovReform.</div><div><br></div><div>The same arguments apply to adding rfc822Name.</div><div><br></div><div>I understand that we benefit from economies of scale, and a rising tide lifts all boats, and any other aphorisms or metaphors we'd like to go along with that. But I think, on the back of the SHA-1 deprecation woes, we shouldn't be needlessly coupling independent systems, nor should we be trying to expand the scope unless and until we've got better vectors for participation, discussion, and feedback.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 5, 2017 at 12:22 PM, Jeremy Rowley <span dir="ltr"><<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-6470265441106247378WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Why would you consider it a bad security design? It’s just an SSL cert with an otherName included. There’s really nothing else that differentiates them.  <u></u><u></u></span></p><p class="MsoNormal"><a name="m_-6470265441106247378__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><u></u> <u></u></span></a></p><span></span><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Ryan Sleevi [mailto:<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>] <br><b>Sent:</b> Thursday, January 5, 2017 12:43 PM<br><b>To:</b> Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>><br><b>Cc:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><span class=""><br><b>Subject:</b> Re: [cabfpub] Ballot 184: rfc822Names and otherNames<u></u><u></u></span></span></p><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Thu, Jan 5, 2017 at 9:51 AM, Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>> wrote:<u></u><u></u></p><div><div class="h5"><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><p class="m_-6470265441106247378m741881086273449798m-3178879151159413396m-3045134859279020391msolistparagraph" style="margin-left:.5in"><br>3)<span style="font-size:7.0pt">     </span>The browsers are part of the HotSpot program. The WFA membership includes Apple, Microsoft, and Google.  As Ryan points out, the representatives are not necessarily the same, but, nevertheless, browsers are interested in the project. This group should provide browsers with the option of reusing their trust store as part of the program (Erwann pointed out that Microsoft has already done this). Forcing browsers to have two separate trust stores on the same platform doesn’t make much sense where the two programs are essentially compatible minus a few points.<u></u><u></u></p></div></div></blockquote><div><p class="MsoNormal">I'm sorry, this is simply not articulated as to why browsers care.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">More concretely: You've not demonstrated why there is a need for a second trust store at all. If Starbucks wants to run a captive portal, it can and should use a publicly trusted CA cert to the captive portal (e.g. <a href="https://captive.starbuckswifi.com" target="_blank">https://captive.starbuckswifi.<wbr>com</a> ). It shouldn't create a 'shadow trust store' for captive portal signin pages (as the WFA has done), and there's zero incentive to browsers to support that.<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><p class="m_-6470265441106247378m741881086273449798m-3178879151159413396m-3045134859279020391msolistparagraph" style="margin-left:.5in">4)<span style="font-size:7.0pt">     </span>Allowing WFA otherNames invites interoperability from other groups. I think showing the public that this group is willing to interoperate with the WFA invites other groups to bring their use cases forward and see whether we can accommodate them. I’d rather know the various ways people would like to use public trust than have everyone assume the public trust industry is impossible to work with.<u></u><u></u></p></div></div></blockquote><div><p class="MsoNormal">I would rather we resolve the many governance issues first, since we have repeatedly made clear that's a precondition to expanding the scope of the Forums' activities.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">As it stands, I think we'd be fairly opposed to both the rfc822Name proposal and the WFA proposal. SRVNames are and remain a good idea, but rfc822Name has significant interoperability and legacy concerns, and the WFA stuff is just... bad security design.<u></u><u></u></p></div></div></div></div></div></div></div></div></blockquote></div><br></div>