[cabfpub] Final Minutes for CA/Browser Forum Teleconference – May 25, 2017 (approved June 8, 2017)

Thu Jun 8 20:59:13 UTC 2017

Final Minutes for CA/Browser Forum Teleconference – May 25, 2017

Attendees: Arno Fiedler (D-TRUST), Ben Wilson (DigiCert), Bruce Morton (Entrust), Curt Spann (Apple), Dean Coclin (Symantec), Dimitris Zacharopoulos (HARICA), Doug Beattie (GlobalSign), Fotis Loukos (SSL.com), Frank Corday (Trustwave), Geoff Keating, Apple, Gervase Markham (Mozilla), Jeff Stapleton (Wells Fargo), Jeremy Rowley (DigiCert), Ken Myers (US PKI), Kirk Hall (Entrust), Leo Grove (SSL.com), Li-Chun Chen (Chunghwa Telecom), Mike Reilly (Microsoft), Neil Dunbar (Trustcor), Patrick Tronnier (OATI), Peter Miscovic (Disig), Rick Andrews (Symantec), Ryan Sleevi (Google), Tim Hollebeek (Trustwave), Tim Shirley (Trustwave), Tyler Myers (GoDaddy), Virginia Fournier (Apple), Wayne Thayer (GoDaddy).

1.    Roll Call

2.    Read Antitrust Statement

3.    Review Agenda

4.    Approve of Minutes: The Minutes of the May 11, 2017 CABF teleconference as amended were approved, and will be posted on the Public list.

5.    Governance Change Working Group update.  Ben said on the last call the WG accepted many red-line changes to the draft Bylaws amendments from the prior call.  It’s possible the current IPR Agreement will need to be amended to cover the new WG structure.  The WG also discussed how the IPR policy would apply to Forum members who do not participate in one of the new-style working groups – what obligations would those members have.

Virginia noted that few people call in to participate on the WG calls, and asked if that meant lack of interest or support.  She asked whether more people would participate if the WG met at a different time.  Kirk and Gerv said their lack of participation didn’t indicate lack of support, but rather lack of time plus confidence in the core group working on the new governance structure.  Kirk asked if the WG would have a complete proposal to discuss at the F2F meeting June 21-22, and Ben said he wasn’t certain.

6.    Validation Working Group update.  Ben said the main discussion on recent calls related to Ballot 190 on readopting several of the domain validation methods from Ballot 169, and there’s been extensive comment on the Public list.  A new draft will be posted soon.  Jeremy noted there were issues on how Ballot 190 could be interpreted, which should be cleared up.  Kirk suggested Ballot 190 should not be used to make extensive additional changes to BR 3.2.2.4, but should just readopt the methods with any clarifications that were needed.

7.    Policy Review Working Group update.  Ben said the WG had a call earlier in the day, and the WG looked at RFC 5280 to see if there is a definition of “certification authority” and how the term is used in 5280.  RFC 5280 is not consistent in how it uses the term CA – sometimes it refers to the organization, and sometimes to the system that is issuing the certificates.  So it’s hard to use 5280 to formulate a position the Forum should follow in the BRs.  The WG is looking to create a list of definitions and get consensus from the Forum first, then go through the BRs and do a replacement of terms to reflect the new definitions for clarity (e.g., use “CA Operator” and “CA System” instead of just “CA”).  Kirk thought that was a good approach.  Dimitris noted that changes in definitions may create unintended changes to the substantive places where the definitions are used, so the WG will have to be careful about that.

8.    Possible creation of a new Security Controls Working Group (to update Network Security requirements).  Kirk said that he thought Peter (who was not on the call) had volunteered to draft a new Working Group charter for this project.  Gerv confirmed, and said Peter had hoped to get a ballot drafted and approved by the time of the F2F meeting, but we are running out of time.  Kirk noted it could be a very simple charter, e.g., “consider changes to the Network Security requirements”, and Gerv noted it would also need a goal, end date, etc. but could be pretty simple.  Kirk asked Gerv if we would be willing to do a first draft of a charter, but Gerv said someone else from Mozilla would participate in this new WG and it might be better to have a future participant do the draft.  Dean suggested giving Peter a little more time.  Kirk said he would contact Peter again.

Kirk noted he had sent out a mapping of the CIS Critical Security Controls for Effective Cyber Defense to the existing Network Security Requirements created by Tim Crawford and Jeff Ward of BDO, and asked if there were any comments – would the CIS Controls be a good alternative to consider?  There were no comments.

9.    Ballot Status - Discussion of ballots.  Kirk started by asking if the Forum should consider Ballot 198 (.Onion Revisions) as “Invalid” because there was a discrepancy in the email-posted version versus the marked-up version.  Kirk noted that the replacement Ballot 201 could add a provision stating the earlier ballot was invalid, and Gerv said that made sense.  Ben said the proponents of Ballot 201 needed another endorser.  Wayne said GoDaddy would be an endorser, and the new ballot would proceed.

Kirk noted the Bylaws require a ballot to include a red-line or comparison showing changes to existing text.  There are different ways to do this that are left up to the ballot authors.  If someone uses a different method than typical (e.g., something using + and – marks to show additions and deletions), it would be best to explain the method being used in the ballot introduction itself.

Kirk asked if the Forum should consider a new Bylaw to deal with ballot questions (like Ballot 198) and voting questions (but not changes to the BRs, EVGL, or Bylaws, which would require a regular ballot)  – something like a seven day ballot with all members voting as a single class.  Kirk didn’t like the idea that the Forum would have to go through a full ballot to decide narrow procedural issues.  Perhaps the Governance Change WG would want to look at a possible Bylaws change.

Ryan asked what was wrong with using regular ballots for that, and Kirk said it seemed like overkill and too slow for resolving procedural issues.  Plus, what if a correction ballot on an ambiguous issue failed – where would we be then?  Ryan disagreed, but said he would wait to see a proposal to decide.  Gerv noted that these issues can be contentious, so a quick procedure may or may not be the answer.  Tim noted that when contentious, the members may want a quick resolution so the issue doesn’t linger.  Gerv noted that the normal two week ballot process allowed members who are not as engaged in Forum activities as others a greater period of time to address the issue and vote.

Kirk also raised the idea of adding a “consent resolution” process where limited issues (e.g., typographical corrections in the BRs) could be proposed to the members, and if no one objected in (say) seven days, the consent resolution would be deemed approved.  He noted this is done by corporations and governments all the time.  Any one member could object, and the resolution would fail.  Ryan said he is still opposed to that.  Kirk asked why, and pointed out that Ryan could object to and stop anything he didn’t like.  Also, we are currently doing editorial corrections in roughly the same way – Ben says what he’s going to do, and asked if anyone objects, but without a Bylaw authorizing that.  Ryan said the Bylaws do allow for editorial changes, and also said the current process of two weeks for a ballot allows for deliberation, but a consent process does not – seven days could be too short if a member is on vacation.

As a separate matter, Gerv said it might be useful in a ballot to allow the proposer to extend the discussion period beyond seven days if additional time is needed.  Virginia asked for those who are interested in these issues to participate in the Governance WG.

No other ballots were discussed.

10.  Profiling OCSP & CRLs.  Ryan noted there had been a lot of discussion on GitHub and on the mailing list about his proposal to set requirements in this area, and we were circling around one point he wanted more feedback on.  For many issues there didn’t seem to be any controversy, but there was disagreement around the use of delegated OCSP responders.  We need to figure out what that means for intermediate certificates – what should the lifetime of that delegated certificate be, and how do you balance out security risks from longer lived certificates.  Google is concerned that if you compromise the signing key for an OCSP responder, you basically take it down for an extended period if the certificate’s validity period is long.  He discussed factors on designing OCSP systems and secure zones.  The proposal was to limit the lifetime of these responder certificates to 90 days as an upper bound.  He acknowledged that if you have an offline CA, you would have to bring it online every 90 days to accomplish this.  There are also issues as to the validity period for CRLs.  The other alternative solution is for CAs to notify browsers directly about broken OCSP responder certificates.  Ryan wanted to hear from those who want longer OCSP certificate periods and their evaluation of security concerns.

Curt asked if the proposal assumed OCSP no-check was in the signing certs, and Ryan said yes, that was currently part of the requirements, and discussed technical issues.  One goal is to get to a world where OCSP stapling can be reasonably deployed by servers.  Perhaps over-long OCSP certificates should be rejected and clients should have to go get a CRL.  Curt asked if the spec was considering two different validity periods if the cert was coming from an offline CA versus an online CA.  Ryan said no.

Bruce said he’d like to have a discussion about when the OCSP keys are protected in hardware to the same degree as the CA keys are – why do we need a shorter validity period for OCSP certificates in that case?  Ryan said there could be a systemic failure on the CA side, it’s not just about key protection, and there is not a lot of guidance on secure OCSP systems.  Some CAs are very insecure in their systems, and some are more secure than he would have imagined.  Part of the goal of this discussion is to figure out what best practices are, and then see if we can codify language for that so the best practices become the required practices.

Bruce expressed concern that with a requirement of generating shorter duration keys he would have to go to a less secure policy than he currently has.  The changes Ryan is proposing would also require significant changes to his current infrastructure, and he needs to be convinced this is more secure than what he is currently doing.  Ryan agreed that was the right sort of discussion to have.  If we agree on the ultimate goal and on the potential risks of compromise of an OCSP system with no possible revocation, what is the technical solution, and does it also meet the business needs.  Once we agree on the goals, there may be multiple paths to achieving them.

Bruce asked what the approach would be for resolving these issues of system configuration and security – a number of CAs have developed their own OCSP systems, while other CAs have purchased OCSP systems, and CAs have been doing this for ten years or more.  The people on the Forum calls may not have the technical expertise to talk to the right depth on these issues.  There could be a number of secure implementations that could be done for OCSP deployment.  Ryan said that a CA who thought it would be hard to go to a 90-day OCSP cert could describe how it had mitigated some of these security concerns on the list.

Bruce said he wasn’t sure he wanted to put out public information on how his company had designed its OCSP systems, so he is afraid of the public list for this purpose.  Ryan said the goal is to define what’s good and what’s bad, and a public discussion is intended to do that, like other Forum discussions, but if there is a way to avoid disclosing the most sensitive information perhaps that is possible.  Bruce said he’s open to having a discussion, but not necessarily to publish it to the world for security reasons.  He suggested a working group or offline discussion, and not solely via email on public lists.  Ryan said perhaps the discussion can happen via the Management list under the Bylaws, not the Public list to discuss the “what”.  After that, the solutions can be discussed on the Public lists.   We need to have a record also of who contributed what for IPR purposes.  Bruce agreed that discussion on the Management list seemed like a better approach.  Ryan said the group could take further discussion to the Management list for risk assessment purposes.

Curt asked if the 90 day limitation proposal included a rotation of keys, or was that optional.  Ryan said that was not required right now, and it was a good question – there are many options there, depending on the overall OCSP system structure.  Curt asked on the OCSP no-check – if no-check is in an OCSP delegated cert can you then go do a CRL check, or clients may be inclined to do a CRL check even if the OCSP extension exists?  Ryan said this was covered in RFC 6960, and read relevant provisions – you can check revocation via CRLs, but those don’t work with stapling.

11.  Next F2F meeting: June 20-22, 2017 Berlin (D-Trust).  Review first draft of F2F Agenda Items; Tuesday activity.  Kirk noted he had circulated a first draft of an Agenda for the meetings and asked members to email to him any additional items.

12.  Any Other Business.  There was no other business.

13.  Next call June 8, 2017

14.  Adjourn

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