[cabfpub] Ballot 184: rfc822Names and otherNames

Ryan Sleevi sleevi at google.com
Thu Jan 5 19:43:16 UTC 2017

On Thu, Jan 5, 2017 at 9:51 AM, Jeremy Rowley <jeremy.rowley at digicert.com>

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170105/7b195ad4/attachment-0003.html>

More information about the Public mailing list