2014-04-17 Minutes
Notes of meeting, CAB Forum, 17 April 2014, Version 1
1. Antitrust Statement – read by Ben.
2. Agenda reviewed.
3. Roll Call: Atsushi Inaba, Eddy Nigg, Dean Coclin, Jeremy Rowley, Ben Wilson, Marcelo Silva, Kirk Hall, Wayne Thayer, Imren Altepe, Atilla Biler, Mert Özarar, Kelvin Yiu, Robin Alden, Gerv Markham, Rick Andrews, Rich Smith, Tom Albertson, Geoff Keating
4. Approval of minutes: Minutes approved, including amendment suggested by Jeremy Rowley, as circulated.
5. Ballot review: Ballot 122 Verified Method of Communication: Kirk asked for clarification as to whether this applied when reaching out to the contract signer, human resources, or a confirming person. That was affirmed. Jeremy clarified that intent would be that communication would be over that method until other methods were established between the parties, e.g., through the exchange of a code. Kirk also asked whether the group had considered the somewhat ephemeral nature of non-landline phone numbers, for instance, if they have a number where they can be reached and then they discontinue receiving service. What is the record checking process? Jeremy responded that the group tried to focus on services that were stable. Kirk asked about email addresses like Gmail and how those would be looked up. Jeremy said that those have to be verified using a QGIS or QIIS or an attorney letter-it is not just based on what the customer provides, it is based on an independent reliable source, and more and more governments are using email addresses for official communications with businesses. Often the business is required to keep this information up to date with the government, so it isn’t as ephemeral as one might think.
Announcement: New WebTrust documents. Ben said that the following documents have been posted on the CAB Forum website, and everyone should be aware of them and take a look at them: EV Guidelines (effective 3-Apr-2014); SSL Baseline with Network Security (effective 1-July-2014); and EV Code Signing (effective 1-July-2014). Kirk asked whether a redline version had been provided by WebTrust. Kirk said he could email Don for a tracked-changes version.
6. Membership application for Actalis: On 11-Apr-2014 we received the CA membership applications from Actalis located in Italy. Richard Trevora pointed out via email that their audit report is based on older ETSI standards, but Dean noted that the bylaws do not require current ETSI standards (this is, however, a guidelines requirement). We have a signed IPR agreement, and the application contains everything that we request in the application. For active business of issuing SSL certificates, they also sent a link to a website that has an SSL certificate, even though it is their own website. From a CAB Forum perspective, they appear to meet the requirements. Dean will contact them to say that they have been accepted.
7. Discussion of re-key rules: Wayne explained that it would be a lot faster to re-issue certificates based on a re-key needed by customers in response to the Heartbleed vulnerability. The problem is that section 11.3 of the Baseline Requirements states that the age of data used to validate a certificate must be less than 39 months, while section 11.13.4 of the Extended Validation Guidelines provides reissuance under an exception as a replacement certificate if it has the same expiration date of the currently valid EV Certificate being replaced. He said that the EV rule provides clearer guidance while the BR rule causes problems for legacy certificates issued with older data, which can’t be rekeyed without meeting all BR requirements. So, if vulnerability like Heartbleed happens and you have a situation where you just have to re-key, it doesn’t make sense to have to re-perform validation if it is just a re-key.
[Comment from Geoff Keating: To avoid confusion, this is what was said in the discussion, but I don’t believe it’s a completely accurate statement of what the EV guidelines say. What they say is that “A CA may rely on previously verified information to issue a replacement certificate” which is not necessarily the same as “you may reissue”-the previously verified information may not be enough. An EV certificate has a maximum lifespan of 27 months, and the previous sections allow use of information up to 13 months old. By comparison the BRs allow 39 month old information to be used to issue a certificate that might have up to a 60 month lifespan, for a total of over 8 years before anything is rechecked (disregarding the Mozilla policy).]
Kirk agreed that if it is allowed at the EV level, it is strange that it is not allowed at the OV level. Gerv said that when we adopted the Baseline Requirements we needed to have a rule that phased out long-lived certificates (greater than 39-month validity) so that it wouldn’t be applicable immediately. Now, if they are changing the certificate anyway, then it is reasonable to expect that the certificate be changed to be BR-compliant.
Ben wondered whether there was any potential wording for a ballot that could be proposed, but also whether this issue is going to pass without being able to address it. Wayne said that from a practical prospective, it would be helpful to address, even though it has now been 10 days since Heartbleed was announced. Kirk said it appears that the guidelines don’t expressly address this issue (re-key, re-issue, replace), so it is maybe just that some browsers don’t like it.
Rich said that in past discussions there has been consensus that a re-key is allowed after a quick review of the main facts-the certificate issued today can be based on the details of the past. It will be a new certificate with a new hash, even the key would not be the same key. Kirk agreed that traditionally CAs have done this for customers, and it was not really considered to be a new certificate. Eddy said that there is no such thing as a “re-issued certificate” – it is not the same certificate.
Rich said that, for the record, he agrees with Wayne, and he would like to see something done with a ballot as a long-term thing–there should be something in the Baseline Requirements similar to what we have in the EV Guidelines about reissues (replacements). In this particular case, in regards to Heartbleed, do we have an emergency ballot process? Can we relax these revalidation requirements just for the instance of Heartbleed? My personal view is that it is far better to have a re-issued certificate out there that may not be in full compliance with the BRs.
Kelvin: For an emergency ballot for Heartbleed, in terms of this slowing down customers’ ability to re-key, what is the slowdown rate? How many customers are waiting in the queue because your staff is dealing with it?
Rich: I’m seeing at least a 10-fold increase in re-issuance requests. I thought that by now I would have seen light at the end of the tunnel and for the next few weeks that seems to be the case, but right now, I’m not sure we can estimate when this is going to be past us.
Wayne: There’s a second take on this. In addition to the customers who have to wait, in a many cases there are three parties-the company/website/business owner, the CA, and the hosting provider who we deal with directly. If we could do it without the business owner, between just the hosting provider and the CA, that would be better.
Jeremy: The Mozilla rules say that you have to re-verify information at least every 39 months. Customers cannot get more than a 60-month certificate.
Kirk: The proposal on the table is to reissue with the same expiration date.
Rich: The five-year certificate is still permissible under the BRs today. There are still some certificates out there that were issued with validity longer than 5 years, which predate the Baseline Requirements. So, if what you’ve got left on one of those exceeds 5 years, then you will have to knock that down to 5 years.
Rich: Is there any mechanism within the Bylaws to put forth a measure?
Ben: No, and I don’t think we’d even know how to suspend the Bylaws.
Kelvin: And that would be a very dangerous thing to do, in terms of precedent.
Kirk: Another way we can do this is by asking each of the browsers whether they prefer that this approach be taken. Isn’t it only Firefox that has a stated rule? Has Microsoft ever stated a rule on revalidating information in case of rekey?
Rich: The issue here really is with people who have long-lived certificates that were issued when the BRs came into existence a few years ago.
Kirk: The ballot could address anything that came into place before the BRs.
Gerv: How about this? CAs concerned about this issue should send Kathleen and me an email with the number of certificates Heartbleed affects and the percentage of Heartbleed re-keys that involve re-validation, and then we can look at it. That information will remain confidential.
8. Discussion: Root CA Recognition/Acceptance Processes of Trust Anchor Programs
Mert Özarar (Turktrust) said he appreciated the opportunity and this period of time on the agenda to express their situation and the difficulties they have had in getting into the trust anchor programs of Google and Oracle. Here is Turktrust’s written statement:
Turktrust Statement on Root CA Recognition Process
**9. Working Group Updates: **
Jeremy: Besides the one ballot that is being proposed on EV SSL Working Group, that’s it.** **
Kirk: If you look back, it is clear that the Forum has approved the code signing working group. We’ve passed ballots and worked on EV Code Signing for years, and I’ve read the recent posts, and I have wondered why this is being raised now and why the issue wasn’t raised several years ago?
Dean: Just to be clear, there are two different issues here. The working group on Code Signing is just on code signing, not EV code signing, and the other group is working on EV SSL. The status of the Code Signing Working Group is that we’re working on the risk database issue and we’re having a call next week. Jeremy has circulated a revised draft of Code Signing guidelines.
10. Other Business: Heartbleed vulnerability disclosure process and sharing of vulnerability and threat information.
Ben said that he obtained a chronology of the Heartbleed discovery and disclosure process, which many members may have seen. It indicates that certain people were pre-notified of the issue, and he wondered whether members of the CA/Browser should have been advised as well, given the nature of the problem, and whether we should have had a seat at the table will information about the vulnerability was being handed out.
Dean: Yes, and how do we do that?
Ben: We need to make it known that we are here and should be on the notification lists. There is a balance between disclosing it to people who can start fixing it and those who discover it or find out about it and want to keep it secret-it’s confidential information to them, and they aren’t required to share it, but only with people with whom they want to share it, and pursuant to some kind of non-disclosure agreement, but on the other hand, it’s pretty bad when we learn about it after it’s released to the public.
Kirk: Maybe we should send an email to whoever you can think of and say, “you may not know about us, but here is who we are, and we’d appreciate receiving notice if there is anything in the future that we can help with, if you choose to disclose to us.”
Rick: And who is the “they” that we send it to? For instance, it is likely to be only a few researchers. Mitre was advised earlier, because they had a CVE number already set up. Does Mitre have a process for responsible disclosure, on a case-by-case basis?
Geoff: No. Usually a CERT is involved, and they advise other CERTs, but this did not go the way it was supposed to go.
Ben: Rick, could you send an email to Adam Langley on the management list to ask why we weren’t notified, just to start a discussion about it?
Rick: Yes.
11. Next call: Thursday, 1 May 2014
12. Adjourned.