2013-12-05 Minutes
Notes of meeting
CAB Forum
5 December 2013
Version 1
1. Roll Call: Dean Coclin, Ben Wilson, Atsushi Inaba, Sissel Hoel, Tom Albertson, Gerv Markham, Caroline Oldenburg, Kirk Hall, Doug Beattie, Richard Wang, Jeremy Rowley, Moudrick Dadashov, Wayne Thayer, Rich Smith, Robin Alden, Rick Andrews, Imren Altepe, Atilla Biler, Ryan Sleevi, Eneli Kirme, Mads Henriksveen, Stephen Davidson
2. Agenda Review: Approved.
3. Minutes: Minutes of 21 Nov 2013 were approved as circulated. Regarding the status of minutes from the F2F in Ankara, Ben will complete the minutes and post them on the WordPress site. He’ll upload PDFs as attachments to the minutes for the presentations that were given at Face-to-face and hyperlink them to that draft of the minutes and then put them on the agenda for approval during our next telephone call.
4. Discussion of Face-to-Face Meetings:
Ryan will send out a clarification that he needs a headcount for the next Face-to-Face meeting. A webpage will be created on the wiki for planning purposes. Ben will assist getting a letter of support for the meeting to the US State Department for WoSign and Turktrust and anyone else who needs a letter.
In order to plan for the meeting in Eilat and in China, Ben will send out an email with information about conferences in June and September and ask if anyone knows of any other events that might conflict with F2F scheduling. For instance, ICANN is meeting in London June 22-26 and the WiFi Alliance is meeting in Chicago June 24-26. Then we’ll do a Straw Ballot to help plan the dates.
5. Discussion of Ballots 89, 103, 107 and 111
On EV Processing Guidelines, Ben needs to get a replacement sentence for the conclusion paragraph, and then Ballot 89 can proceed. Robin will check into what we should do about “must staple” for Ballot 103. On Ballot 107, Mads explained that he removed specificity to version numbers because ETSI standards are revised and re-versioned more frequently and yet they are of equal applicability across Europe. He also created references the ETSI certificate policies for the BRs and EV Guidelines. Ben will recirculate the language of amendment as a pre-review-period version for Ballot 107.
**Ballot 111: ** Dean raised concerns about Ballot 111 and the timing of implementation. He said that Bruce made some good points in his email. Wayne said he had concerns about the language that would affect existing customers with 5-year certificates because the customer buys a certificate for a given term, and changing the duration causes problems.
Gerv: All certificates on the Internet have an effective lifetime of less than three years because of SHA1 phaseout. On the current plan, there is an April 2015 deadline to stop issuing 5-year certificates. However, we have the opportunity instead, to implement this change to three-year certificates two years earlier than we would otherwise be able to do. Having everything with a shorter lifetime is better for the ecosystem and our ability to respond to threats to bring changes. People can either disagree with me on the goal or on the implementation, and I can address the issue. We can either do something with a ballot as proposed, or we can let the SHA1 apocalypse deal with the SHA1 certificates so that the amendment just addresses SHA2 certificates, which will allow CAs to deal with SHA1 as they see fit. I thought we had some preference toward that on the last call, but people may have changed their minds on that since the last call, but I would like to bring one of these two proposals to a ballot. Either way, CAs are going to have to deal with the SHA1 certificates.
Rick: I think you assume that CAs would like to issue 5-year certificates up to the current deadline, but I don’t think that’s correct. We’re trying to shorten the lifetime and replace SHA1 certificates as soon as possible while minimizing the costs that we’ll have down the road, but even April 2014 will pushing it too fast.
Gerv: But if you replace a SHA1 certificate with a SHA2 one, there is nothing to prevent you from replacing it with a five-year certificate, and my proposal is to say that people should not do that. So if you are not opposed to that, then you have a problem with the implementation date, so would you prefer a different date? I have tried to have the date coincide with dates of other changes.
Wayne: When a CA sells a certificate to a customer, it is sold for the term of the certificate. So, when I am rekeying a certificate using SHA2, I can give the customer the same term they bought. And when I sell a three-year certificate, they can get either a SHA1 or a SHA2, but changing from selling a 5-year certificate and trying to rekey a 5-year certificate from SHA1 to SHA2 are more difficult. To change them to a 3-year certificate I would have to give them a refund or credit as well.
Gerv: But everybody is going to have to do this in three years.
Wayne: It is more difficult to do it now.
Dean: Most CAs have made their plans given the current schedules and to change CA product planning cycles and product roadmaps is quite difficult.
Robin: We are sympathetic with bringing the timescale down, but it is the customer edge cases that we have to deal with and 100% compliance become the sticking point.
Gerv: So what if it said, “unless required by existing contractual obligations”?
Ben: What if we left that section in the BRs as is, but added another sentence that had a “SHOULD”?
Wayne: I actually like Gerv’s language better. The problem I have is being able to reissue certificates, so if I have to rekey a certificate for a customer with a 5-year certificate and I’m allowed to do it, then that makes a big difference to me.
Gerv: I’ll ponder that because we would like to enforce this requirement in code. However, these suggestions do not allow us to do that. If we move forward with the ballot, and if it were to fail, then Mozilla would have to figure out what approach it might want to take, but it might that if we were to take these approaches and saw that in the vast majority CAs are only issuing 3 year-certificates.
Jeremy: If we were to take that approach, we’d want the language to say “unless contractually obliged.”
Gerv: Yes, you’d want those kinds of words, and effective as of some date specified in the ballot-some date which doesn’t require CAs to update their site within 18 hours. So, for those who currently oppose the ballot, would a date not too distant in the future with some exceptions meet with your approval?
Dean: I don’t think a date sooner than October works, so that we can get this change roadmapped. So whether it’s contractually required or not doesn’t matter from our perspective.
Gerv: Are you saying it takes nine months to stop selling something?
Dean: No, what I’m saying is that anything that is not an extreme security risk is going to take time and need to be placed on the roadmap. There is a difference between CAs in large software development houses and smaller CAs that have less trouble making changes.
Gerv: Surely, if it were except for existing contractual obligation, it would not be a code change at all, because the code would still support the issuance of five-year certificates. It is just that from a business perspective you’d be making a request of that code softer. It would be a web site change or marketing change.
Dean: When you’ve got a lot customers and partners, and people out there, it’s not that easy to ripple that down.
Ben: I think we need to move this conversation offline. Maybe we should do a combination where the effective date for requiring a contract is some date, January or April, and the date for the prohibition and other effective requirements and exceptions would be a subsequent date like October?
Gerv: It is useful to talk about this together. What is the deadline for this ballot?
Ben: Voting starts this afternoon, but I don’t know whether we can make any minor amendments at this point based on today’s discussion.
Gerv: I don’t think we have consensus yet, so I’ll take what I’ve heard and go have a discussion and decide what we’ll do-whether we go ahead with the vote or withdraw it. Thanks everyone for your input. Feel free to email me if you have further input on this or post on the list.
6. RFC 3647 Formatting of Guidelines
Jeremy: On 7 November, I sent around the BRs re-formatted to RFC 3647, and I wanted to get feedback on what everyone felt and what we should do next. I have done this for the EV Guidelines as well, but I want to get feedback on the BRs first.
Kirk: Could you remind us about why we are doing this? I remember that we decided to do this, but I can’t remember why, and it is a lot of work.
Jeremy: RFC 3647 is the prescribed format for CPs and CPSs, and the Guidelines and Requirements are really CPs. Doing so will make it easier for auditors and others to compare what is already required for CAs to do and against other industry standards written in 3647 framework, like NIST and others, and the CABF is an anomaly since requires others to do it, but we don’t have ours in that outline. It will also help us to identify gaps in the BRs and EV Guidelines where we haven’t adequately described what CA practices need to be in place. This decision was made in Turkey, after Tom made his presentation, in which he compared NIST’s CP with the BRs.
The first phase is not to make any changes in the language but to move the language over. I’ve created a spreadsheet to track the changes. The next stage would be to reconcile the language, but I want to make sure everyone is OK with this approach before we proceed.
Ben: We need feedback on this, but we also need to keep moving forward.
Ryan S.: Reviewing this is high on my list of priorities, I just haven’t got to it yet. I just need to find the time among other competing projects.
Ben: So how should we proceed?
Jeremy: Once everyone is OK with this, we would then proceed making changes and inserting “no stipulation” where appropriate.
Ben: Since we have a snapshot, we should be less concerned about moving forward because we can always go back and look at that snapshot to see how things changed.
Tom: It’s still a priority for me. We should move forward carefully on this and discuss it at our next face-to-face meeting. Microsoft has an added resource now to work on it with the February meeting as an objective.
Ben: That’s a good idea. Let’s everyone thoroughly review it without additionally editing it, but provide comments to it and marking it up from where it is now.
Dean: We are doing a similar thing for the code signing BRs now. We have people working on a review of them so we can get them out before the holidays.
Rick: Jeremy, at this point, will we have to re-write the code signing BRs to this format?
Jeremy: When we’re done, we may want to combine the SSL BRs and code signing BRs together. We can figure out more of the details when we get there.
Ben: Would this be something we could do during the Tuesday meeting at the next face-to-face?
Jeremy: Yes.
7. Working Group Updates
EV: Jeremy said that a number of issues are ready for ballot, and all that is needed is a couple of endorsers, and a few others need more discussion. There is an EV WG coordinating call directly following this meeting to figure out meeting schedules.
Code Signing: Jeremy said we’re ready to circulate another draft for review. There will be a new draft next year. Ben asked what he meant by a draft that will be ready for review, one for the CAB Forum to review or a public release. Jeremy said it will be a “draft 2 for public release”.
Performance: Wayne said he still needs to connect with Brian Smith to discuss project goals and objectives. It doesn’t make much sense for the group to proceed without a better outline of what it will work on, so we really need Brian’s input first.
8. Any Other Business: None.
9. Next phone call: Thurs. Dec. 19