2013-07-11 Minutes
Notes of meeting
CAB Forum
11 July 2013
Present: Kirk Hall, Atsushi Inaba, Ben Wilson, Dean Coclin, Rick Andrews, Rich Smith, Eddy Nigg, Geoff Keating, Mads Henriksveen, Wayne Thayer, Jeremy Rowley, Steve Roylance, Gerv Markham, Mert Ozarar, Robin Alden, Phill Hallam Baker, Cornelia Enke
Agenda review: The agenda was reviewed. Steve Roylance said he wanted time to discuss technical constraints. Jeremy Rowley said he wanted time to discuss what defines an SSL certificate covered by the Baseline Requirements and convening the working group on EV. Rick would like to see if there is any update on browser vendors using CAA. He said it seems like Google has already implemented it. He asked Geoff whether CAA testing was on the radar for Apple, and Geoff said it was.
Minutes of 27 June 2013: The minutes were approved for publication as circulated.
Ballots: Ben- Ballot 104 passed. Ben will revise 103 again and send it out again, hopefully this afternoon. Dean indicated that Oracle is still interested in joining the Forum. Dean noted that sent an email response to Richard from WoSign to submit an application and he hasn’t heard anything back. Ben will send an email asking for when that might be. Dean said they indicated they would join the CAB Forum once they have an approved root.
Kirk asked whether the adoption of Ballot 104 immediately allowed automatic verification by email now since now a two-person vetting requirement for this validation step would be nonsensical. Because that is not vetting per se, is that outside the two-vetter requirement?
Wayne- just to clarify the scenario, are you talking about when a person has a multi-domain / multi-SAN certificate and just want to add a new domain name to it?
Kirk – no, we just changed the EV rule on how to verify a domain, at the EV level, for a customer. It used to be that you had to do a manual lookup or do various things, and a second vetter, Vetter2, however you do it, when confirming whatever Vetter1 did would check it and confirm that it was correct. Since the automatic email method allows you to send a challenge email to confirm domain validation, and it is added to the OV account and no further vetting is done, it just happens automatically.
Steve – It seems that Vetter2 is checking on everything that Vetter1 has done and is pulling in all of that information that has Vetter1 has collected.
Jeremy – That is where 11.12 comes in and says that Vetter2 has to review the entire corpus of the information.
Kirk – so assuming your process is sound, then no one, neither Vetter1 nor Vetter2, has to do anything to add a domain at the EV level, is that what you were just saying?
Steve – Vetter1 has to make sure that he has the results in the system and Vetter2 does too.
Ben - It is important to remember that the domain validation step is just a narrow part of the EV guidelines and it doesn’t mean that other things still don’t need to be done pursuant to the EV Guidelines. We can’t give recommendations on whether a process fully satisfies the EV guidelines.
Kirk – If no human is involved, then all that is required is that someone go in occasionally and look at the database and say, “Oh, look, here is another domain.”
Ben disagreed. The use of the phrase “automatic method” starts to imply that an interpretative opinion is being requested.
Wayne – There may be a gray area. I think the point is that you still have to do a correlation of all of the information in the certificate, but what about the case of a multi-domain certificate where you are just adding or removing a domain? My interpretation of the guidelines is that yes, you still need to do that, the guidelines do not allow the automatic process to replace that final step. [Narrative Summary by Ben: So we may need to put in a better explanation of what to do in this situation because that final step of due diligence / cross-correlation may not need to happen if the only change is an automated one.]
Ben – If someone thinks that the current statement of the requirements is unclear, then the burden is on the ones that feel they need clarification to propose an amendment to the EV Guidelines.
Steve- I think that is similar to something that I tried to raise in Ballot 92 that was shot down.
Ben- It does. This is also related to the request that we start a working group to review the EV Guidelines and identify where things don’t quite work.
Wayne offered to give Kirk an example offline of how he could validate things given the passage of Ballot 104.
Rich- asked when this process could be implemented. Jeremy said Ballot 104 was effective immediately. After a short discussion on audit / EV compliance , it was recommended that CAs have a discussion about this with their auditors, if needed.
- Critical Name Constraints / Technically Constrained Sub CAs. Steve- hopefully everyone’s had a chance to look at the emails I sent. Geoff, could you provide a short response, if you can, on Apple’s plans regarding name constraints? Gerv – it would be very helpful if Apple could provide us with its plans on implementing critical name constraints. Geoff – we don’t have anything to announce other than we do have a bug open on this topic.
Steve – Thanks, I didn’t mean to focus this on Apple other than for the purpose of pushing this ballot forward in order to protect as many people as we can. If we can move this forward then we can increase the use of name constraints and that may give more impetus for other to want to protect relying parties by recognizing name constraints as well. Apple would not vote in opposition to the ballot, but may not vote in favor of it either.
Rick – Since adoption by CABF is not the final step in implementation, because some browser programs may disagree (e.g. and still require audits), then getting this into the Baseline Requirements might be insufficient.
There have been a few cases where the browsers require extra or less than the Baseline Requirements. For instance, here Mozilla has said it will accept name constraints in place of audits, an approach that another browser might not follow.
Gerv – A lot of requirements evolve out of implementation by browsers first.
Rick - We need browsers to all be on the same page.
Steve – Ryan Sleevi isn’t on the phone, but I think we need clarification from him because I believe he indicated at some point that he did not believe that the BRs applied to Sub CAs, which is contrary to most of our understanding.
Gerv- we see this as a cheaper way to get more people to use SSL, which is what we’d like to see.
Ben – Rick, does Symantec have concerns beyond the across-the-board recognition of critical name constraints by browsers? If we can satisfy that, is there something beyond that issue?
Rick – I think Mozilla and Microsoft have now said that external sub CAs should be treated just like regular CAs, above and beyond the BRs, and that’s what they have put in additional language referring to that.
Eddy – I think that language preceded the BRs. Gerv, maybe this should be a ballot brought forward by Mozilla.
Gerv is going to talk to Kathleen about endorsing Steve’s ballot.
Ben- one of the action items might be for the CAs that support this ballot to have a side conversation with Google and Apple to understand their positions better and see whether we can reach consensus on this.
Steve- I was looking at this sub CA issue with Ryan, but I’ve always taken the position that external sub CAs that are technically constrained should have easier audit requirements and name constraints are a powerful tool
Ben – We could do this first as a policy adoption ballot and then follow with another ballot that changes the BRs.
Steve- I prefer to do it all in one go. If it fails, we can go back and separate out the more controversial aspects if there are any, but I think it’s a good ballot, and I know people are worried, and that’s why we’ve made changes as we’ve moved this forward.
- EKUs and What is an SSL Certificate subject to the Baseline Requirements: Jeremy – an interesting question- what really brings a certificate under coverage of the Baseline Requirements as an SSL server certificate? The BRs aren’t entirely clear about what the SSL certificate should / should not contain. Sometimes you see a certificate with all kinds of EKUs, but there is no requirement. Is it just the server authentication EKU that makes it an SSL certificate? And what if there’s no FQDN? What’s everyone’s thoughts on that? What makes it fall under the BRs? And which EKUs should be allowed and prohibited, and if prohibited then what?
Rick feels strongly, there should not be any other EKUs than what is specified in there. He sees some customers, e.g. VMware, that use the SSL key to encrypt some configuration data. That’s pretty dangerous. The more you allow a key to be used for other things, the more you open yourself up to attacks like the FLAME attack. Right now CABF guidelines say it should not contain any other EKUs.
Because we’ve run out of time on this call to discuss this in more detail, Jeremy will post this topic to the mailing list for further discussion. We can discuss it on online and on the next call.
Committee to Review EV Vetting: Jeremy- we had talked about setting up a working group for EV validation. He emailed Wayne a request for a new email list. Wayne will create a list starting with a half dozen people - Sigi, Simon, Melih, Moudrick, Robin, Rich, Eddy, Tom, Jeremy, Kirk, and Wayne.
CAA: Rick – As we discussed previously, in Munich we talked about CAA and wanted to get feedback from browser vendors who have implemented it and indicate how onerous it is to create one. Gerv said Mozilla’s approach was to lock it down at the root to prevent wildcard issuance and then lock down the high-value targets by naming Mozilla’s two CAs one by one. That is a good way to do this incrementally. Phill noted that the WebSec Group has been discussing certificate pinning recently. One issue that came up is–if you’re pinning to a CA, how do you identify the CA that you’re pinning to? This turns out to be a little more complicated than might be apparent. He recognized that the issues were similar to those in CAA, so he proposed that they use the same approach as CAA, i.e., a domain name held by the CA. For certificate pinned to a CA to work, it is necessary for the browser to map a CA identifier to the root from which they are allowed to issue, and that will be in the browser already. This requires that there be formalization of a consistent set of labels for purposes of CAA and pinning so that everyone isn’t creating their own schema. IANA doesn’t want to handle it, someone else will have to.
Ankara: Dean – We could hold the working group meetings on Tuesday. The CABF Meetings would cover all day Wednesday and Thursday. Dean will follow up with Mert and Atilla.
Next Call – July 25th.