2015-09-03 Minutes
CA-Browser Forum teleconference call, Sept. 3, 2015
Attendees: Atsushi Inaba (Globalsign), Atilla Biler (TurkTrust), Ben Wilson (Digicert), Billy VanCannon (Trustwave), Bruce Morton (Entrust), Burak Kalkan (TurkTrust), Dean Coclin (Symantec), Dimitris Zacharopoulos (Harica), Doug Beattie (Globalsign), Eddy Nigg (Startcom), Jeremy Rowley (Digicert), Jody Cloutier (Microsoft), Kirk Hall (Trend Micro), Kubra Zaray, Turktrust, Li-Chun Chen (Chunghwa Telecom), Mads Henriksveen (BuyPass), Mat Caughron (Apple), Patrick Tonnier (OATI), Peter Miscovic, (Disig), Rick Andrews (Symantec), Robin Alden (Comodo), Ryan Sleevi (Google), Stephen Davidson (QuoVadis), Tim Hollebeek (Trustwave), Tim Shirley (Trustwave), Volkan Nergiz (TurkTrust), Wayne Thayer (GoDaddy)
1. Antitrust statement was read by Kirk
2. Roll Call completed.
3. Review Agenda: No items added
4. Approve minutes of August 20, 2015 meeting: Minutes approved. Ben to post on website.
5. Ballot Status:
Ballot 150: IV/EV OIDS. Jeremy stated that the Ballot 150 was already in the voting period, which would end this Friday, but that no one had voted yet. Bruce stated he didn’t realize that voting had started, and had thought only a draft ballot was under consideration. Dean suggested that we restart the voting and extend for one week. There were no objections.
After checking with the proposer and and the two endorsers (Digicert, Symantec, and Trend Micro), Kirk stated he would post a notice to the public list stating that voting will start of this Friday and end one week later. There were no objections.
6. Microsoft Root Program changes.
Kirk stated that there were several outstanding questions about Microsoft’s new root program.
Rick said he still had an open question about the shortened OSCP validity period. The new maximum validity period two days is too short for any immediate change. Some CA’s use a four day period, others like Symantec a seven day period, etc. Any sudden reduction in the maximum validity period could have a big impact on a CA’s OCSP responders. Symantec’s technical group had given a rough estimate that reducing its present maximum validity period from seven days to two days could double the load, which could increase the costs by roughly 33%. However, if the load is tripled, the costs would double. It’s not possible to predict the effect right now with certainty.
Rick also stated that clock skew was a real concern with a two day maximum validity. He again suggested shortening the maximum validity period gradually in a stair-step fashion so CAs can adjust to the impact, e.g., by reducing the maximum period by one day every year or six months.
Jody noted that the root program was released in May, and Microsoft did not want to be constantly revising its root program rules, and needed to hear from Forum members as soon as possible about all potential changes or issues. However, he proposed that the group seek consensus now on reducing the OCSP maximum validity period to seven days, which would cover the clock skew issue. If there is no objection, Microsoft could make that change now, but might further reduce the maximum validity period in the further program changes planned for November. Rick said Symantec could live with a seven-day maximum validity period now and wait for further clarification in November on this and other issues.
Jody stated that further program changes were planned for November, and offered to circulate a red-line version showing the changes to the Members in advance.
Rick then pointed out there were pending questions on timestamp and OCSP SHA-2 signature requirements. He noted that there are multiple hashes that are used in both, and exactly where did the SHA-2 requirements apply? In the online discussions, Microsoft said it wanted SHA-2 signatures in some places, but did not require SHA-2 in all places, etc., which could cause problems for different CAs and applications. CAs need clarification on exactly where SHA-1 is acceptable, and where SHA-2 is required.
Jody acknowledged that clarification was needed, and stated the most efficient way to get clear answers would be if he has a specification or list of the places in timestamp and OCSP responses where a choice between SHA-1 or SHA-2 is possible, and the exact questions the group has. Jody could then take the list to his Microsoft specialists for resolution. Rick noted that he had already created such a list for time stamping, and could easily create one for OCSP responses.
Rick also stated it would be useful to get the same answers from the other browsers as to which fields could be SHA-1, and which must be SHA-2. Jody said that Microsoft could do a baseline document on this issue, and the other browsers could then comment.
Wayne agreed with this approach, and emphasized that CAs need clarification in writing. He also noted that on the last Forum call Nazmus Sakib had said he would give CAs a document explaining how to configure Windows to behave as it will on January 2, 2016 and January 2, 2017 so the CAs can test interoperability. Jody said he would follow up with Sakib.
Dean and then asked Microsoft to clarify to the group what the last date for signing Microsoft’s new root program contract would be. Jody said the last date was September 19, 2015, and that if Microsoft’s contract is not signed and received by that date, Microsoft will start the root removal process for the CA. He noted that he hadn’t heard at all from some CAs about the new contract. Wayne asked if the question of maximum OCSP validity period would be ironed out by the September 19, 2015 deadline for signing the Microsoft root program contract, as it is a significant issue. Jody said that Microsoft had agreed to a seven day maximum validity period for OCSP responses as of now, and would post any changes in its November update.
7. Email from AT&T re prohibition against issuing SHA-1 certificates after 2015
Kirk asked Rick and Dean for any comments they had on the request from AT&T to allow SHA-1 certificates to be issued in 2016 so long as they expired by January 1, 2017. Rick stated that Symantec had talked to the customer, but couldn’t convince the customer to switch to SHA-2 before year end 2015. AT&T felt so strongly about this issue that it asked to present its case to the Forum directly. Ryan it noted there had been several e-mail responses from different browsers to this request already, and asked if any ballot for a change to the BR was likely to be proposed. Rick said the answer would depend on the current discussion.
Kirk noted that he had posted a message to the list suggesting the issuance of SHA-1 certificates into 2016 shouldn’t really matter so long as they all expired by January 1, 2017, so why not allow issuance into 2016. He also noted that Bruce had stated the security issues occurred at the time of issuance, not at the later time of use of a SHA-1 certificate, which would affect his point of view.
Ryan stated the time of issuance of a SHA-1 certificate was important from a security standpoint, and noted that the current BRs stated that SHA-1 certs “must not” be issued after 2015, but only stated that any SHA-1 certs that were issued “should not” extend beyond January 1, 2017, and that some CAs had chosen to issue SHA-1 certs with a later expiration date. For this reason, he was against extending the deadline for issuing SHA-1 certs after 2015. He also noted that this deadline has been known since at least 2012 or 2013, and that CAs should have informed and prepared to customers by now. Finally, he noted that AT&T could solve its problem by stockpiling SHA-1 certs before the end of 2015.
Dean stated that given AT&T status as a major corporation and user of certificates, and that other large businesses had expressed the same concern, their views should be considered by the Forum when coming up with or modifying rules. Kirk asked if it would also be possible to push the December 31, 2015 end date for issuing SHA-1 certs into January or February 2016 with a maximum expiration date of January 1, 2017 so customers could avoid the 2015 holiday shut down season for changes to their web sites. Ryan stated that Google would not support such an extension.
8. Domain Validation Ballot – Discussion of Draft
Kirk noted that the Validation Working Group had completed a draft ballot with changes to BR 3.2.2.4 concerning domain validation methods, and wanted initial input from Forum members. He started by asking for a response to the open issues noted in the draft that was circulated.
The first open issue was the question of Authorized Ports. The working group recognized that allowing use of any and all ports for a practical demonstration method of domain validation presented security risks, and was looking to limit the number of ports that could be used. The draft ballot includes a definition of Authorized Ports, with a short list of off the possible ports to be used. However, the working group was not certain that this list was correct.
Jeremy stated that he initially liked the idea of restricting CAs to specific ports, but changed his mind. He noted that the draft ballot imposed other safeguards for domain validation by practical demonstrations, such as limiting web pages to the well-known directory location and requiring a random value unknown to the customer, so he now believed that there was no need to limit methods to Authorized Ports. If we are going to limit to Authorized Ports, we need a more comprehensive list, and should get data from all CAs – the current list is too short.
Ryan noted that he was one of the original proponents of limiting Authorized Ports, and stated that some CAs are allowing any ports to be used and that successful hacks have occurred. He did not feel that the other limitations, such as use of a well-known directory and random value, were sufficient to avoid the security risks if any port is allowed for a practical demonstration.
Ben stated he previously posted a list of 30 to 40 ports to the Validation Working Group, but the group had not reached any consensus. Kirk asked Ben to repost his list to the Public list for comments and suggestions, and Ben agreed. Kirk stated the Validation Working Group would take this information into consideration at its meeting next week, then bring the draft ballot back as a real ballot for voting.
9. Patent Working Group Status Update
Ben stated that the Patent Working Group had met two weeks ago, and would have another call tomorrow.
10. Validation Working Group Status Update
See previous discussion.
11. Code Signing Working Group Status Update: More changes
Dean said the working group had received many good comments from Opera and others, and still has lots of work to do. The working group will process all the recent input, and bring back its proposal in the near future.
12. Policy Review Working Group Status Update
Ben said the working group would meet next week in Washington, DC, and go over the rest of the BR requirements. There was a question of whether the Extended Validation Guidelines should be incorporated into a single document with the Baseline Requirements. At this point, Ben thought the answer was no – it would be more useful to keep the two documents separate.
Kirk asked if the working group plans to incorporate the Network Security requirements into the BRs, and Ben said yes. Its next project would be to convert the Extended Validation Guidelines into the RFC 3647 format, but keep it as a separate document.
13. Responding to Questions Posted to the Questions List
Dean said he wanted to discuss the procedure for how the Forum responds to questions posed by the public to the questions@ list. He stated that the Forum has a bylaw covering this, and as he recalls the practical procedure the Forum uses is as follows: the Forum has a “coordinator” (and that this is currently Eddy) and the coordinator will respond to a question directly on behalf of the Forum if the question is very easy. In all other cases, the coordinator will draft a proposed response and circulate it among the members for comment, then post it as a response to the question once consensus has been achieved.
Kirk agreed that was the correct procedure as he recalled it, and stated he would include the applicable bylaw on the questions list with the Minutes for this meeting. [Bylaw 6.2 reads as follows:]
6.2 Procedure for Dealing with Questions and Comments
The Forum procedure for dealing with questions and comments sent to the Questions Mail List shall be as follows. The Chair shall appoint a Questions List Coordinator. The responsibilities of the Questions List Coordinator are:
(a) If practical, within 24 hours send an acknowledgment to the questioner indicating that the question or comment has been received and that a response will provided as soon as is practical.
(b) Coordinate discussion using the Member Mail List until consensus has been achieved. (c) Post the proposed response to the Member Mail List indicating that Members have 24 hours to object.
(c) Post the proposed response to the Member Mail List indicating that Members have 24 hours to object.
(d) If no objections are received before the deadline expires, then send the response to the questioner.
(e) If consensus cannot be achieved, or one or more objections are received, then the matter should be dealt with in the next Forum Meeting or Forum Teleconference.
13. Information Sharing Working Group Update
Ben stated that he had no update.
14. Any Other Business
Istanbul meeting Oct 6-8.
Dean it stated that Davut needed to know all hotel reservation requests as soon as possible, and that room requests should be posted on the CABF wiki for the meeting. He also stated that Davut would have more information about pricing and rooms by next week.
New member request
Dean stated that he had received a new member request from Cisco, which apparently has a root in at least one of the browsers. He informed Cisco of the Forum membership requirements, and expects to see a completed application from Cisco by next week.
15. Next teleconference Sept 17th
16. Adjourn