[cabfpub] Notes of meeting, CAB Forum, 21 February 2013

Ben Wilson ben at digicert.com
Wed Mar 13 00:46:20 UTC 2013


 

Notes of meeting

CAB Forum 

21 February 2013

Version 1

 

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, 

2.   Agenda Review

The agenda was reviewed and Item 6 (Wi-Fi Alliance) was moved forward to
Agenda Item 4.      

3.   Approval of the Minutes of 24 January 2013.  

The minutes of 24 January 2013 were approved as published.  

4.  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. 

  

5.  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.  

6.  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.

7.  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.

8.  Meeting then adjourned until the Next Call -- Thurs. March 7th

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130312/c09f8b3e/attachment-0002.html>


More information about the Public mailing list