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]] Sent: Thursday, January 5, 2017 12:43 PM To: Jeremy Rowley <[email protected]> Cc: CA/Browser Forum Public Discussion List <[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
