If I understand you correctly, then the argument against boils down to a few main points:
1) The WFA defined their own PKI Framework, which originally didn’t require public trust so adding public trust now isn’t appropriate. 2) The number of OSU root operators is currently limited. 3) The benefit to Google is limited. Although you mentioned browsers, Microsoft has interest in a publicly trusted OSU cert as they added one of the Hotspot roots to their root store. 4) WFA members might want to participate in the discussion but shouldn’t until the governance reform is completed. 5) Cross-trusting systems makes it more difficult to migrate to better security practices. Is that a fair summary? If so, then 1) There are lots of PKI frameworks operated by various entities, and these frameworks are often updated. Usually (like the TAGPMA), the policy aligns sufficiently with the CAB Forum that issuance of a certificate isn’t going to violate either requirement. The OSU framework was partially based on public cert requirements with the addition of the otherName type. This is one reason the validation and profiles look nearly identical to OV certs. The non-critical technical constraint decision was partially based on the lack of support in Apple products, the WFA arriving at nearly the same conclusion as the CAB Forum. Some of the WFA members, but not all, see a need for public trust in the certs. Although they have a separate PKI framework, it is one that is closely aligned with the goals and requirements we’ve created in the CAB Forum. 2) Although DigiCert is the sole public CA involved at this time, the WFA has twice made an open invitation for CAs to participate. I can’t speak for other CAs about why they chose not to participate in the project. Although there are only a handful of anchors, I’m not sure why this is a “no” for Google. There’s nothing that forces browsers to support OSU or requires CAs to follow the OSU Hotspot profile when issuing non-WFA certs. 3) I have no knowledge of what Google is doing with the OSU program. Perhaps there isn’t a value to Google, but there’s a value in public trust for the WFA community. 4) I’m already participating in both groups. No other WFA members have indicated an interest in participating with the CAB Forum. No need to delay on that account. 5) I don’t understand this reason. If they removed the friendly name and used publicly trusted certificates, then we’d have the same problem with migration as with friendly names included. This is a problem no matter what because people use publicly trusted certificate roots for a variety of purposes. Limiting the profile doesn’t actually change this concern. Jeremy From: Ryan Sleevi [mailto:[email protected]] Sent: Thursday, January 5, 2017 1:41 PM To: Jeremy Rowley <[email protected]> Cc: CA/Browser Forum Public Discussion List <[email protected]> Subject: Re: [cabfpub] Ballot 184: rfc822Names and otherNames Hi Jeremy, 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. HotSpot 2.0 (aka Passpoint) defines its own PKI program ( https://www.wi-fi.org/download.php?file=/sites/default/files/private/Passpoint_R2_Deployment_Guidelines-v1.1.pdf direct link w/ no shrinkwrap) As part of that profile, Section 4.2 details the requirements for that PKI HotSpot 2.0 requires that an OSU (Online Sign Up) server use a server certificate from a HS 2.0 Trust Root CA Certificate. 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. 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) 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. 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. 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. 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. 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. The same arguments apply to adding rfc822Name. 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. On Thu, Jan 5, 2017 at 12:22 PM, Jeremy Rowley <[email protected] <mailto:[email protected]> > wrote: 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. From: Ryan Sleevi [mailto:[email protected] <mailto:[email protected]> ] Sent: Thursday, January 5, 2017 12:43 PM To: Jeremy Rowley <[email protected] <mailto:[email protected]> > Cc: CA/Browser Forum Public Discussion List <[email protected] <mailto:[email protected]> > Subject: Re: [cabfpub] Ballot 184: rfc822Names and otherNames On Thu, Jan 5, 2017 at 9:51 AM, Jeremy Rowley <[email protected] <mailto:[email protected]> > wrote: 3) 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. I'm sorry, this is simply not articulated as to why browsers care. 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. https://captive.starbuckswifi.com ). 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. 4) 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. 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. 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
