[cabfpub] Notes of meeting, CAB Forum, 24 January 2013

[Ben Wilson]

Notes of meeting, CAB Forum, 24 January 2013

Version 1

Notes of meeting

CAB Forum 

24 January 2013

Version 1

 

1.   Present:  Ben Wilson, Atsushi Inaba, Mads Henriksveen, Sissel Hoel,
Eddy Nigg, Rich Smith, Ryan Koski, Ryan Sleevi, Gerv Markham, Simon Labram,
Kirk Hall, Jeremy Rowley, Wayne Thayer, Rick Andrews, Brad Hill, Stephen
Davidson, Robin Alden, Mert Ozarar, Phill Hallam-Baker

2.   Agenda Review: the agenda was reviewed.  

3.   Approve Minutes of 10 January 2013:  The minutes of 10 January 2013
were approved subject to factual corrections made by Turktrust.  

4.  News Items:  NIST request for papers and 2-day event April 10-11; ICANN
request to discuss Non-FQDN certificates during next F2F; and Update of
Scanning results for End Entity Certificates Where CA=True.

NIST:  Ben announced that NIST had released a request for papers in advance
of a 2-day event to discuss security of the Web PKI April 10-11.  He plans
on attending and asked who else had plans.  Kirk said TrendMicro would send
someone.  Rick said he would attend.  We will discuss this further as an
agenda item during the Face-to-Face meeting.

ICANN:  Jeff Moss of ICANN has requested some time Tuesday morning of the
face-to-face to go over potential issues that may arise with the new gTLDs
if valid, pre-existing certificates are issued to entities that are not
registrants under the new gTLD program.  Ben said that in the past we have
discussed internal domains such as .corp and .local and we have tried to
alert ICANN to this issue and now they would like to discuss it.  Brad said
that Jeff Moss is concerned about the same things that PayPal and Google
have been concerned about for the past two years-that we need to accelerate
the retirement schedule for internal names that are going to be registered
as gTLDs and will be globally resolvable.  Brad said that the CABF should
look at his previously proposed language and take action or respond that it
is not going to take any action.  Ben said that we need to be politically
astute and aware of the issues and a dialog will be helpful so that we can
take action based on a solid understanding of the situation.  It would be
easy to just point fingers, but we should identify the most urgent actions
that need to be taken, like for instance, avoiding problems with legacy
certificates by not issuing them in the first place.  Brad said that we are
not just talking about dot-less domains, but certificates issued to .delta,
.foobar, etc.  Applicants are spending up to five million dollars and are
unaware that there may be valid internal certificates issued for their
requested gTLDs.  They will not be too happy if CAs do not revoke those
certificates on an accelerated schedule, and saying that they cannot be
revoked without coordinating with existing customers will not be a very good
excuse when these issues have been previously raised.   Brad said that over
a year ago he had proposed language that he thought worked.  In response to
the ensuing discussion, Ben said that we did not have time to debate the
language of a ballot on this phone call.  Instead, we should work to
understand the problem better, for instance, by scanning our certificate
databases for names that are potential / applied-for gTLDs.    Kirk said
that we need a statement of the problem so that we know what we're trying to
fix.  Ben said he'd like to see something in writing, and if so, it would be
something like, "the CAB Forum already has a retirement schedule set for
internal name certificates.  We need to revisit it and revise it by looking
at the issues to identify what more we can do to facilitate the
implementation of these new gTLDs by not issuing these names in certificates
or by changing the retirement schedule for these names.  We can control what
we do, but we cannot control what others will do, and that is another
problem, etc."  Rick and Jeremy said they would be happy to continue working
on the proposed ballot language.  Jeremy said that when he talked to Jeff
Moss, he said that ICANN is also concerned about certificates issued to
*.newgTLD, and so the ballot will need to address that concern as well.
Rich said that Comodo would support that approach, too, but that he is
concerned about the lack of information from ICANN on what is being done on
their side, so when we have our conversation with them, we will need to find
out which new gTLDs are really being considered for the earliest approvals.
Kirk recommended that we have a ballot prepared to place on the table for
our discussions with ICANN.

Results of Scan for Certificates with CA=True.  Eddy said that Yngve had
been very helpful in locating some of these problematic certificates.   He
said that Yngve had found 60+ certificates with CA=True and no pathlength
constraints, issued by a Korean CA.  Eddy sent an example to the management
mailing list.  He explained that the CA is trusted in Microsoft's trust
store, and that he and Yngve had communicated with Tom about the CA, and
that Tom was going to contact the CA.  There were some certificates that did
have the pathlength=0, which would mitigate the problem somewhat.  None of
the other parties that Eddy contacted about searching their databases for
this CA=True condition have yet responded.  Yngve found additional
certificates with this condition which had also expired, and some of the 60+
expire in February.  Gerv said that Mozilla is not affected because the
Korean CA is not in their root store.  Eddy said that we should continue our
research and also prohibit this type of certificate in the future because
the entities receiving these certificates are not CAs.

Ben asked what the procedure should be when these things are discovered.
"Should we rely on the browsers to contact these CAs or should we contact
these CAs and let them know that if they do not resolve it we will contact
their customers directly?"  Gerv said that the Browsers cannot take on the
responsibility of policing every little certificate error.   Eddy said that
for the Microsoft root store, it is relied upon by multiple browsers like
Google and Safari, so the issue is broader than just Microsoft.  Kirk said
that if an issue is important enough we should contact both the CA and the
browsers because they might be unaware that they were doing this.  And we
could ask that they take action and if they don't take action we could make
the issue more public.  

Rick asked if browsers might consider taking additional action, such as
blocking, even when the root is not in the trust list, because even Firefox
allows you to bypass such errors and these are malformed certificates.  Gerv
said that 60+ certificates across the whole web is a rather smallish number
for a special block.  Ryan Sleevi said that trying to address these kinds of
security issues is too hard given that parameters in certificates can easily
be changed.  Chrome performs automated checks on several things, but on some
things there may not be an added security benefit by blocking it.  Rick
believes these kinds of issues are not going away and we can't just ignore
them.   Ben noted that we haven't done a risk-threat-benefit analysis and
that it would be good to know what the degree of risk is for these kinds of
issues, so in the future we might want to categorize and scale them based on
their perceived risk.  Gerv asked, "what is the additional risk over and
above your ordinary untrusted certificate?"  The group discussed what might
happen if a user clicked through the warnings and/or either granted an
exception to the certificate or accepted it as a CA in their root / trust
store.  (E.g. are users subsequently exposed to other certificates signed by
that site's private key?)  Ryan Sleevi said that exceptions would still
subsequently fail-based on what he knows about how Firefox and other
browsers are doing exceptions.  The only risk is if the user were to install
that certificate as a trusted CA, and they will be told that it is a CA
certificate that they are installing, but if you click through as an
exception, you're only accepting it as that server's certificate.  Gerv
said, so there is still no incremental risk over and above that for an
untrusted certificate, which doesn't have CA=True in the basic constraints.
Rick said that, to illustrate, he had received a request from Kathleen a few
weeks ago and she wanted confirmation that CAs have looked through their
databases and to not just respond that they have controls in place, so
similarly, it would be better if someone were to actually go through and
test this scenario and verify whether browsers do behave the same
universally.  CAs take a hit when they mis-issue a certificate, but there
are things that browsers can do and fail to do and that causes a bad light
to fall on the system and make people think that the whole system is
untrustworthy. Ryan S. said that browsers continue to perform risk analysis
on CA problematic practices and things that CAs do that affect the
reliability of their browsers.  They do add software controls, in addition
to procedural controls like WebTrust and ETSI, for added security.  The
software controls must be perceived as effective and easy to implement,
because UI changes are going to be predicated on benefits to end users, and
treating it differently here than an untrusted certificate provides no
additional security.  While one could argue that treating it with hard-fail
or some extra-special error will teach people that CA=True is unacceptable,
browsers are not in the how-to-run-a-CA education business.  Browsers cannot
do this for internal CAs that people run, which have lots of other errors.
Certainly there are automated checks that can be run, and OS X will fail in
its API implementation with an internally issued end entity certificate
asserting basic constraints true if it is not a self-signed certificate.
Android will soon be doing the same.  Rick said he would feel more
comfortable if someone were to test this trust-exception scenario to confirm
that they are not subsequently trusted by a browser.  Ryan said that
browsers should ensure that exceptions do not leak beyond the site that the
exception bypasses or is made for, but the general risk is no greater than
the situation of an untrusted certificate, and regardless, it is a serious
concern if a publicly trusted CA has violated the terms of a browser's root
store program.  

5.  Ballot Issues

OCSP AIA requirement (Remaining BR Issue 7) -- Ben said that he sent an
email out on Wednesday and wanted to confirm that everyone had received it.
Anyone interested in AIAs or OCSP Stapling should respond.  

BR Issue 15 (IDNs and new gTLDs)  -- Jeremy has a draft that he, Rick and
Robin are going to review for gTLDs.  Brad, Rick, and Geoff still need to
work on the IDN ballot.  The open source code that Brad made available still
needs to be tested by someone.  Rick said that he would have Symantec look
at the code and see how it can be incorporated into their systems.  Brad
said the code is being incorporated into an open source library and that the
previously presented ballot language is there for someone to pick up and put
into an independent ballot.  

Ballot 89 - EV Processing - Rick said that he condensed the issues into five
groups and that he is sending emails out regularly to get responses on the
meta-issues and that the arguments and counter-arguments are all documented
on the wiki at
https://www.cabforum.org/wiki/89%20-%20Adopt%20Guidelines%20for%20the%20Proc
essing%20of%20EV%20SSL%20Certificates%20v.2  He has sent out emails on 3
issues and has 2 more to go.  Ben said that we need to move these issues
forward.  Rick said that these discussions are all on the public list and
he'd appreciate it if everyone would take a look at them and provide
feedback.  He hopes to present a status report on all of these issues during
the face-to-face meeting where we can debate any open issues and bring them
to closure.

CAA (RFC 6844) - Phill updated everyone that CAA has been approved for
publication as RFC 6844.  He would like the Baseline Requirements to require
CAs to disclose whether they are going to do CAA records and identify which
of the validation mechanisms listed that they will implement with CAA, but
that at this stage of implementation it would be too difficult to make it
mandatory, if that is where we are as a group today.  If we are to have a
ballot ready to discuss at the face-to-face, Phill asked where to place that
provision in the Baseline Requirements?  Ben recommended that Rich might be
of some help.   Phill said he wants domain holders and certificate holders
to be aware that this is a facility that they can use, and he asked whether
everyone agreed with this stance.  Kirk said he would have to read the RFC
before he would be in a position to make any comment.  Phill said that he
would track down the publication status of RFC 6844 (published now at
http://www.ietf.org/rfc/rfc6844.txt). 

Ben also asked Phill about the must-staple OID, and Phill said that he did
raise the issue with the four main people at IETF and they had not taken any
action, although they had been adamant that it be in the PKIX space because
if people wanted to look at it and what it does, then it makes sense for it
to be in PKIX.  

6-7.  Working Groups

Audit - Kirk provided an update on the Audit Working Group.  Under the
current proposal, the criteria would be frozen at a certain date every year
and auditors would have to adopt changes to their audit standards within 6
months.  Then there would be an effective date that would be recommended to
all browsers (likely the date 6 months after the freeze date).  We cannot
force browsers to do it, but if just one browser does it effectively becomes
enforceable for all of the browsers. Audits would be split where part of the
CA audit is under the old standard and part of the CA audit is under the new
standard.  Don supported this approach.  If six months were to be the
deadline for the adoption of new audit criteria, then that would be the date
that we recommend that browsers to require.   We will still need to talk to
ETSI about this, possibly during the face-to-face meeting at Mozilla.  

Ben would like to move toward a model with chairs of working groups.  Even
though we generally all work on all of these things as one whole committee,
it would be good to have at least one committee chair, but two, three, or
even four committee / working group chairs would be fine.  People could be
on any working group, etc.  Kirk suggested that Ben send a request for
volunteers and if there are not enough volunteers for a particular group we
could start filling the group list with names of people thought to be a good
fit for a particular group, and then we would ask for their participation.

8.  Face-to-Face Planning

Ben said that he would post the proposed Face-to-Face agenda to a Google
folder because it is easier to edit spreadsheets there than tables in the
wiki.  Rick asked whether we would have another meeting before the
face-to-face.  Ben said that we did not have one planned, but that he would
send out an announcement for a F2F planning meeting to take place at this
time next Thursday, January 31st for those who are interested and can and
want to participate.  

9.  Any Other Business

Mert stated that he would submit revisions for the minutes of the last
meeting.  Turktrust would like 1.5 hours of time during the Face-to-Face
meeting to present findings and quantitative results and because KPMG
Netherlands would be auditing Turktrust on its new change and incident
management controls, which have already been implemented, and he expects
that he and his associate will be able to present those recent audit results
to the group.   He suggested that Wednesday afternoon would be the best time
for that presentation.

10.  Meeting adjourned until the Next Call -- Thurs. January. 31st for
Face-to-face Planning only.  Next telephone call following face-to-face will
probably be Thursday, 21st of February.

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