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

[Ben Wilson]

If you join for a portion of the call and want to be listed as in
attendance, just let me know by email after the call and I’ll add you to the
minutes.  

From: Moudrick M. Dadashov [mailto:md at ssc.lt] 
Sent: Friday, February 01, 2013 1:28 PM
To: ben at digicert.com
Cc: public at cabforum.org
Subject: Re: [cabfpub] Notes of meeting, CAB Forum, 10 January 2013

 

Hi Ben,

do you count those on skype? If the voice quality remains as stable as it's
been on the last 2 calls, I'll be happy to join again.

Thanks,
M.D. 

On 1/31/2013 8:00 PM, Ben Wilson wrote:

Notes of meeting

CAB Forum 

10 January 2013

 

1.   Present:  Maarten Van Horenbeeck, Stephen McHenry, Atsushi Inaba, Ryan
Koski, Gerv Markham, Brad Hill, Dean Coclin, Rick Andrews, Robin Alden, Mert
Ozarar, Atilla Biler, Cagdas Funda, Jeremy Rowley, Eddy Nigg, Sissel Hoel,
Ryan Sleevi, Steve Roylance, and Kirk Hall.  

2.   Agenda Review: the agenda was reviewed and Ben mentioned that Phill
Hallam-Baker had contacted him previously to make sure that CAA was
discussed, and he thought it could occur later after the discussion of
Turktrust.  Phill was not on the call, but joined near the end of the call,
and we discussed CAA under Item 9. Other Business.

3.   Approve Minutes of 6 December 2012:  The minutes of 6 December 2012
were approved as published.  

4.  OCSP AIA requirement (Remaining BR Issue 7)

Ben said that we need to wrap up the correction needed on BR Issue 7
(Mistake in Exhibit B -- Stapling is not an exception to having the OCSP AIA
in a certificate)

5. WebTrust / ETSI Audit Implementation Cycles

Dean said that we need to coordinate better on implementation timeframes and
auditability.  A working group was formed to hammer-out the details.
Members of the working group are Don Sheehy, Iñigo Barreira, Dean Coclin,
Kirk Hall, a representative of Google (TBD), Kelvin Yiu/Tom Albertson, Gerv
Markham, and Jeremy Rowley.  The objective/goal of the working group will be
to come back to the group as a whole with a recommendation of how
coordination among document revision cycles for requirements, audit
criteria, auditing, and browser compliance should work.

6.  Discussion of TURKTRUST facts

Mert and Atilla presented the facts of the Turktrust-issued certificate to
EGO that had CA=True.  Atilla explained that they had provided an update on
their web site and via email.  The event occurred on August 8, 2011, prior
to / during preparation for audit certification.  Since November 2011
Turktrust has been compliant with ETSI audit requirements.   Then in
December 2012 they discovered the faulty certificate, and have now improved
their existing Change Management procedures. The post-issuance logs examine
certificate contents and extensions.  These are checked by an internal audit
process.  He also said that they have also discussed the case with their
KPMG-BSI auditors who will perform an additional limited scope audit for
change management, incident management, and internal audit processes.

Ben asked about the Checkpoint Firewall issue and whether other certificates
besides the one issued to Google had been discovered.  Atilla recounted that
the Google certificate was detected by Google, but he has no further
information about any detection or usage of any other certificate out of the
EGO domain.

Rick Andrews asked about Turktrust’s plans to implement the Baseline
Requirements and the Network and Certificate System Security Requirements.
Atilla said that ETSI requirements for networking security have all been
implemented and the Baseline Requirements that are referenced in the final
ETSI standard are implemented and audited by their auditors.   Rick noted
that the current Turktrust CPS did not mention the “Baseline Requirements.”
Atilla said they hadn’t yet declared conformance to the Baseline
Requirements, but they will declare at some point.  They have had
discussions with KPMG-BSI Netherlands, their ETSI auditors, and they will
first comply with ETSI audit requirements and then CABF Baseline
Requirements. 

Stephen McHenry asked what procedures Turktrust had in place to detect
whether any subCA certificates had/have been issued.  Mert said that they
had checked the audit logs for any certificates with those CA=true
condition, and the only two certificates they found were the EGO one
(ego.gov.tr) and one to e-islem.kktcmerkezbankasi.org.  In addition to the
existing controls coming from ETSI requirements, currently Turktrust has
implemented an independent post-process control and a runtime control that
runs live.   The post-process control can additionally be run as a chron job
to review such fields as BasicConstraints, AIAs, and the pathlengths of
subCAs. Stephen asked how quickly are they detected after issuance, assuming
that somehow the certificates make it past the current controls due to
software errors, runtime errors, or whatever-to detect the situation after
it has occurred.  Mert said that they had previously explained how the
misuse of the profiles had originally caused the problem and that if the
runtime controls do not prevent a certificate from making it to the database
the scan can be run on demand through the certificate database as a
completely independent process that checks the certificates.  Stephen said
that Turktrust should run the process routinely because software errors do
happen.  Mert agreed and said they would run the process as a chron job
periodically, but that he believed that they already run it daily already.

7.  Discussion of preventative / remedial measures

Ben asked for discussion on additional preventative or remedial measures.

Jeremy said that he was working on an additional set of CA controls, such as
developmental controls, because we already said during adoption of the
Baseline Requirements and Network Security Requirements that we were going
to come back and address some of the issues raised by the Diginotar
situation later.  He said he hoped to have a draft out soon and that
volunteers were welcome.  Robin said he would help.  

Rick asked whether Turktrust only issued certificates to Turkey, and if so,
then Name Constraints might be used as a preventative measure?  Atilla said
that they do not issue any certificates in the US so far, but that doesn’t
tell the whole story because they issue certificates to .com domains and to
many sites all around the world that have physical locations and data
centers within the United States.  Atilla said that therefore a name
constraint of .tr would not work, because there would be too many negative
effects.  

Maarten asked if anyone knew whether the EGO subCA certificate was installed
on the Checkpoint Firewall intentionally to inspect traffic.  Atilla said
that he does not know because it happened at a customer site.  What we do
know is that at one point it was installed on a server and was detected by
Chrome.  The assumption is that the firewall was intended to inspect
traffic, but he is not sure whether EGO or Checkpoint Turkey will release
any announcements or final reports, but that hopefully they will. 

Eddy suggested that we scan certificate databases at EFF and elsewhere for
certificates on SSL servers where CA=true and other similar criteria.  Ben
suggested that Eddy write a note to EFF, Ivan Ristic, Yngve Pettersen, and
Bernhard Amann at Berkeley to see if they are interested in running such
scans, even if only for academic reasons or out of curiosity.

8.  Logistics of next face-to-face meeting

Gerv said that they are expecting at least 24 people and there will be
enough seats, but any one arriving beyond that number might anticipate
standing or sitting along the wall.  

9.  Any Other Business

Ben asked about involvement of invited experts like Yngve who sign the IPR
Agreement.  They have posting privileges on the public list, but what about
their ongoing allowed participation?  While it depends on each proposal, for
instance with the revocation group, those who have signed the IPR Agreement
should be able to participate.  Dean said he thought it was a good idea to
improve the rules in this area. Kirk noted that while we have observer
status for entities like WebTrust, ETSI, and PayPal, but that there are
plenty of people in the world who might qualify as experts and that allowing
participation just on that alone won’t work and we do allow them to
participate in working groups—so he would oppose opening up greater
participation in meetings and regular phone calls to that category.  Kirk
said he was open to working with Dean on this issue.  Ben said that the
working group is one approach to segregating discussions off from the main
group, but the other approach is to have very stringent rules on which
experts will be invited or qualified to participate as invited experts. With
the first approach we’d have to make sure that there is a working group in
which someone interested could participate, with the second approach we’d
have to decide what the qualification steps and voting percentage would be
to approve someone as a permanent invited expert.  There would have to be
sufficient rules around the latter approach so that we would not be accused
of being too exclusionary.  Jeremy said if all of the discussion took place
on the public list, the only thing that such individuals would not have
would be voting rights.  Ben noted that they would get to participate in
live discussions.  Kirk said that where we determine that an individual has
enough expertise we could invite them to speak as a guest.  Ben agreed.

Phill joined the call and those who stayed on continued with a discussion of
the CAA record proposal. Phill said he’d like to put forward a proposal that
CAA be required.  Rick said that there are several solutions that have been
proposed and he wondered if we mandated CAA whether people would stop
looking at the alternatives or whether they would implement “all of the
above” or what.    Phill said that CAA does something that nothing else
does, which is it allows companies to say, “do not issue certificates for my
domain unless you’re one of my approved CAs.”  Everything else, CT and DANE,
are looking at either client enforcement or detecting anomalies and
reporting them.  Because CAA is different than CT or DANE, adopting one
solution does not exclude the other.  Ben noted that during our December
call we discussed using the word “should” rather than “shall” except when
necessary to mandate a global solution.  Phill said that CAA only requires
that you look at the CAA record, nothing other than that.   Ben said he
understood Phill’s position on how CAA would be implemented, but that as
Phill is trying to draft and put forth a motion that will pass, maybe he
should consider using the word “should” rather than “shall.”  Phill said
that it may not need to be a “shall” depending on how CAA is adopted by the
domains --- whether it is by the 100s or the 1000s.  Jeremy said he was
apprehensive about adopting a requirement in the CA/B Forum if it were seen
as an abuse by the CAs in locking in existing customers making it harder to
get a certificate without a corresponding benefit.  Phill said that the
issue had been raised at the IETF and so they specified a mechanism for
obtaining the data and stating that how you treat that information is up to
you.  So, if you state, “we don’t observe the records in this TLD data,” so
long as it is in writing, you are complying with the IETF.    Ben said that
it will be interesting to see what the registries do.  Phill noted that the
registrar for xxx was trying to place a variety of controls on their
registrants.  Rick said that in discussing concerns with encountering CAA
records he wasn’t sure how difficult it would be to get the customer to just
go off and update their CAA record.  Ryan K. said he knew about the
previously expressed CA concerns, but that it also will increase the support
time burden and some CAs may even start to require customers to set up a CAA
record before they’ll issue a certificate to the customer and the CA could
have a tool during the application process that says, “hey, you don’t have a
CAA record,” so I share these concerns.  Ben asked that anyone interested in
endorsing Phill’s proposal coordinate with him, and Rick advised Phill that
it would be good to also get at least one browser to endorse it as well,
since he will need more than 50% of the browser vote, too.

10.  Meeting adjourned until the Next Call -- Thurs. January. 24th






_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130201/35a2f6d1/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5460 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130201/35a2f6d1/attachment-0001.p7s>