2017-04-27 Minutes

Minutes for CA/Browser Forum Teleconference 27 April 2017

Attendees: Arno Fiedler (D-Trust), Atsushi Inaba (Globalsign), Ben Wilson (DigicertBruce Morton (Entrust), Christopher Kemmerer (SSL.com), Connie Enke (SwissSign), Curt Spann (Apple), Dean Coclin (Symantec), Dimitris Zacharopoulos (Harica), Doug Beattie (Globalsign), Erwann Abalea (DocuSign), Fotis Loukos (SSL.com), Frank Corday (Trustwave), Geoff Keating, Apple, Gervase Markham (Mozilla), JC Jones (Mozilla), Josh Aas (Let’s Encrypt), Ken Myers (US PKI), Kirk Hall (Entrust), Mads Henriksveen (BuyPass), Masakazu Asano (GlobalSign), Neil Dunbar, Trustcor, Peter Bowen (Amazon), Peter Miscovic, (Disig), Rich Smith (Comodo), Rick Andrews (Symantec), Robin Alden (Comodo), Ryan Sleevi (Google), Sissel Hoel, (Buypass), Tarah Wheeler (Symantec), Tim Shirley (Trustwave), Tyler Myers (GoDaddy), .

1. Roll Call
2. **Read Antitrust Statement **
3. Review Agenda. The Agenda was approved.
4. (a) Approve Minutes of CABF teleconference of April 13, 2017 as amended. The Minutes were approved.

(b) Complete F2F meeting minutes: Kirk noted that the following Minutes segments had not been posted to the wiki, and asked the volunteers to complete the missing Minutes:

Jeremy – Validation WG

Doug– Microsoft Program Update

Liang – 360 Update

Andrew Whalley – The Role and Relationship of the Forum

Kirk said he wasn’t certain if anyone intended to post Minutes for the guest presentation by Eric Mill – GSA update. He will ask Eric if he wants to provide minutes or a summary. Kirk also noted that he had asked the leader of each breakout group for the three Future of Web sessions to provide Minutes, but none had done it so we will not provide Minutes for those sessions.

(c) Update on Cisco-provided WebEx account (Jos, Ben). Kirk noted that Cisco had graciously created a WebEx account that the Forum could use for its teleconferences and also for working group meetings. Ben and Dean said they would try using the new account for some working group meetings first. Credentials will only be provided to a limited number of leaders to avoid misuse.

5. Governance Change Working Group update. Dean said the WG was making good progress on draft amendments to the Bylaws. We will start using Webex on our bi-weekly calls and the goal is to have a complete set of documents to implement the governance changes by the time of the next F2F meeting in June.
6. Validation Working Group update. Ben said the WG had met the prior week and worked on a number of draft ballots, which should be ready soon.
7. Policy Review Working Group update. Ben said the WG had a meeting just before this Forum meeting, and continued to work on clarifying the use of terms like CA, CA operator, etc. in the Baseline Requirements. They were also trying to better incorporate RFC 5280 terminology in the BRs.
8. Draft Code of Conduct. Virginia was not on the call to review her draft of the proposed Code of Conduct. Tarah, who had volunteered at the F2F to move forward with this project, said she had reviewed the draft and thanked Virginia for all her hard work. There were no comments on the draft from the members. Kirk said the topic would be on the agenda for the next call, and he hoped Virginia could participate on that call to provide an overview.
9. Ballot Status. Kirk noted the status of the following ballots:

Ballots in voting period: Ballot 197 – Effective Date of Ballot 193 Provisions – Ends May 3.

Ballots in discussion period: Ballot 198 – .Onion Revisions – Ends May 1. Ballot 199 – Require commonName in Root and Intermediate Certificates – Ends May 2.

Ballots in IPR Review Period: Ballot 189 – Amend BR 6.1.7 to clarify signing by root keys (ends May 15); Ballot 194 – Effective Date of Ballot 193 Provisions (ends May 16); Ballot 195 – CAA Fixup (ends May 18); Ballot 196 – Define “Audit Period” (ends May 18).

Kirk noted that other draft ballots had been listed on the Agenda, and asked if anyone wanted to discuss any ballots during the call.

Ballot 198: Ryan said the ballot adds to the EV Guidelines the Tor service descriptor because the onion name is essentially a truncated hash of the public key used to identify hidden services. The subject is computed by generating a 1024 bit RSA key and hashing that with SHA1; the truncated hash of that is then encoded and the onion name results. In the discussion as to why we are permitting onion certificates, the goal is to ensure that there is no ambiguity as to how the naming is done. In this ballot the goal is to ensure the certs issued for onion clearly identified the public key that they are attesting to so if someone is exploiting a SHA1 collision they will do so by generating a different public key. A goal of the ballot is to put additional information in the EV certificate to make sure you are going to the right site. In the original onion ballot it was not a required extension, so the intent in this ballot is to fix that oversight in the earlier drafting to make it mandatory.

Ballot 199: Gerv noted there was a discussion going on concerning the wisdom of allowing a certificate to be reissued with the same name but different metadata. Gerv noted his draft ballot would not permit this. Bruce had suggested the use of the same name might be useful in some circumstances, but had no concrete use cases – Gerv asked people to come forward if they had any. Kirk asked Gerv why the ballot was originally proposed, and Gerv said it was mainly housekeeping because the current rules would allow issuance of an intermediate with no common name in it, which seems wrong if you want to avoid ambiguity.

Ben asked if the ballot would prohibit reissuing a subordinate CA certificate that had the same public key, same common name, but different metadata in it. Gerv said that was what the current discussion was about. Ryan noted there are a couple of attributes that arguably are in this gray area where we need more discussion and feedback, such as cross-certification cases and AIA where you later have to add that to assist in chain building. This needs to be discussed because there are a lot of ways to reissue that cause negative security consequences, so we need to figure out what the positive use cases are to support those.

Bruce said Entrust definitely supported requiring common names. If the ballot is just a clean up to put that in the BRs, then he supported it, but if it’s also a security ballot then he’s prefer that discussion happen separately, as the group has zero data on that. Ryan said the ballot is a little of both – when you add the requirement of a common name you want to make sure you don’t introduce additional risk or challenge. Gerv thought that discussion might take more time than was left for Ballot 199’s discussion period. It would be more than a minor change to add permitted use cases to the ballot a day before voting starts. On this basis, it might make more sense to remove the uniqueness constraint from this ballot and put in a future ballot. Ryan said he saw a risk from someone reading these requirements and end up with the same FQDN for two different logical CAs with two different keys – a CA in Taiwan had run into this situation.

Gerv noted that the RFC key words used “should” for something you normally should do, but where exceptions were permitted for a good reason – maybe that should be used in this ballot instead of the current “must” for unique names for now, and we can come back later and change that if we decide that is too permissive. Ryan agreed. Peter mentioned the GIAG2 example of reusing the same key and name with changing other things in the certificate, plus we have seen several CAs change the key for the same name and use things like authority key identifier to disambiguate any end entity certs – so changing “must” to “should” in the ballot is a viable path forward.

Kirk noted there were about a dozen other pending ballots listed on the Agenda and asked if anyone wanted to talk about any of them.

Mandating RFC 3647 format. Ryan noted he had put out two ideas (not listed as a ballot on the Agenda) and wanted feedback. One touches on RFC 3647 and mandating its format in CPs and CPSs. The current wording would require updating to that format by December 8. One question was, should a CA’s CP/CPS use the same headings and sections as RFC 3647 – the Forum has done that for its own Baseline Requirements, with “No stipulation” for those sections that aren’t relevant. We don’t rename section headers, but may introduce new subsections. Ryan asked if that was controversial, or there were concerns, and would that make it harder to convert to the format over the next six months.

Ben asked if CAs could substitute certain words in RFC 3647 headings – e.g., change “Subscriber” to “User”. Also, what if the CA is writing the document in another language (even with an English translation) – you may need different words and may not want to do a literal translation because it may not make sense. Ryan said that was a good point – he had seen a translation from one CA where they had introduced a Section 9 to cover issues like that, and it was hard to understand in the English translation what they were doing. That kind of substitution makes him nervous – he wants to make sure all information is present and there is consistency, so he leans against it. There was also discussion of RFC 3647 not using capitals in titles, except for the first word. Ryan said he would update his draft in GitHub, and wanted more input.

Ballot re OCSP Profile. Ryan next mentioned another ballot concerning the OCSP profile. He had floated a basic outline to capture a profile for OCSP responses and requirements for OCSP responders. Under the BRs we put the profile of how the request works and what sort of requests are generated and other requirements in Section 4, but it’s actually describing here’s how the request works fail to specify the OCSP Profile in Section 7. There is an opportunity to clarify this.

We’ve got a lot of requirements in the BRs, some inherited from WebTrust for CAs such as physical security controls, etc. In areas of “no stipulation”, for some there is nothing that can be said, but others were perhaps overlooked. Some of the OCSP language in the BRs is outdated, plus there are some other changes that would be useful regarding delegated OCSP responder certificates – right now we don’t have a specified maximum lifetime, and a compromised OCSP certificate could compromise the whole revocation infrastructure system. Ryan is working with GlobalSign to deal with RFC 5280’s recommendation to keep such delegated OCSP responder certificate lives short, such as 30 days for a maximum validity period. Ryan would like more feedback on these proposals, some of which could affect operations. We should first formulate an ideal end state that all can accept, and then figure out how to get there – clearly we will need time to implement any changes. We want a vision of OCSP that will support stapling, high availability, and timeliness to help promote stapling.

Ballot 190: Ryan asked if Ben knew what the status of Ballot 190 on validation methods was – it had been withdrawn over concerns with Section 2. He noted Peter had suggestions on how to incorporate Section 2 into Section 1. Gerv said he wanted to see Ballot 190 move forward, and offered his help. Ben said Jeremy had been busy which had caused the delay. Ryan also offered to help. Kirk noted he had drafted language to incorporate Section 2 into Section 1, and would resend to the list.

Membership Rules Ballot. Gerv raised his membership requirements cleanup ballot and asked if there were endorsers. Kirk mentioned some comments he had forwarded – membership suspension for CAs would occur exactly 15 months after their last WebTrust audit, which might be too soon as audits are due no later than 15 months after the last audit, and there can always be last minute delays with the auditor. Gerv noted that suspension is a light-weight process that is easily reversed, so that should not be a great concern if an audit is a little bit late, and it’s better to match the time period with the audit requirement date.

Kirk said his second concern is that the new membership suspension rule is not self-enforcing – how does the Forum learn a member is in suspended status, how is notice provided, what is the effect on a vote, etc.? He suggested a procedure be included to determine all this publicly, and made suggestions in his email to Gerv. Geoff agreed it was necessary to have membership status known at the time of a Forum vote, and not challenged later. Gerv discussed how the rule would apply to a CA with multiple roots where the audits were late for some but not all roots. He will draft an updated ballot.

10. Next F2F meetings: June 20-22, 2017 Berlin (D-Trust) – Arno said the Forum had invited Dr. Jens Bender from “Bundesamt für Sicherheit in der Informationstechnik Referat D13 – eID Technologies and Smart Cards” to be our speaker on topics like e-Identification, eIDAS and Website Certificates. We will finalize the title of the lecture in May.
11. Preliminary discussion F2F Agenda – June 20-22 Berlin. Kirk asked if anyone had preliminary ideas for the next F2F agenda. Dean thought the breakout sessions on the Future of Web PKI and GitHub training in North Carolina had been useful, and suggested we might want another session on Network Security requirements in Berlin. Gerv thought it might be better to wait a bit before more breakout sessions as we did for the Future of Web PKI, but wondered who was going to follow up on the discussion about Network Security at the last session.

Dean recalled that several people had intended to move forward on a possible replacement for the Network Security requirements, possibly through a new working group or subcommittee. Gerv thought two or three people were going to come back with some specific ideas. Ryan noted that Jody is a fan of CI Security, and he thought people were going to look at those standards in depth and try to figure out if they would be a good starting point for the Forum, plus talk with the auditors about possible changes.

Kirk asked if the Forum should create a new Security Controls working group to work on this. Dean noted there had been interest in this, but there was already a lot going on. He suggested adding new Security Controls as its own topic again at the next F2F, but this time with some concrete action plans for moving forward. Kirk asked members to provide suggestions for other full sessions in Berlin.

The last F2F meeting of the year would be Oct. 3-5, 2017 in Taipei, hosted by Chunghwa Telecom. Dean noted the hotel for the meeting had been changed, and the updated information was on the wiki.

12. Any Other Business. Wayne noted that the Forum’s email server had crashed two days in a row, so delivery of some messages would be delayed.
13. Next call May 11, 2017
14. Adjourn