2012-11-19 Minutes
Notes of meeting
CAB Forum
19 November 2012
Version 1
Present: Rick Andrews, Ben Wilson, Kirk Hall, Yngve Pettersen, Atsushi Inaba, Eddy Nigg, Jeremy Rowley, Dean Coclin, Mads Henriksveen, Wayne Thayer, Ryan Koski, Steve Roylance, Gerv Markham, Stephen Davidson, and Robin Alden
Agenda Review: the agenda was reviewed.
Approve Minutes of 8 Nov 2012: The minutes of 8 November 2012 were approved as published.
Review of Ballots: Ballot 94 (Governance Reform) is in the voting period and closes on Friday. Ballot 92 has been split into 3 segments. Rick and Geoff are looking at the IDN issue, Jeremy sent Robin a draft ballot to address new gTLDs, and Steve Roylance has proposed a ballot to address SANs. Also, during the last call, Jeremy was asked to take a look at BR Issue 4, and he has prepared something that will be proposed in the future.
On Ballot 92, Steve Roylance is trying to gauge member opinion on a number of issues concerning the use of SANs in certificates. First, (1) with regard to internal / non-unique items, he asked whether any members felt it was appropriate to issue a publicly trusted certificate with solely a non-unique name like “mail” in the certificate? Several members said that they believed it was already going to be prohibited under the Baseline Requirements so that it should be allowed until it is expressly prohibited. Yngve said that the proposed ballot is not about prohibiting an internal name but about having an internal name as the only information in the certificate’s subject CN or SAN. Rick said that he would have to see if any customers have such certificates, and then ask those customers for their rationale in wanting such certificates. Wayne said that for GoDaddy it is an extremely common use case.
Steve asked whether any member had concerns about the risk of issuing a publicly trusted certificate with a single internal IP name and no other identifying information (i.e. no identity information). Rick said the risk of malicious misuse is low. Kirk said that no one has ever shown an example where such a certificate has been used against somebody. Steve said that Brad Hill had raised this concern during the Bermuda meeting a year ago, and that nobody could come up with a scenario, but some members continue to be concerned about this issue.
Yngve asked Wayne how common it was to have only a non-unique domain name in a certificate. Wayne said that customers with purely internal-facing services still want publicly trusted SSL certificates because with the variety of enterprise devices that people are using it is virtually impossible to distribute an internal root, and if you were using it only internally, why would you want anything more than a domain-validated certificate? The customer already knows who they are dealing with, and the use case for purely internal use is a pretty common one.
Yngve asked if there were any specific examples. Wayne said that GoDaddy has that type of certificate, and that a customer should be able to get a certificate with an internal name of say, “mail.” He said he didn’t think that the proposal really raises the bar to prevent malicious people from getting and using these types of certificates, and if they are really seen as a threat, then they should be eliminated altogether, which is what we are already doing under the current plan. Yngve said that an attacker can use a “mail” certificate to intercept email sent to your connection. Kirk asked whether that wasn’t true even if you put a unique name like “Steve-O” as a unique name, an attacker could still intercept email. Yngve said that information in the certificate makes it more trackable. Kirk asked whether that helped with security, and Yngve said that it did because you’d have somewhere to go. Kirk asked whether you couldn’t go to the Issuer. Yngve said he didn’t know whether any particular CA actually knows who it was dealing with in issuing an internal name. For example, the credit card could have been stolen, but at least with a DV certificate you verify a unique name associated with a domain registrant and that raises the bar.
Steve said that if Wayne and Gerv believe that the current BR requirement for OV are not strong enough to be of any use, then that would be the next thing to look at, because if you want to have one of these certificates, then we should require that you identify who you are, because otherwise there is no identifying information in the certificate.
(2) Steve asked about public IP address and said that there are a number of processes that a CA can go through to ascertain a public IP address, but attackers can exploit these same processes to obtain certificates with public IP addresses and then use them against the legitimate holder of the public IP address. So it would appear that the issues discussed previously are very similar.
(3) Steve said the third scenario is the certificate with mixed registration information because there are multiple domain owners. He noted that in the past there has been debate over whether there is any security difference between a single certificate with 10 SANs and 10 DV certificates with separate keys. Steve said that ten DV certificates is more secure because you have 10 different keys, and that for a certificate with a single key and 10 different, unrelated domains, the CA should include contact information. Kirk said that if a common key is the problem, then we should just eliminate SANs altogether. Steve said that SANs help SSL to work with current hosting deployments until SNI is widely deployed. Kirk said that if Steve thinks that a common key is the security threat, then we should just prohibit it, otherwise using a common key is not an issue and we don’t need to address it because there is no relevant distinction between common owners and different owners. Steve said it comes down to the example of multiple flats with shared keys-with a shared key there is no security, so he asked why Kirk was arguing this point. Kirk said that loss of a key is disastrous in either case, whether it’s ten people who are family members or ten people who are not family members-so we should outlaw all SANs certificates, because he didn’t see any distinction.
Yngve said that a cloud service provider might use a single SSL server for 10 different domains. The cloud owner generates the key and obtains the certificate, but is behind the 10 domains. Wayne said that this is a common use case that he is aware of, due to the limited supply of IPv.4 addresses and the use of CDNs. The person controlling the key and obtaining the certificate is not the person serving up content and controlling the website. So when you put an O field in a certificate, it would have the service provider’s name, but each website is controlled by an entirely different organization, and that would be misleading because you’d be requiring misleading information in the certificate in these cases. Steve said it’s not misleading because it’s reality. Wayne said it is misleading because if content is served up by Cloud Flare as a CDN, and a hosted domain puts up a website serving malicious content, then a user who sees an indication of Cloud Flare doesn’t get notice not to trust the web site. Steve said it is just like when you enter a building that says Regus across the top, and that here reality is reality, and you are showing who has control of the key. Ben noted it is really browsers displaying information, so if that message is considered misleading, then there is a whole different aspect of this problem that needs to be discussed, apart from what a CA should put in the O field.
On a final ballot topic, Yngve noted that he sent out updated text on BR Issue 7 again, and that for whatever reason no one has responded. He said that he had adjusted the timeframe to implement AIAs in URLs to August of next year. Ben asked everyone to take a look at it again and to have a response for Yngve before the next telephone call. Rick asked whether it would only apply to newly issued intermediates after the effective date, and Yngve confirmed that was the case.
- Discussion of IPR-related Issues
Ben noted that he had sent several emails trying to gauge member positions on the IPR policy. Kirk asked why Entrust wouldn’t sign the IPR and said that we shouldn’t go through any more trouble revising the IPR because no member has ever claimed patent infringement or demanded payment of royalties from other members. Ben said that begs the question of why we have an IPR Policy in the first place. Kirk said that if companies with huge IP portfolios are willing to sign, then why isn’t Entrust. Dean said the reason was the inclusion of affiliates, which Kirk had already addressed previously, and then he asked Jeremy to explain stand-around liability. Jeremy said that Entrust’s attorneys were concerned that member representatives might accidentally grant licenses to some Entrust patents without realizing it. Gerv said that one person’s concern about stand-around liability is another person’s concern about submarining.
Ben said that he had hoped we would look more closely at the term “participation” in the current IPR Policy and the fact that it is not defined, but includes everything, and that while we had this conversation a couple of telephone calls ago, without a definition of “participation” the IPR policy applies to everything we do, but if we are able to define it so that it is limited (e.g. by defining “participation” to mean “Contributing” or “Voting in Favor”), then that will address the concern about stand-around liability because it will provide a bright-line that is acceptable to Entrust. Kirk asked whether they would participate, even under a revised model, because they would still have to know their entire patent portfolio to decide when to participate or not, but will likely choose not to participate because it would be easier not to participate than to risk exposing to RF licensing something they don’t know about.
Kirk asked about how contributions would be recorded, and what would prevent a party from leaving the room or not going on record as contributing, and how could you trust someone across the table in that scenario. Ben said that CAB Forum discussions are mainly public anyway, so it’s better if we can get Entrust to sign the agreement and actively participate in the Forum because anybody on the outside can lurk on the public list and not be bound at all. Kirk asked Ben what made him think Entrust was going to participate if they signed a new one because he thought that they didn’t want to participate if they had to check all of their IP for conflicting material? Ben said that the IPR Policy has plenty of ways to exclude your IP if you decide not to license it, so he didn’t think anyone could say that they wouldn’t participate because they didn’t want review their patent portfolio. He also said that if someone contributes, and then realizes during the review period that IPR is implicated, then they can always file their exclusion notice. Kirk asked why, then, would Entrust not sign our current IPR Policy, since it has that approach already built in. He also said he doesn’t want someone to come in and say, “we’re not participating from beginning to end, but here is what we think about your draft.”
Yngve asked about the status of one of Entrust’s concerns - the blanket exclusion. Ben said that the issue came up but was never accepted by IPR Committee and isn’t being proposed under this new IPR proposal, but the work that they’ve done with Marc and with us indicates that Entrust would come back and participate if we were to amend the IPR as proposed. Gerv said he didn’t understand the “I have to keep checking my IP argument” because we’ve only produced three documents in six years, and which one is very basic security guidelines that does not have IP in it. Jeremy said that we do a lot of errata over the years, and that is where the attorneys need to look at patent portfolios. Gerv asked what they do with other standards bodies. Jeremy said his understanding was that Entrust does not join other RF-licensing standards bodies. Gerv asked how other companies involved with RF-based standards bodies deal with this so that we can address this question for Entrust and other potential members who are concerned about the burden of reviewing errata? Kirk said that there is no easy way and that they have to look at their IP, and the only thing that helps is if an entity decides not to participate. Jeremy said that he understood that Entrust would participate in issues in which they were interested. Kirk asked whether Entrust would leave the room or get off the call when they weren’t interested in participating, so that at least everyone would know that they are not participating? Kirk said he doesn’t want to be in the room when they know that they are participating, but he doesn’t know. Dean said that this whole debate about participation was the reason why we are trying to define participation, which was the purpose of the straw poll. He also said that “participation” was an issue raised by John Espinoza of Identrust and that it was also part of IPR committee calls and that we should look at the results of the straw poll and decide where we are on the definition of participation.
Ben said he would like to get to an answer on this, because contrary to some members that say this won’t change a thing, the current use of the term “participation” is too broad. Kirk said that we can’t use “working group” because we’re not working-group based. Ben said that “working group” is not part of the currently proposed solution. Kirk asked whether someone could attend a regular Forum meeting and talk but not vote and why would we want them there? Ben said that seldom does someone say something during a discussion that is a patentable idea, but that talking would be considered “contributing” when it is recorded in the minutes, or when someone works on something that gets incorporated into a ballot. Kirk said he thought that the proposed definition would be unworkable, because a year later they might say, “hey, I’ve got a patent on that,” and then we’ll have to go back and listen to recordings of what they said and whether they had ever, ever said, “hey, you ought to word it this way” by way of contribution. Yngve said that the current wording says it has to be minuted. Kirk expressed concern about the ability to keep track of minutes. Yngve said that if we ever get into a court fight, then all of the documentation will have to be put into the record and the lawyers will have to fight it out. Gerv said that whoever prepares the minutes each week will have to prepare them knowing that one day something minor that said might become legally relevant, and that’s not fun for the person who transcribes it, nor for the person who has to check to confirm that that is what they said. Kirk said that we’d have to record everything and keep recordings of everything. Gerv said it is easier if you’re in or you’re out, and we generally sit around talk, and you’re involved just by being present. Yngve said people could also sit around and not talk during the meeting, and then pull someone aside outside of the meeting and get them to contribute it. Ben said that we have to wrap up this conversation and move this to the list and continue the conversation, but as Yngve noted, there are a lot of concerns that arise simply by having an IPR Policy in the first place, and unlike Kirk’s concern about participation, he is more concerned about the exclusion provision and the fact that a patent review committee is supposed to be convened to review 70 patent exclusion notices and figure out where in a guideline an essential claim in the patent is implicated, and who is going to do that, and yet it’s already part of the IPR Policy.
Kirk asked if Ben could ask Entrust what their plans were, and how they would decide when they would be participating and not, and that this would force them to look at it and get back to us on why this is a solution. Dean said that if we had more participation during the IPR committee calls some of the questions raised on the call today might have been answered during those calls.
- BR Audit Effective Date & Compliance Pledge
Dean recapped that he had sent out an email expressing his concerns about the BR effective date and audits, including his concern that people outside the Forum are saying, “hey, look, the CAB Forum approved this Baseline Requirements document 1.0 effective July 1, and 1.1, effective September 14, but look, members are issuing certificates that don’t comply with their own standards.” For example, when Netcraft noted that CAs weren’t observing the rule on 1024-bit keys, it put a black mark on the whole industry. While most CAs are complying with the BRs, there is evidence that not everyone is complying or correctly implementing the BRs. He said he hoped, firstly, that all members would state that they are complying and that he hopes that we’d work toward auditability of compliance. To illustrate this second point, he noted that during the face-to-face meeting in New York that Don said there first needed to be audit criteria and that second, browsers would need to accept that audit guidance and that he subsequently said in an email that he is fine with applying the audit criteria back to whatever date is chosen (e.g. July 1, 2012), and that maybe we can get some feedback from Gerv and Yngve about this, since they are on the call. Dean then asked – 1, are CAs willing to set a date now, and 2, are we willing to say to ETSI and WebTrust that once your criteria have been adopted, are you willing to tell your auditors that they have to go back to whatever date is chosen and require compliance-checking as of that date? Kirk said he thought there was WebTrust criteria for the BRs that were open for comment. Ben said he thought that the comment period had already passed and that they are ready to implement. Dean said he understood from Don that they were ready to implement as of Q1 of 2013. Dean asked Gerv if it was Mozilla’s understanding that WebTrust and ETSI would approach the browsers and ask whether they were willing to accept the audit criteria? Gerv said that when ETSI and WebTrust publish their requirements, Mozilla evaluates them and decides whether to start requiring them. Dean asked whether Gerv had any thoughts about whether Mozilla might be willing to require compliance back in time. Gerv said that for the BRs, there was a date set after which they were effective, and that Mozilla would be expecting CAs, morally, to comply with them as of that date, and that they reserve the right to include in the Mozilla program requirements any provision of the BRs without advance notice, although Mozilla has currently been going through an update process that includes some things that clearly cannot be checked by Mozilla without them being included in the audit. However, as soon as WebTrust and ETSI implement their audit criteria that will be great because more people will be checking these items, and then we can start requiring audits under those new standards. Dean said from a CAB Forum perspective we can set a date of July 1, 2012, which is great, but from a practical perspective, browsers need to say that compliance is required for it to get done.
Gerv asked Dean what he meant by “audited from”? Dean said that if WebTrust is ready to perform audits as of March 2013, and the first CA audited is in May 2013, then will the auditor look back to July 1, 2012, for compliance? Kirk said that Don’s proposal that “we decide” really didn’t mean CAs can make this decision, because we as CAs shouldn’t, from an antitrust perspective, so that when Don said “it’s up to you” he really meant that it is up to the browsers to decide when compliance is required in order to stay in the trusted root store. Dean said that the browsers really need to get in touch with ETSI and WebTrust and say, “thanks for constructing the audit criteria, we want you to check for compliance as of date ‘X’.” Otherwise, the auditor will assume that compliance is only required after the first full year after the criteria are effective, which might delay BR audits for even an additional year. Ben said that he thought that the audit criteria for ETSI and WebTrust weren’t going to change much and that we could set a date of January 1, 2013, and we could notify the browsers that the two sets of criteria are ready to implement and that the documents from ETSI and WebTrust provide enough guidance for both CAs and browsers to judge now whether they’re good enough to begin requiring enforcement. The CA Browser Forum could send browsers a request that they require compliance as of January 1st, so practices between July 1 and January 1 are not audited according to the BRs, but they are after January 1st. Kirk said a ballot could state that the CAB Forum recommends that browsers require that CAs be audited to the BRs from January 1st so that even if the browsers can’t enforce that on each other, at least it is a recommendation. Dean said he would move forward along those lines.
- Auditability of EV and other CABF Guidelines
Ben said that recent discussions on the list have been about audit cycles and revisions to the BRs and EV Guidelines and revisions to the audit criteria, and how we can coordinate development cycles with effective dates, etc. Related to our previous discussion, we want to make sure that what we adopt is not confusing from an auditability standpoint. For example, during the period of any particular CA’s one-year audit cycle, we might have three conflicting requirements, and we don’t want the auditor to have to figure out that only during a three-month period a particular requirement applied. Kirk asked whether we could talk to the auditors about making everything effective as of each July 1. Jeremy said that there should be some flexibility. Ben also said that a CA that is implementing the next version of a guideline shouldn’t be penalized for moving ahead of a deadline.
- Discuss Revisions to Web Site
Ben mentioned that there is a link at the bottom of the Front Page of the wiki to a draft mock-up of a new web site with blank pages and that he had copied content from the current CAB Forum site into pages located there. Links that are grayed have no content. He is seeking volunteers of those interested in a particular subject area. Empty pages include “Information for Web Site Owners,” “Information for System Administrators,” etc. Also, the Final Guidelines pages are so out of date that they need to be entirely re-written. Ben said he could make a sign-in sheet available for volunteers or start a weekly telephone call on Tuesdays at 1400 or 1500 UTC, if people are interested.
- Any Other Business.
None.
- The next call will be Thursday, December 6th
Meeting adjourned.