2016-09-29 Minutes
Minutes September 29, 2016
Attendees: Andrew Whalley (Google), Anuj Saxena (Network Solutions), Arno Fiedler (D-Trust), Atsushi Inaba (Globalsign), Ben Wilson (Digicert), Billy VanCannon (Trustwave), Bruce Morton (Entrust), Connie Enke (SwissSign), Curt Spann (Apple), Dean Coclin (Symantec), Dimitris Zacharopoulos (Harica), Doug Beattie (Globalsign), Erwann Abalea (DocuSign), Geoff Keating (Apple), Gervase Markham (Mozilla), Giuseppe Cimino (FPKI), Inigo Barreira (Startcom), Jeff Stapleton (Wells Fargo), Jody Cloutier (Microsoft), Josh Purvis (Cisco), Ken Myers (US PKI), Kirk Hall (Entrust), Li-Chun Chen (Chunghwa Telecom), Mads Henriksveen (BuyPass), Neil Dunbar (Trustcor), Peter Bowen (Amazon), Peter Miscovic, (Disig), Phillip Hallam-Baker (Comodo), Rich Smith (Comodo), Rick Andrews (Symantec), Robin Alden (Comodo), Ryan Sleevi (Google), Tim Shirley (Trustwave), Virginia Fournier (Apple), Wayne Thayer (GoDaddy).
** Roll Call**
Antitrust Statement was read by Robin
Review Agenda – no changes
Approve Minutes of Sept. 15th – Dean asked if there were any edits to the draft minutes. Rick said he had sent notice of a typo to Kirk, and Kirk said he would correct that for the final minutes. There were no other edits, and so the minutes of September 15th were approved and will be posted to the public list.
Ballot Status
Dean asked if there was any discussion on ballots (other than the election ballots). Peter posted a proposal for defining how the Issuance Date for a certificate must be represented in a certificate. It has generated some discussion, and will likely move to a ballot soon. Dean stated that we may need to hold new ballots in a queue for a bit based on the IPR discussion later in the call.
- Continuing the discussion on CAA:
Rick summarized the discussion about next steps for CAA on the CABF list as divided between those who want to use a “go slow” approach to deploying CAA and a “go fast” approach. “Go slow” would mean that CAs would have to implement CAA checking, but would be able to soft-fail on a CAA failure (e.g., discuss with the subscriber and proceed if the subscriber approved). “Go fast” would mean that all CAs would have to hard-fail on a CAA failure.
Gerv reminded us of a third option being discussed: make soft-fail the default, and define a way for domain owners to specify hard-fail in their CAA record. Why would anyone choose soft-fail? Perhaps when first deploying a CAA record, the domain owner would use soft-fail for a test period, then move to hard-fail once they were confident that their CAA record was properly configured. Phil proposed deploying it in the opposite sense: make hard-fail the default, and specify a way for domain owners to specify soft-fail in their CAA record.
Rick made a distinction between two types of failures: CAA record mismatch (the CA sees one or more CAA records but they don’t include a domain name identifying that particular CA) and DNS error. Someone then suggested that we allow soft-fail for DNS errors. Gerv thought that if there was a DNS error, the CA should first try again several times (perhaps from a different location on the Internet) and then hard fail and ask the customer what’s up with their DNS! Rick wondered if anyone would be concerned about a DDOS attack against a subscriber’s DNS server. What if the CA mis-configured its DNS resolver to hit the wrong IP address, and so all CAA checks resulted in DNS error and therefore cert issuance? Ryan said CAA requirements should be clear enough so that all CAs and users could implement, even if their technical skills were limited. There was some discussion about making sure the CA’s actions would be auditable. CAA failures due to malicious or unintended DNS configuration should be discoverable by the auditor.
Governance Change Working Group update. No meeting was held this week so there was no further update.
Validation Working Group Status. Ben said there were a number of issues for the Validation Working Group to look at, but its bi-weekly teleconference time slot had been taken by the Policy Review Working Group, so Jeremy would need to find a new time slot. Kirk said there were perhaps three pending issues mentioned in the CABF Minutes from Sept. 15, and Ben said he would mention that to Jeremy as a source of working group agenda items.
Policy Review Working Group. Dimitris discussed updates to Section 6.1.7 which he has distributed to the list concerning issuance of time stamping certificates directly from a trusted root. Kirk noted the BR was ambiguous on this point, asked if Dimitris was in favor of or opposed to allowing time stamping certificates to be issued directly from a trusted root. Dimitris said the Baseline Requirements for Code Signing proposal was clear that time stamping certificates must be issued from an Intermediate so the majority seems to consider that it is prohibited, at least from a Root in a hierarchy that issues SSL certificates. He will likely seek endorsers before moving to a ballot to clarify BR 6.1.7 on this point.
Application of current IPR policy. Kirk summarized the memo which Dean circulated to the management list regarding the Forum’s current IPR policy. In essence, the Forum has not been following the IPR Policy as to the procedures to follow in adopting new guidelines or amendments to existing guidelines. The IPR Policy specifies the following order: first, draft a potential ballot, next, the Chair should circulate the ballot and guidelines with a Review Notice. Then, the members will have an IP review period of 30 days for guideline amendments and 60 days for adoption of entirely new guidelines. During the review period, members should submit Exclusion Notices to the Chair if they have Essential Claims that would be infringed by the guideline, with specifics, and must indicate if they will offer a license on royalty-free terms in compliance with the IPR Policy or not offer a license.
If no Exclusion Notices are filed within the 30 or 60 day review period, the Forum can proceed to a vote in its normal manner. If Exclusion Notices are received, the Forum should form a Patent Advisory Group (PAG) to evaluate the Essential Claims and offer recommendations to the Forum, such as drop the ballot, amend the guidelines to avoid the conflict, proceed with the ballot, etc. After that, the Forum would vote on the ballot (including any amendments), drop the ballot, etc.
Kirk said our actual process to date was to approve ballots first, and then sporadically send out Review Notices afterward. When we have received Exclusion Notices, they were not always in the correct form, and we simply posted them and did no evaluation. We also never took a vote to approve (or reapprove) a ballot after the Review Notices were sent, so we have not been following our IPR Policy. He continued that we had been following the balloting procedures of our Bylaws (which are not in conflict with the IPR Policy), but not the IPR Policy. He noted the IPR Policy provided valuable protections to the members and gave them necessary information they needed before voting to approve a new guideline, so we should try to follow our policy in the future.
Kirk proposed two steps: (1) all ballots from that point forward should follow the IPR Policy procedure strictly, and (2) to make up for the past, we should re-adopt the entire Baseline Requirements and EV Guidelines as they exist through the most recent completed ballot, sending out a draft re-adoption ballot and Review Notice, allowing 60 days to review, dealing with Exclusion Notices, and then voting to readopt again. He suggested two ballots, one to readopt the entire BRs (except for BR 3.2.2.4 on domain validation methods) and a separate ballot for BR 3.2.2.4. Because we are only likely to receive Exclusion Notices for BR 3.2.2.4 (which will require creation of a PAG, etc., which could take time), we could probably complete re-adoption of the balance of the BRs and EVGL in a much shorter period that way.
Finally, Kirk noted that some had asked if this analysis meant that the current BRs and EVGL were not enforceable, and what it meant for the recent Ballot 169 updating the domain validation methods. Kirk noted that the Forum itself does not impose any requirements on CAs (but only adopts non-enforceable best practices), and it is the browsers through their trusted root programs that impose the CABF guidelines on participating CAs (as checked by WebTrust and ETSI auditors). For this reason, in Kirk’s personal opinion CAs should proceed at this point as if nothing had changed and that CA compliance with the current BRs and EVGL would still be required by the browsers. Virginia cautioned, however, that whether or not past attempts to comply with the IPR Policy were effective or not, there had been several Exclusion Notices filed by CAs listing some IP that may or may not be infringed by portions of the existing BRs and EVGL, so that CAs should consult with their legal counsel and proceed at their own risk concerning the IP listed in those Exclusion Notices.
Ryan said that as far as Google was concerned, it would expect CAs to continue to comply with the current guidelines for now. He also said he would prefer not to split the ballots for re-adoption of the existing BRs and EVGL in two as Kirk had suggested, but keep them together in a single ballot to simplify review. Someone said it would be inefficient to go through this entire process for a draft ballot, only to have it fail in the end, and suggested we start with a non-binding straw poll on the draft ballot – if the straw poll fails, the draft ballot would be dropped, but if it passes, we would follow the review procedure laid out in the IPR Policy, and then hold a real vote on the ballot (at which time members could change their minds from the straw poll). There was also a suggestion that the ballot adopting our current IPR policy (v1.2) be readopted, but Virginia responded that was not necessary as the IPR Policy only applies to “guidelines” and the IPR Policy was not a guideline. The matter will be discussed further at the face to face meeting in Redmond in October.
Membership status of WoSign, Startcom, Qihoo 360: Dean said that given the recent disclosures from the Mozilla Foundation on these 3 entities, the concern for the Forum is member/voting status and whether these three members should share a single vote. In addition, it was brought to the Chair’s attention that Ballot 171 concerning ETSI standards passed only because 360 voted from the browser side (no other browser voted and the Bylaws require at least one browser to vote in favor of a ballot) which made quorum. Kirk said he had seen research showing shared ownership of the three companies on the Mozilla website, but he believed the Forum should not simply rely on that but instead gather the information in the Forum before making any decisions. While the Bylaws say that only one vote will be accepted per Forum member and affiliates should not vote, there was no definition of affiliate in the Bylaws and the Forum should clarify that. Dean will send a note to the 3 companies, asking them to clarify their ownership status and who they want to be represented in the Forum.
SHA-1 Exception process. Dean noted that Symantec will be submitting a SHA-1 exception on behalf of First Data later today. Billy noted that Trustwave will also be submitting an application on behalf of TNS in the next few days.
Ballots 177/178 – Kirk Hall was confirmed as the new Chair of the Forum, starting right after the F2F meeting in Redmond, WA. The ballot for vice chair is now active with voting concluding on October 6th. In response to a question of when the terms start and end, Kirk noted that the dates were essentially set by the ballot for the first election of a Chair, and that the start date for a new Chair’s was approximately October 22, running for two years from that date.
Any Other Business – Dean asked members attending the F2F meeting to indicate their dinner choice on the wiki. He is working on the draft agenda on the wiki.
Next Forum teleconference will be on October 13th.
Adjourn