[cabfpub] Notes of meeting, CAB Forum, 6 December 2012, Version 1

[Ben Wilson]

All,

Here are the approved minutes of our call in December.

Ben

 

[cabfman] Notes of meeting, CAB Forum, 6 December 2012, Version 1

Notes of meeting

CAB Forum 

6 December 2012

Version 1

 

1.   Present: Rick Andrews, Ben Wilson, Kirk Hall, Yngve Pettersen, Atsushi
Inaba, Eddy Nigg, Jeremy Rowley, Dean Coclin, Mads Henriksveen, Sissel Hoel,
Wayne Thayer, Ryan Koski, Ryan Sleevi, Geoff Keating, Gerv Markham, Rich
Smith, and Håvard Molland.

2.  Agenda Review: the agenda was reviewed.

3.   Approve Minutes of 19 Nov 2012:  The minutes of 19 November 2012 were
approved as published.  

4.  Report on ETSI CA Day:  Among those in attendance were Yngve, Ben,
Robin, Mads, Sissel, Iñigo, Dean,  Tom, Arno, Nick Pope, Steve R., Tony
Nagel, Moudrick, and several others.  During CA Day, Dean, Ben and Robin
provided an update on the implementation of the Baseline Requirements.
One of the main topics during CA Day was CA auditing, and Nick Pope, Iñigo,
Arno, and Christoph Sutter updated attendees on CA auditing and the work of
ETSI STFs.  (See Arno’s email dated 18-Dec-2012.)  Representatives of the
European Commission explained the proposed update of regulations concerning
the 1999 Electronic Signature Directive (1999/93/EC).  The main purpose of
the regulations is to remove legal barriers to cross-border transactions
(see
http://docbox.etsi.org/Workshop/2012/201211_TSP/1_TSP%20-%20Berlin%20%20-%20
eID%20
<http://docbox.etsi.org/Workshop/2012/201211_TSP/1_TSP%20-%20Berlin%20%20-%2
0eID%20&%20Trust%20Services%20Regulation%20-%20Galler%20-%2029.11.2012.pdf>
&%20Trust%20Services%20Regulation%20-%20Galler%20-%2029.11.2012.pdf), but it
might also include an initiative to regulate SSL certificates.  The approach
would be to recognize EV certificates as “qualified website authentication
certificates” IF the issuer is subject to member state supervision.  Ben
said he had reviewed the draft regulation
(http://ec.europa.eu/information_society/policy/esignature/eu_legislation/re
gulation/index_en.htm)  and that it did not go into those specific details.
Ben also reported that several CAs in the meeting questioned the efficacy of
that solution because there would not be any further browser enhancement of
trust displays for such certificates.  He also said that he had suggested
that EV could be used as a standalone solution and that the EC should tailor
a separate solution around the perceived problem, whatever it is that they
are trying to solve, e.g. Diginotar, etc.  

Kirk asked whether any additional details were available.   Dean said that
from his conversations, he understood that no one would be required to issue
them and no one would be required to use them, so there would be no demand
pulling them with “we have to have this type of certificate.”  He said that
maybe there might be some issuers in the EU who in the future will try to do
marketing around this type of EU-qualified SSL certificate on the basis that
they are more secure because the CA is also supervised by an EU member.
Dean also noted that enhanced browser displays had been mentioned during the
meeting and he said he didn’t think it would work because of the difficulty
in getting browsers to change the UI.  Yngve noted that he also mentioned
that it would be too difficult.  

Ben said that there were also discussions about improving the acceptability
of audits of Trust Service Providers across the EU, but that would be the
topic for a whole other discussion if any members want to form a group
around that topic.  For instance, we could schedule a telephone discussion
with Nick Pope and other representatives of ETSI.   He also said that when
we have our meeting in Munich, Nick has asked that we schedule an
opportunity to delve into EU/ETSI issues, maybe on a separate day if
facilities are available.   Kirk requested that the discussions of EU/ETSI
issues in Munich be well-planned so that they are productive for all CAB
Forum members and not a lengthy update on the status of the work.  Instead,
the dialog with ETSI and CAs located in the EU should include sufficient
explanation of:  why a particular issue is important for us, what direction
we are heading and why, whether identified goals are worthwhile, and what we
as CAs must do with the information as actionable tasks toward accomplishing
those goals.  

5.  Review of Ballot Status and BR Issues List

Ben asked for comments on a proposed resolution of BR Issue 7.  He
paraphrased the current proposal to resolve BR Issue 7 (revocation of
Intermediate / Subordinate CAs) was that certificates issued after 1 August
2013 that are not issued directly by the root must have a pointer to the
issuing CA’s certificate in the AIA.    Kirk asked for an explanation of why
this was needed.  Ben referred to the email of 5 December 2012 - “Improve
the user experience by helping clients verify certificates for misconfigured
servers (as he has mentioned earlier, 1 server in 50 does not send a full
chain, 1 in 1000 does not send a full chain and automatic completion is not
possible, 
”.  Kirk said he needed further explanation of what is meant by
“server misconfiguration”, and Ben explained that many server administrators
do not properly install intermediate certificates.  Kirk asked whether a
better resolution would be just to require customers to install all required
intermediate certificates.  Gerv noted that because Firefox does not
download any intermediate certificates, any server that is misconfigured in
this way won’t work in Firefox, and therefore, there are not many servers
that are misconfigured in this way.

Yngve said that his information indicates that about 1 in 50 (2%) of servers
do not deliver a complete certificate chain.  Eddy said his information
indicates that the number is higher.  Yngve said that Ivan Ristic’s figures
say it is 7%.  Wayne noted that many users may be more inclined to blame the
CA and not figure out that it is a missing intermediate.  Yngve says that
they actually blame the browser.   Ryan Sleevi asked why the solution has to
be a “MUST” even though he is well-aware of the problem with misconfigured
servers, including servers that deliver their chains in reverse order in
violation of the TLS specification.  He supports a “SHOULD” solution that
allows CAs to address customer needs instead of a “MUST” when the problem at
its core is a customer configuration issue.   Rick said the benefit might be
lower support costs, but that it may not be a benefit if browsers do not
commit to using the AIA to build the missing parts of a chain.  Yngve noted
that Opera and Windows use the AIA.  Wayne asked if there was a reason why
Firefox does not use the AIA.  Ryan S. interjected that AIA chasing isn’t
the best solution because of the performance implications and that support
costs are incurred only by the CA that issues the certificate.  Gerv noted
that Mozilla does receive support inquiries about this problem, but that he
doesn’t believe there are that many.   In answer to Wayne’s question, Gerv
said that he suspects that Mozilla has not implemented it because it is not
a priority and because as Ryan noted, there are performance implications,
and if the misconfiguration is concealed by browser behavior it will just
increase the problem of poor performance.  Yngve said the performance
problem depends on how you implement AIA chasing.  Opera caches the
certificate into the repository, so for a single issuing CA identified by
the AIA URL, Opera does one request and then never again.  Ryan said that he
was aware of caching, but if browsers handle the problem it encourages
misconfiguration.   He would also like the “MUSTs” in certificates be kept
to a minimum so that certificates can stay small, like the omission of the
OCSP URI for OCSP stapling.  Ben asked Ryan why he opposed it if it was a CA
requirement and not a browser requirement.  Ryan responded that he didn’t
see this issue rising to the level of a universal problem that needed
interference between all CAs and their customers.   Ben said that in order
to bring this issue to closure we need to figure out whether to move forward
to a ballot, but that it didn’t sound like there would be more than the
required 50% of browser support, so that if we didn’t take action on it
currently, we should at least document some of the reasons why didn’t act.
Ben asked Geoff what he thought, and he said he agreed with Ryan—that
“SHOULD” would be better than “MUST”.   Yngve asked about removing OCSP when
there is an agreement for stapling.  Ryan said that we need to see where
we’re going with “must staple” and that when we have an OID for it, it makes
sense to include the AIA even if a stapled response is received, if the
client needs to go and fetch a fresh response, then at least they can go do
so.  Yngve said that he could remove the “MUST” for the Issuer URL in the
AIA but leave the OCSP URL.  Ben asked whether Mozilla and Google would
still support cleaning up the problematic language that might still exist in
the appendix concerning the OCSP URL and OCSP stapling.  Ryan explained that
the current wording allows omission of the OCSP URL if there is going to be
stapling, but there is no way presently to enforce that.  Yngve noted that
most servers will need the OCSP URL information in the certificate in order
to configure their own retrieval of the OCSP information for stapling and
leaving it out of the certificate will lead to configuration errors.  

6.  Ballot 89 Issues

Rick explained that he had created a list of 21 issues raised and has put
them on the wiki -  (see
https://www.cabforum.org/wiki/89%20-%20Adopt%20Guidelines%20for%20the%20Proc
essing%20of%20EV%20SSL%20Certificates%20v.2).  He inquired about the
procedure that should be used to resolve these 21 issues.  Rick wants to
avoid separate discussion threads for each issue.  Objections came mainly
from Opera, Apple, Google and Mozilla.   Many of the comments have asked for
additional coverage of certain topics, but Rick would like to avoid that
unless there is widespread agreement.   The issue he is facing is that the
comments on any given topic will come from one person, but no one else
chimes in to say that they also support the comment.  Rick would like to use
a better way of getting consensus.  Ben said that the Survey Monkey account
could be used.  Kirk suggested that Rick start with what appears to be the
toughest or most fundamental issue and re-frame it in a simple way that
presents the potential views and then gather input and then try to reach his
own conclusion on the sentiment of the group and then move to the next issue
and so on until all of the issues have been discussed and then put the
entire work out for a ballot.  Or Rick could put several issues out for
discussion in batches and then make his own conclusions based on the
discussions.  Rick said that it was a good idea provided that everyone else
will participate.  Ben said that if we do decide to use some form of online
survey tool he would be willing to help bug people until they’ve responded.
Rick said that he had received great feedback from Mozilla, Apple, Opera,
and Google, but that they’ve all commented on different things.  Gerv said
that he does prefer a single email on a particular issue rather than a list
of 21 proposed additions or modifications of text because big requests just
get pushed to the bottom of the pile.  Ben said that whatever we do, we’ll
aim at minimizing the time needed to respond.  

7.  WebTrust and ETSI Implementation of Baseline Requirements Audit Criteria

Kirk said he would like to move things to completion and get them off our
agenda.  Just to recap, he noted that he had circulated a proposal to ballot
it without imposing it as a requirement by CAs on other CAs, but only
browsers can through their root programs, so his ballot suggested that it be
a recommendation of the Forum to browsers that the WebTrust and ETSI
requirements apply to all CAs after a certain date, for example, January 1,
2013.  Tom responded to the email saying that the motion wouldn’t accomplish
anything, so Kirk is recommending that we now declare this issue finished
and move on.  Therefore, it is now up to the browsers to announce through
their root programs exactly when they are going to impose Baseline Audits on
their participating roots.  Dean said that he had talked to Tom last week
about the audit requirements and he had indicated that he would not have a
problem with a January 1st date, so he was hoping Microsoft would make that
announcement.  Gerv said that he would be talking with Kathleen and that he
would check to see about the January 1st date as well.  Kirk suggested that
we look up the ETSI reference for the Baseline Requirements audit and
communicate that to the browsers so that they have the right language for
their root programs.  Ben suggested that we circulate a draft notification
email to the browsers using the management email list simply as a way of
getting motion forward to closure on this issue, or we could do it directly
on the side as a subcommittee.  Kirk said he considers it done without
further action.  Ben said that we will then record here in these minutes
that we are done and that there is no further action needed by the CAB Forum
and that we are expecting the Browsers to begin implementing WebTrust  for
Certification Authorities –  SSL Baseline Requirements Audit Criteria v.1.0
and ETSI TS 102 042 V2.3.1 in accordance with Guidance for Auditors and CSPs
on ETSI TS 102 042 for Issuing Publicly-Trusted TLS/SSL Certificates (ETSI
TR 103 123 V1.1.1).  Kirk said that Ben could also send out an email to
browser members in this regard.  

Kirk also recalled that in an earlier email he had suggested that we move
toward a formalized process for incorporating audit standards in our work
and that he had suggested July 1st of each year.  All changes that happened
in the prior 12 months would be fixed as of that date and we would tell the
auditors that we would like their audit criteria updated as of January 1st.
It could either be effective on CA operations as of January 1st or it could
be for audit periods that begin on or after January 1st.  With that approach
there wouldn’t be fewer conflicts with audit requirements.  If members like
this suggestion, Kirk will propose it as a ballot.   Ben said that the
suggestion is fine in terms of simplifying the process as long as we don’t
simplify it so much that it prevents us from fine-tuning the effective dates
for certain things.  Kirk said that it would be fine to make a provision
effective immediately and that until it is in an audit standard it would be
considered a voluntary best practice that members should implement because
it is clear from our conversations with the auditors and browsers thus far
that it will not be enforceable until it is incorporated into the audit
criteria.  Gerv suggested that we check with auditors to make sure that a
six-month cycle is an acceptable timeframe for changes to be incorporated
because it might not be workable.  Ben agreed and said that we can only
control what we do, and that therefore the key thing will be to limit
ourselves to this cyclical, July 1st  framework.  Gerv said that
alternatively we allow them to tell us when they have a stop-start in their
work cycle and then we deliver to them a version where the errata to a
certain date have all been incorporated, and then they go off and they’re
done when they’re done.  Ben said there is a benefit if we can synchronize
updates between the two audit frameworks.   Jeremy said he liked Gerv’s
approach because we really can’t control what the auditors or browsers do in
terms of timing audit updates, but we can set effective dates for ourselves,
so he would like to continue working as we’ve been doing up until now.  Kirk
said that the benefit of his proposal is that it provides more structure and
a less chaotic environment, especially for CA compliance and
audit-preparation purposes.  Kirk said he’d talk to the auditors about their
document update cycles.  Ben suggested that we put this on the agenda for
the next face-to-face meeting.  Kirk said he’d like to have something
concrete prepared as a ballot so that we don’t have endless discussion.  

8.  IPR issues

Ben said that he contacted Entrust and they had indicated that they would
participate again if we adopted the draft version of the IPR Policy that he
had circulated, which included participation defined as voting in favor of a
ballot or as contributing.  Kirk asked about RIM and Identrust because he
didn’t think we should rely on the response of just one company.  Dean said
that RIM has not participated in the working group but his understanding was
that Identrust was amenable to the same position as Entrust.  Kirk said that
TrendMicro strongly disagreed with it being workable and that they opposed
the changes because Entrust would be under no obligation to disclose their
IP.  Gerv said what if during the process of developing a standard that we
discover that the essential claims of several members are included and yet
everyone is in favor of the standard and we get to the vote and suddenly one
of the members who has been quiet and hasn’t made a contribution suddenly
votes no and then later reveals that they held IPR after it has been
adopted?   Ben said that he thought that scenario could be easily resolved
by cancelling the vote or otherwise legally addressing the bad faith of a
participant who engages in that kind of behavior.   Gerv said that this
would allow disruption of the work of the Forum because we would have to go
back and change the standard.   Ben said that he intended to push forward
with a ballot on this version of the IPR and find two members willing to
endorse the ballot even if TrendMicro and Mozilla intended to vote against
it.  Gerv asked if that Ben did intend to move forward that he include a
requirement for tracking who are the contributors during the document’s
lifetime because that will reduce the number of disputes in the future
because it will contemporaneously record it when it happens and give
participants much greater certainty about who have and haven’t  licensed
their patents.  Ben said he would make it part of the ballot.  

9.  Governance Reform Issues

Ben said he would create an official version of the Bylaws based on Ballot
94 for posting on the wiki and the web site.  He said that he added this
item to the agenda in order to keep moving forward on issues of transparency
and for continued discussion of how we allow SMEs and other interested
non-members to participate.  Kirk said that we have a framework in place.
Jeremy said he thought that Kirk was going to work on some amendments.  Ben
noted that with the holidays coming up that he figured everyone would like
to take a break.  Kirk said that he had some minor improvements that he
would like to make, including posting of ballots in track-changes mode to
make it easier to see what is involved, and that the format should include a
description of the problem being addressed, etc., but we can give the bylaws
a try for a while and see how they work.  Ben said that we ought to revisit
the bylaws every once in a while because we want to be proactive.  Rich said
that our ballots used to focus on a single set of issues and the ballots
have gotten away from the format where the single issues were easier to
track, so we may not need a ballot to require that, but we should give some
thought to encouraging people to go back to how we used to do things where
the ballots were smaller and clearer.   Ben said he agreed, but that part of
the problem may have been we have been trying to accomplish so much over the
past year and a half.   Ben said it would be nice if someone would volunteer
to help with ballots by reviewing them, reformatting them for consistency,
etc., and that maybe we can experiment  with some templates without being
bound—sort of like when they build a campus without sidewalks and then lay
the cement after they have figured out the traffic patterns.  Rich said that
it may have arisen out of the fact that groups of BR issues were assigned to
certain individuals and that they would try to address multiple issues with
a single ballot, but we shouldn’t do that going forward.

10.  Development of new content for web site

Kirk said it would be helpful to outline what we want for each section.  Ben
said that he would work on giving everyone a section of the web site to work
on along with a brief explanation or bullets of what the content would
include.   Rich said that Ben should circulate the proposal to the list and
maybe that will bring in some volunteers.

11.  Any Other Business.

Yngve announced that he would be leaving Opera the first week of January.
Håvard said that Opera will need to determine whether his workload allows
him to participate in Yngve’s place, but that someone would be assigned as
the contact person.  Ben said he would like to see Yngve participate as an
invited expert.  Rick and others said they would look forward to Yngve’s
continued participation on the public list.

Dean reminded everyone that he had circulated a discussion FAQ of the
Baseline Requirements and the BR OIDs and that he would appreciate getting
everyone’s feedback on it.  Goal of the FAQ would help explain the BRs to
relying parties.

Ben asked about whether the CAB Forum web site should refer to Entrust and
Identrust because if we want everyone to abide by the BRs, then we ought to
include their information even if they are not CAB Forum members—just to
make sure we’re advocating adoption.  Eddy asked that it be published also
as a PDF.   

Kirk noted that the comments received about internal name certificates shows
a big flaw in our outreach to other CAs and their customers.  These groups
are coming now and asking when and why did we do this, so this shouldn’t
happen in the future because we need to do a better job of announcing and
circulating pending proposals and getting feedback when we are proposing
anything that will have a substantial impact on their business and their
customers.  Dean said that we need to publish Brad’s paper.   Jeremy said
that with the Baseline Requirements we did circulate the proposal on the
Mozilla list and gave people more than 30 days to comment and after changes
were made based on the comments we went through another 30-day review
period.  Kirk asked whether people had to find them.  Ben said that we
reached out through email with an approach that we thought was adequate but
that in hindsight maybe it wasn’t good enough, but that it is just hard to
contact people if you don’t know they are interested and the degree of
effort put in to outreach is a relative measure because people around the
world are speaking other languages on an everyday basis and read different
sources to get their information.  Yngve said that sometimes the people who
are affected don’t even realize they will be affected until afterwards, so
they would not have submitted any comments had they known.  He suggested
that the CAs need to look through their customer bases and identify those
likely to be affected and then get feedback to provide the CAB Forum.
Jeremy said that Symantec did do a survey.  Dean said that Brad’s paper was
in response to Symantec’s survey.  Dean said we need to get the information
on the web site.  Kirk said we should have done a better job.  Ben reminded
Kirk that he wasn’t involved at the time so he doesn’t fully understand what
we did or didn’t do.   Jeremy said that several of us were opposed to it.
Kirk said that if there had been more public input it may not have been
adopted.  Jeremy responded that there was substantial opposition to internal
server names and that if we had gone out for more public comment we might
have received the same proportion of input for and against.  Kirk said that
we should have reached out to a few online technology magazines to write
about it because we should have known that it would be a big change that
would affect a lot of people.  Dean urged that we at least publish Brad’s
paper on the web site, and Ben said that he would take that down as an
action item.

10.   The next call will be Thursday, January 3, 2013

Meeting adjourned.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130110/05621818/attachment-0003.html>