[cabfpub] Notes of Teleconference of 30 January 2014

Ben Wilson ben at digicert.com
Mon Mar 10 16:28:08 UTC 2014


30 JANUARY 2014

Dean Coclin read the antitrust statement at the bottom of the agenda.  

1.  Roll Call:  Dean Coclin, Eran Messeri, Rick Andrews, Kirk Hall, Eddy
Nigg, Doug Beattie, Eneli Kirme, Mads Henriksveen, Sissel Hoel, Gerv
Markham, Imren Altepe, Robin Alden, Atsushi Inaba, Ryan Sleevi, Tom
Albertson, Rich Smith, Ben Wilson, Wayne Thayer

2.  Agenda Review:   Dean reviewed the agenda and no changes were made.

3.  Minutes:  Minutes of 2 January 2014 were approved.  (The meeting of 16
Jan 2014 was cancelled.)

4.  Discussion of Ballots:   Ballot 114 - EV Definitions passed.  Voting on
Ballots 110 and 115, dealing with bylaw revisions for associate members and
invited guests and Entrust/Bruce Morton, starts on 30 January 2014. 

5.  Participation of Cisco as Associate Member:  Dean said that Cisco had
asked again about the status of their inquiry into Forum membership. He
noted that we had discussed this in November and that Cisco is not clearly
either a CA or a Browser and that it has some elements of both.   He said he
previously distributed information about the methodology used by Cisco to
manage its root store.   Until we come up with a new definition of trust
anchor managers, as mentioned by Tom, Dean would like to recommend that
Cisco be invited to participate as an associate member.  That way they could
attend but not vote, similar to PayPal, ICANN, ETSI, WebTrust and others.

Gerv asked whether associate membership was part of the bylaws yet.  Dean
clarified that associate membership is in Ballot 110.  Kirk reconfirmed that
when the bylaws were drafted, associate membership was not specified but
that the Forum had followed its de facto treatment of them.  Ryan S. said
that there is no associate member category, but we do have interested
parties.  Gerv said that during the meeting in Turkey, we worked on a round
of revisions to the bylaws to clarify what types of members there are.
Ben said that Cisco could fit into the current "Interested Person" category.
Dean said that the bylaws provide that interested parties can participate by
completing the IPR agreement. 

Gerv suggested that we invite Cisco as an "Interested Party", saying that we
will clarify this and soon they will be an associate member if this passes
and that is effectively the same status and then they can participate in the
discussions of how exactly we define browsers going forward.  There were no
objections to inviting Cisco as an "interested Party" as long as they sign
the IPR.  Dean will reach out to them.  

Dean read Cisco's reasons for wanting to join.  Cisco is interested because
they are operating a CA/B Forum compliant sub-CA subordinated under the
Identrust root, and they are in the process of setting up another publicly
trusted root which will be compliant with CA/B Forum standards from the
get-go.  Cisco SSC CA 2 is already fully WebTrust for SSL CA certified as of
this year and has been WebTrust for CA Certified for several years, and the
new root representing Cisco is an investment in customer services that
require a publicly trusted root.   Given how important that can be to their
business and products, they want the chance to contribute to the standards
that will determine the playing field.  Their PKI trust pool originates from
Cisco's trusted root project.  They are restricting the contents of that
root pool this year, as well as establishing new root stores that can be
used for certifying third party code or applications on Cisco products, or
for certifying connections to or through them.  Standards like those of the
CA/B Forum represent a chance to exchange information with peers in that
space and to establish cross-company guidelines for root stores that foster
consistency.  It is also a good way to demonstrate Cisco's ongoing
commitment to transparent, secure, and open standards for cryptographic
security on the internet and helps calm concerns created by the recent NSA
fallout.  They have always operated above board and want to continue to
assure their customers that they are trustworthy while encouraging and
fostering standards by bodies like the CA/B Forum that encourage open and
verifiable security standards.

Gerv thought they sounded more interested in being on the CA side than on
the Browser side.  Dean said they mentioned the PKI trust store, which is
more like a browser.  Ben suggested that they are a hybrid, and no
definition exists for them yet.  We have always had to pick which one you're
in, but in this kind of situation, I don't know if we want to follow that
history.  We might need to define another membership type.

Gerv said that if they are an interested party, it doesn't matter which side
they are on, but if they are going to join they have to pick one, because
the one you pick depends on how your vote is counted. Gerv things that Cisco
seems to be more in the CA business than other browsers.

Dean said that if they come to the face to face, we can talk about it there,
but it doesn't look like they will have submitted their signed IPR agreement
by then.  

Kirk suggested that the browsers move forward with their own ideas of a
definition of a browser so that we can get the bylaws the way we want them.
He suggested that the browsers come to the Mountain View meeting with a
proposed membership definition for the bylaws. 

Gerv mentioned that he had started writing an email on that topic, but what
he was missing was a clear and full understanding of the issues with the
current definition.  There are companies that we gut feel should qualify as
browsers, but don't.  Having a list of those companies would be useful.
Ryan agreed.  The definition flows out of principles and what kind of
organizations we think should be members in order for the CA/B Forum to be
effective.  If we start to write a detailed definition without having an
agreement on what we're trying to achieve, it's not going to work.  Do we
need to start a discussion on the mailing list to determine what that would

Ryan said a big part of the interest in defining the definition of the
Browsers is the increased scope of the Forum with code signing.  In
particular, the code signing working group, as opposed to focusing on
SSL/TLS.  We need to address the increased role of the Code Signing working
group, and when to permit organizations when they care about code signing,
but might not necessarily care about SSL/TLS.  We need to understand what
organizations we want to have as members, but changing the definition of
browser to the point of meaninglessness creates concern for those already
deeply involved in improving the SSL/TLS ecosystem.  He would like to see
the names of those who we believe should be members as browsers, and the
browsers can look into it, and try to find a way to expand the definition,
or look for ways that they actually meet the current definition.  Because
there hasn't been a demonstrated problem with the current definition we just
need to understand why you want to expand it.

Ben said the list of those entities is as simple as Oracle and Cisco, but he
wasn't sure what the definition of that group would be.   Gerv mentioned
that Oracle qualified because they run a root store built into Java. 

Ryan said that it sounds like from what Dean read, that Cisco is planning on
running a root store of their own.  Dean clarified that Cisco has operated a
trusted root store for quite some time.  All Cisco products have the feature
called PKI Management and they have over 100 products.  They perform an
analysis of three major root stores:  Microsoft, Apple, and Mozilla. If the
root appears in all three stores, they include it in their bundle.  

Gerv said that independent trust decisions, rather than taking someone
else's decisions, is an important part of being a browser.  Positive
security decisions are important as well--taking an algorithm based on
someone else's decisions is not sufficient to qualify as an independent root
store operator.   So, if what we are looking for is a root store operator, a
root store operator is someone that has a program and criteria for making
independent trust decisions. 

Additional discussions should follow at our face to face.

6.  Planning for Mountain View and Eilat

Working groups will meet on Tuesday, 18 February 2014.  The proposed
schedule for working groups is (Pacific Standard Time UTC-8):

09:00-10:30         RFC 3647 Conversion Group

10:30-12:00         SSL Performance Working Group - SSL Profiles 

12:30 - 2:30        Code Signing Working Group  

3:00 - 5:00           Extended Validation Revisions Working Group  

Ben will start an online agenda for the Wednesday and Thursday meetings.  

Certificate Transparency  will be discussed at  9:00 am on Wednesday or
Thursday to accommodate remote participants in European time zones.   

Although this is not a business operations issue, Ben will be putting
together a tour of Petra, Jordan, on Thursday, June 19, for those

7.  Continued discussion about Certificate Transparency 

Eddy said that he has discussed his position about Certificate Transparency
with Eran Messeri of Google, but he also requested the opportunity to
present and record his position (and that of others he's talked to) with the
CA/Browser Forum.  His first point was that the pre-certificate process is
extremely difficult.  There is a huge difference between "the intention to
issue" a certificate and the actual "issued certificate".  Certificate
requests can come in a variety of ways.  For most CAs, a certificate request
will proceed through multiple stages and layers of the CA infrastructure
until it is eventually approved and a certificate is issued.  In some
situations, a certificate presented to the CT log as a pre-certificate might
not get issued later on.  In some CA infrastructures, there might be no
ability to communicate with a transparency log server during this process
(scrivener's note:  because it could open up a firewalled network to an
external attack).  Some CAs will not communicate with an outside source for
security policy reasons - especially "at the point where the CA is about to
issue the certificate".   Yet communications from Google indicate that the
pre-certificate should be submitted to the Certificate Transparency log as
one of the very last steps in the issuance process.  Eddy does not want to
insert something into a certificate at the very last moment.  

Ben asked Eddy for clarification on this point and whether CT proofs could
be provided at a different time during the process and what did he mean when
he said that it is supposed to be one of the very last tasks.  Eddy said
that if you look at EV certificates, which involve a lot of manual review by
staff before you issue the certificate, CAs could probably manage such
process and create a pre-certificate,  but this cannot be done for non-EV
certificates, for which some are partially automatically issued.   The
process would be different.  He would have to point to the CT log at a very
early stage for these types of certificates.  Then if the certificate
request is rejected, it is problematic because there would be a record in
the log for something that never posted.   CT currently does not allow
removal or revocation of a record.  CT log would then be inaccurate, because
it would say that a certificate has been issued when it has not.  If anyone
does implement this pre-certificate, it should instead be called something
like a "certificate signing request" and not a "certificate".    Eddy's main
concern is that they cannot and will not go online to perform the
pre-certificate process as a last step in an automated process.

Ben said he would prefer that we not have multiple different types of
implementations, but he understood Eddy's concerns.   Since Google was able
to go out and create a pre-populated certificate transparency log based on
discovered certificates, based on issued certificates and not
pre-certificates, he wondered whether there were other solutions, but he
noted that we need to keep in mind these questions, "what is the problem
we're trying to solve?" , "does the proposed solution solve that problem",
and "when it is all said and done, did we solve the problem that we sought
to solve in the first place?"  

Eddy said that his second concern is privacy.  We should not be telling
everyone in the world about certificates issued for internal systems.  We
don't publish certificates, even though certificates that are used publicly
become known.  He said he would discuss an alternative later, but that
another issue is the overlap between Certificate Transparency and OCSP and
CRLs.  CT has a list of certificates and OCSP today must have a list of
certificates.  Now, if a browser could ask CT about whether a certificate is
valid or not, it could relieve CAs from having to provide OCSP, and they
could use those resources to maintain CT logs rather than OCSP as a more
cost-effective solution, at least for us.  

Eddy:  The timeframe that Google suggested for implementing CT is
unrealistic because for non-EV we cannot implement it in any case.  Eran has
made me aware that Google, Apache, nginx, and maybe other web servers are
working on an extension for certificates that they see at their servers can
submit them to a CT log and receive back a signed timestamp which will be
delivered by a TLS extension by the very same server providing the
certificate.  This is a post-issuance solution that I believe would work
well for two reasons:  (1) the certificate already exists, and (2) the
reporting is done by the owner of the certificate, and this resolves the
privacy issue.   Google has said that there is a problem because it will
take time until web servers can handle this process with such a TLS
extension, but I believe that is good because this technology is new and
still has to be learned and it must be operational without problems, and
then we still have support issues to be concerned about.  So bottom line is
that this should be done by the servers. 

Eran:  Regarding privacy, that was also mentioned by Rob Stradling.  We now
believe we have a solution that will be in the next RFC.  Specifically, if
you want to look at it, it is Issue #20 for the discussion of RFC6962-bis /
Certificate Transparency issue tracker.  As for the timeline, one option is
to implement a whitelist, for existing issued EV certificates for example,
so we don't have to wait for all certificates to expire and be replaced with
new ones that support CT, and we can have a whitelist in Chrome.

As for the Apache change, we are working on it, with dependencies on other
libraries also.  They have been submitted and are available.   We haven't
announced anything because we don't believe in announcing anything that is
not done yet, but it is one direction that will help some site admins, but
as an only solution it would be very difficult to successfully deploy
because each and every web server would have to support it.      

Ryan:  For Chrome and its requirements for EV, Certificate Transparency
serves a broader purpose than what Eddy has highlighted on this call and
what others have on the list.  Certificate Transparency is an important
complement to public audit requirements.  We are strong believers in the
public audit.  Given the incidents that we've seen over recent years, public
audit is going to increasingly become a requirement for participation of
public recognition of EV and eventually of SSL, as stated in previous
emails.  Eddy has highlighted it as a statement of revocation, but we view
it as more than revocation, but as a part of public audit.  Because CAs are
publicly trusted by our program, we're going to increasingly require
baseline requirements audits the same way we require WebTrust for EV.   

Eddy:  The funny thing is that EV certificates probably have the least need
to be in the CT log.  Maybe it is the best way to learn it, and easier to
implement, as I've said before, and there have been fewer misissuances
because of the requirements involved.   Thanks for the opportunity to
explain our position.

Tom:  Could Ryan clarify Chrome's position on Certificate Transparency and

Ryan:   Certificate Transparency will be part of Chrome's program
requirements just like Mozilla's program has Baseline audit requirements,
and Microsoft has requirements on certificate serial numbers and an
agreement as part of its program.  Such program requirements go beyond
common requirements.  For Chrome, we would require audits for baseline and
EV, but in addition to those, we will require CT as part of our program
requirements because having a publicly auditable log is an important part of
participating as a publicly trusted root, at least for our users,
recognizing that other browsers may have other opinions on that.   

8.  Report on ETSI CA Day Meeting 

Dean said that Ben, Robin, he, and other members of the CA / Browser Forum
were at the ETSI CA Day meeting hosted at TuVIT in Berlin on January 16,
2014 and that he and Ben wrote a blog post available here:
https://casecurity.org/2014/01/24/ca-day-in-berlin/.  Presentations from the
meeting are available here:

9.  Working Group Updates

The EV working group continues work on ballots to present to the Forum.  A
draft of the Baseline Requirements for Code Signing certificates was
distributed by Tom recently.  Working group members should start preparing
for the face-to-face meeting by getting up to speed on the list of tasks
they are working on.  The SSL Performance working group should be looking at
certificate profiles.  

10.  Any Other Business


11.  Next phone call -- Thurs. Feb 13th

12.  Adjourn


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140310/fbb7c5ff/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5453 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140310/fbb7c5ff/attachment.p7s>

More information about the Public mailing list