[cabfpub] Ballot 184: rfc822Names and otherNames
sleevi at google.com
Thu Jan 5 13:40:35 MST 2017
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
HotSpot 2.0 (aka Passpoint) defines its own PKI program (
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
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
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 <jeremy.rowley at digicert.com>
> 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
> *From:* Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Thursday, January 5, 2017 12:43 PM
> *To:* Jeremy Rowley <jeremy.rowley at digicert.com>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject:* Re: [cabfpub] Ballot 184: rfc822Names and otherNames
> 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...
More information about the Public