2013-02-21 Minutes
Notes of meeting
CAB Forum
21 February 2013
Version 1
Present: Phill Hallam-Baker, Ben Wilson, Atsushi Inaba, Ryan Koski, Eddy Nigg, Gerv Markham, Wayne Thayer, Sara Morris, Dean Coclin, Paul Lambert, Atilla Biler, Rich Smith, Mads Henriksveen, Sissel Hoel, Mert Ozarar, Jeremy Rowley, Stephen Davidson, Tom Albertson,
Agenda Review
The agenda was reviewed and Item 6 (Wi-Fi Alliance) was moved forward to Agenda Item 4.
- Approval of the Minutes of 24 January 2013.
The minutes of 24 January 2013 were approved as published.
- Certificates for Hotspots- An Overview of the Wi-Fi Alliance PKI for Passpoint Online-Signup Servers.
Ben noted that the presentation had been previously circulated, and Sarah introduced herself as a senior marketing manager of the Wi-Fi Alliance and Paul as one of the lead contributors to Passpoint release 2. Sara explained that Passpoint release 2 will be a new way of connecting devices to 802.11 hot spots. Gerv queried that there must be a release 1 already deployed, and Sara said that hardware devices certified as Passpoint release 1 are in use. Release 2 will update the Passpoint program to improve usability and sign-ups in hot spots. With Release 2 at the end of the year, users will see a uniform way of creating accounts and enabling connectivity and Release 2 access points will become more available the first half of 2014.
The Wireless Broadband Alliance has been working on a contractual framework for operators to execute roaming agreements for wi-fi. The goal of Passpoint is universal connectivity where a handset can detect and make a connection to hot spots. It is contemplated that an Online Sign-up Server certificate would include 1. the DNS address of the server, 2. a “friendly name,” and 3. an optional icon hash representing the provider, i.e., AT&T, Orange, Rogers, Verizon, Dave’s Hotspot Café, with a user-friendly display of these certificate contents that will help people unfamiliar with PKI.
Gerv asked for clarification on whether a given hotspot would have multiple providers (because you might want to sign up online with any one of the above providers), and would each of these providers have its own OSU Server? Is the certificate used by the hotspot to connect to each of those OSU servers? Paul said that it might be possible that each hotspot could use multiple providers, but typically a service provider would enter into a subscription relationship, but clearly you would need to support multiple types of accounts, but one of the key points of the technology would be the ability to send information “pre-association”. First, open SSID would be used for the connection with the OSU server for authentication purposes, and then once you get the SSL credentials, it provides security to convert it into a secure hotspot connection-that’s the goal, (and then the AAA server takes care of authentication, authorization, and accounting).
Gerv asked whether the Wi-Fi Alliance would be using its own root store. Paul said that they were open to suggestions, but that they were currently considering having their own root store because the current TLS root stores do not meet the criteria that they consider important. Gerv said that one reason for allowing the protocol to use existing root stores would be to allow customers to maintain roots of their own, and that would allow enterprises to set up their own wi-fi networks and control the connections made by devices within their enterprise. He also said that limiting the number of CAs would not be good for competition. Paul said that the Wi-Fi Alliance is currently concerned about policy enforcement and the quality of checking that CAs would perform, so they would need additional assurances to consider a broader model like the one in use for SSL/TLS today.
Phill said that with Extended Validation, we had started with the idea of separate root stores, but that when you have a bunch of certificates the certificate policy OID becomes a more important way to distinguish what process the CA uses to issue the certificate than the chains under which a root certificate happens to be accredited. He also said that we shouldn’t be creating more roots to manage because one of the reasons Flame was successful is that the provider lost track of a root which was being trusted without the accompanying security oversight. Paul said that the Passpoint CAs could be in the same cache, with different CAs in that cache, or the same CAs could be trusted in some way through the use of different OIDs, but what should be clear is that the Wi-Fi Alliance does not want the standard enrollment-issuance process for Passpoint OSU certificates. In other words, an ordinary SSL certificate should not be capable of being misused to represent a Passpoint hot spot.
Gerv said that one way the CAB Forum has addressed the need to distinguish certificates in the past has been with the use of a policy OID, and that Mozilla would take a very dim view of any CA who asserted they had performed in accordance with a policy when they had not. One approach would be for the Wi-Fi Alliance and the CAB Forum to work together in specifying a policy OID and a vetting policy that complied with Wi-Fi Alliance requirements. Paul said he would be interested in taking the OID approach back to the task force because they do support a broad ecosystem that involves the manufacturers and platform providers.
Ben said he thought that we might be able to just amend the EV Guidelines to add criteria for an EV CA to be able to issue an EV certificate with the Wi-Fi Alliance’s OID, or the CABF could adopt an OID. Sara asked whether, from a trust perspective, an EV certificate without logos/trust logos be sufficient, considering the fact that EV vetting had been performed on the entity-because at least you make the entity accountable, regardless of how they might provide that logo/trust logo. Ben said that he thought that Passpoint could be layered on top of EV with additional requirements that would make the EV certificate also Passpoint-compliant.
Sara then asked about the level of verification that would be needed for an EV-type certificate to assert a logo or trust logo. Ben suggested that the serial number of the trademark could be included in the certificate. Phill said that a trademark database already exists that is maintained by WIPO under the Madrid Protocol. Gerv said that Dave’s Hotspot Café might not have a registered trademark, so for broad-based allowance of trademarks, it would be good to allow that type of mark and if there is infringement, you always have extended validation information that you can use to knock on the door to serve papers if discovery of infringement is a concern. Ben wondered if CAs would have to worry about contributory trademark infringement. Phill said that the concern had already been addressed by including a hash of the logo in the certificate rather than the logo itself. So it’s just an index, and no contributory infringement exists unless you know about it. Gerv said that because it is an index, you would have to have somewhere to pull the logo from in order to display it.
Tom said that Microsoft has a root store of certificates that is OS-based and serves Windows for all platforms, including Windows Phone and Xbox360. He asked whether the Wi-Fi Alliance could explain in greater detail how the certificate and authentication would display on the user’s device. Paul said he had not yet seen a mock-up of the display and that there are other parts of the standard that are being worked on, such as the UI for the AAA portion of the process. Tom suggested that Paul discuss this with the developers working on Windows Phone 8 because they have a concept of privilege in the OS that might conflict with a special hot-spot application model. Paul said that the Wi-Fi Alliance tries to focus on protocol issues and avoid the UI–leaving the user experience to the vendors. Gerv said that he thought this was more of an OS-level issue anyway than an application-layer issue.
Sara asked whether there were interest in starting a working group. There was general agreement that this type of project aligned with the work and interests of the CAB Forum. Sara asked if there were other examples of EV certificates being used for other than web server authentication. Dean mentioned EV code signing certificates, which are issued by some CAs. Paul said that a root cache with certificates differentiated by type of certificate and intended behavior with a limited number of issuers would be consistent with what they are considering. Currently they would like to test with a small number of CAs. Ben mentioned that the Microsoft kernel signing program is a similar implementation with a separate root store and separate trust model for driver signing capabilities.
Sara said that they would like to continue the discussions over email or pursuant to a non-disclosure agreement that would enable more open discussions. She will follow up with questions to the Forum as needed.
- Ballot Review
Ben said that some work on a ballot for Appendix B is still needed, so he’d skip that. Input on the outcome of Ballot 96 was sought because of a slightly late ballot in opposition, which if it were to be accepted would cause Ballot 96 to fail, but by applying a strict ballot deadline would allow the ballot to pass. Gerv said we should just follow the rules of voting, and Ben agreed. Tom agreed, but expressed his continued concern about the ballot, and that too few browsers voted, which might be a further indication that things were wrong with the ballot. He indicated that he had an upcoming call to talk to Steve Sheng of ICANN about the situations covered by the ballot. Gerv said that it was good to put something in place and that we can always go back and revise our approach if we subsequently discover that it should be done differently. Ben said that Ballots 97 and 98 looked like they were going to pass. He also noted that Jeremy had communicated with ETSI representatives and that they preferred a March cut-off time for changes to CAB Forum guidelines. Tom suggested that we should see if WebTrust will accept a March cut-off date for audit criteria revisions, since it appears that ETSI’s schedules are harder to revise. Jeremy said he would contact Don. Ben noted that we would skip the Wells Fargo discussion, but that he had asked Joe Kaluzny and Ryan Sleevi to discuss this over the telephone because he sees the issue as mainly over use of the phrase “internal database,” and that we should see if Wells Fargo could come up with a solution that avoids relying on that wording.
- Letter to ICANN
Ben said he would edit the letter to ICANN based on recent comments and then re-circulate it for another round of discussions.
- Any Other Business
Ben noted that everyone should have seen his abstract submission to NIST for consideration as part of the workshop on CA trust.
For the fall face-to-face meeting in Turkey, Ben will send out a straw vote for the three weeks proposed using the a, b, c method of determining when the maximum number of people would be available to attend.
- Meeting then adjourned until the Next Call - Thurs. March 7th