2013-03-21 Minutes

Notes of meeting CAB Forum 21 March 2013 Version 1

1. Present: Rich Smith, Ben Wilson, Atsushi Inaba, Mads Henriksveen, Sissel Hoel, Eddy Nigg, Robin Alden, Dean Coclin, Wayne Thayer, Håvard Molland, Phill Hallam-Baker, Rick Andrews, Atilla Biler, Brad Hill, Geoff Keating, Kirk Hall, Jeremy Rowley, Cornelia Enke, Steve Roylance, Ryan Sleevi, and Stephen Davidson

2. Agenda review: The agenda was reviewed. Dean asked that we bring better closure on the issue with re-validation of customers whose information is older than 39 months. That discussion was added to the agenda under Other Business.

3. Approve Minutes of 7 March 2013: Ben noted that reference to an RFI in the Federal Register was mistaken and should be deleted. The minutes of 7 March 2013 were approved for publication as amended.

4. Announcements, Review of Ballots, and Discussion of BR v. 1.1.3: There are no ballots pending. Ben stated that draft version 1.1.3 of the Baseline Requirements has two new tables to address document changes and implementation dates along with narrative guidance on how to address audit issues when audit criteria are based on an earlier version of the BRs. There were no objections to publishing the revised version except a minor correction to the spelling of Turktrust, so version 1.1.3 will be placed on the CAB Forum web site.

5. Report on IETF 86 Orlando Proceedings by Jeremy, Phill, and others: Phill has talked to Sean Turner about the OCSP must-staple document and Sean recommended that the references to “policy” be removed, so he will re-work his internet draft.

Jeremy explained that several CAB Forum members presented at and participated in the presentations of the WPKOPS Working Group. One effort being undertaken is to document browser behavior, but in order to fully document this, we would want to issue certificates that do not comply with Baseline Requirements, just to test how a user agent reacts. There is a need to have some of them be publically trusted and publicly accessible, as long as those types are not extremely dangerous, which Phill noted he also had concerns about. Ryan S. said that there are some things that can be mimicked that will allow us to test more dangerous edge cases. Some things like caching behavior can be tested in a way that is not dangerous to potential clients, but how we do it depends on what we need to test. Jeremy said that we need to work on a test plan and figure out exactly what we need to test in order to see behavior. So we are assembling a list of behaviors to test, browsers we want to test, and if anyone would like to add conditions, then they should contact Ben to coordinate. Ben said that we would start a public area on Google Drive to share more of this information.

6. Discuss EV Processing Guideline Recommendations: Rick Andrews would like some additional comments to the Guidelines for the Processing of EV SSL Certificates, v. 2.0. He has addressed comments and removed items that could not be agreed upon, then he sent it out and has not heard from anyone on it, so please let him know if you agree that the draft should be considered “final”. Ben said he looked at it and had just a few comments– Section 6.2 talks about a root certificate having a designated OID, but that could be misunderstood as requiring that the OID be embedded in the root. Instead, it needs to be revised to make it clear that the OID is in the end entity’s certificate. In Section 7 where it talks about application vendors notifying the Forum, it should highlight that they should also advise the Forum about all of the other things listed in Section 7, and then Section 7.2 should also say something about the embedding agreements being non-discriminatory among CSPs. Rick asked that everyone get their comments in as soon as possible.

7. Discuss Technical Constraints in subordinate CAs via Name Constraints & Extended Key Usage: Steve Roylance introduced proposed revisions to the Baseline Requirements to address technical constraints as presented in Mozilla policy. The idea behind this is to address various changes brought on by the Baseline Requirements, which he had raised during the Paris F2F meeting in June 2011. We have been moving from what was best practice to what will be best practice and just like you can’t audit the world, you can’t audit all sub CAs-so as discussed in Paris, we need to figure out how to avoid expensive auditing. In the Mozilla guidelines this is done with technical constraints–you either need to have an audit or have technical constraints. The draft adds a new Section 9.7 for technical constraints and a new paragraph at the beginning of section 17 to address the audit issue. Ben said that there are other sections of the guidelines that need to be cross-referenced, especially near the top of the document, and other changes to make this proposal more clear. Rick Andrews said that an important concern is that if we allow an audit exception just when a technical constraint is implemented, then there is no guaranty about the other things that can go wrong, but he would be more inclined to agree if browsers were going to do checks for some of the more egregious things that would also be found in an audit. Steve said that it will be up to the audited CA to ensure compliance. Rick noted that there is a difference between a technically constrained sub CA that issues just 5 certificates and one that issues 10s of thousands. Steve said that in the latter situation, a CA may want to require that the sub CA to obtain an external audit, but it would be up to the CA. Rick said that there are certain things that a sub CA can mess up on, like key sizes, and other things that still create external risk that need to be looked at. Ryan S. said that Baseline Requirements are a good way of improving the industry across-the-board, Mozilla is confident in the ability of technical constraints to work, and as long as we’re not allowing other important things to be skipped, we’re just narrowing the scope of harm that a sub CA can do, which thereby adjusts the risk profile, so he thinks he would eventually support this proposal. Ben suggested that the CA or auditor could still look at the certificates issued by the sub CA to determine whether they violated part of the Baseline Requirements even if the auditor did not get into all of the Baseline Requirements that are procedurally implemented by the technically constrained sub CA. He also said that a flow-down chart could be prepared to assist with enforcing the BRs on sub CAs. Steve said that a chart like that would help explain the BRs to his customers.

8. Discuss OCSP Stapling and Short-Lived Certificates: Jeremy said that this proposal is a follow-up to the recent face-to-face during which we talked about a gap in the BRs that doesn’t require the AIA for OCSP stapling and that we also discussed short-lived certificates. Kirk said that we should make sure we are not being inconsistent with our support of revocation checking. Ryan said that he likes the idea of short-lived certificates but one issue that has not been raised before is the concern that a CA will mix up certificate profiles in their issuance pipelines and issue a long-lived certificate without revocation information. Ben said that this is a valid concern given several instances where this has happened in the past. Jeremy said that the Operational Requirements draft that he discussed previously might be a way to address that risk of erroneous certificate profiles, but there are serious problems that can happen in that area besides just issuing a long-lived certificate without revocation information. Ryan S. agreed that it is an issue that we need to address. Jeremy offered to work again on the Operational Requirements document with anyone who was willing to, in light of anything new that NIST might announce in April. Ryan S. also said that the short-lived certificates would be on par with other revocation mechanisms because of similar, related issues experienced with revocation checking on clients with out-of-date clocks.

9. Any Other Business: Dean said that he has learned recently that there is a huge exhibition going on in Munich the week of our meeting in June and that all of the hotels he had planned on having us use are booked, but that his team is looking at the town center for hotels. However, they have also been either booked or very expensive, so our plans may have to change. He will find out more this week and then let everyone know as soon as he has more information.

39-Month Re-Validation in BR Section 11: As a continuation of the discussion from the previous meeting, Dean said he would like to remove confusion about the re-vetting of customers who were customers from before the adoption of the Baseline Requirements. Kirk suggested that it be in the form of a ballot to modify the Baseline Requirements. Ben noted that in the previous discussion Ryan S. and Gerv were present, but Don wasn’t. Gerv had reported that Kathleen had said that an exception should not be made to the BRs. It was generally agreed in the conversation during this meeting that there was not a clear position from the browsers on what should be done. Ben said that there may be similar language in the EV Guidelines for existing customers that might be re-purposed here. Rick said his understanding of the exact problem is that in the BRs there is a requirement that documents originate from an official source, but the allowed practice prior to the BRs did not require strict recordkeeping on the source of the documents-so even though they may have the evidence needed, the current wording implies that they have to re-collect it from an official government source. Dean said that he would get together with Don and others and prepare a ballot.

The face-to-face meeting in Ankara, Turkey, will be October 1-3.

10. Meeting adjourned until the next call – Thursday, April 4th, at the same time.