2013-05-16 Minutes
Notes of meeting – CAB Forum – 16 May 2013 – Version 1
Roll Call: Ben Wilson, Rich Smith, Wayne Thayer, Mads Henriksveen, Rick Andrews, Dean Coclin, Geoff Keating, Eddy Nigg, Simon Labrum, Atsushi Inaba, Arno Fiedler, Jeremy Rowley, Ryan Koski, Tom Albertson, Atilla Biler, Robin Alden, Philip Hallam Baker, Ryan Sleevi
Agenda Review: Agenda was reviewed.
Approval of the Minutes of 2 May 2013: It was noted that Geoff and Mert were in attendance; Arno said he would like to submit additional information about ETSI policy, qualified certificates, and EU data protection for the minutes. Minutes of 2 May 2013 were approved, subject to review after those changes.
Ballots: None pending.
News – Recent Netcraft post: Rick said that he wanted to bring this to everyone’s attention in case we are asked questions about it. Ben said he had read through Netcraft’s post and regarding the 12-month validity of an intermediate CA’s CRL, it could be shortened in some browsers by changing the default settings to re-check for updated CRLs more frequently. Jeremy said the Baseline Requirements require revocation and new CRL issuance within 24 hours. Ben said one of the problems mentioned was that the CRL had been encoded differently, and he wanted to understand this issue better. Ryan Sleevi said that all browsers in their default configurations will treat the nextUpdate as the caching period, so assuming no other variables, they won’t be checking for CRL updates. He also explained that Chrome and Firefox use NSS for revocation checking. He has seen that some CAs take the DER-encoding of the ASN.1 structure and then encode it to Base64/PEM, while most implementations follow the standards, which require binary DER encoding of CRLs in binary octets. Sometimes this CA practice may be attributed to the fact that non-binary works in Internet Explorer, so there is the wrong assumption that it works elsewhere. Rick suggested that we add a requirement to the Baseline Requirements that CRLs be published in DER format. Ryan S. also said that negative serial numbers also are problem. Rick said that not only should we reach out to CAs on this, but we also should address what browsers are doing about revocation, because the article said that Firefox wasn’t checking the CRL at all, and we should be prepared to provide feedback on that issue as well.
Ryan S. said that there has been discussion on the Mozilla list about eliminating the preloading of CRLs that it does fetch and that Firefox has relied primarily on OCSP and not CRL fetching for some time.
Rick asked whether IE and Opera hard fail. Ryan S. said they actually soft fail because if you clear the caches and they download the CRL, then they would block access. However, blocking the download of the new CRL effectively defeats this because IE and Opera would continue allowing access to the site (i.e. no hard fail). Rick said that even if it doesn’t help with that security attack, it is a hole that should still be plugged because if you downloaded the CRL you could still block access to the site.
Tom said that his takeaway from the Netcraft article was that using CRLs with a long validity period provides little value. Eddy responded that the issue was discussed quite a bit with the Baseline Requirements and the problem with issuing more frequent CRLs was that the root key would have to be taken out every time to sign the CRL, and every time you take out the root, there are some risks. That was the reason why it was decided upon as one year. Tom said he was not recommending touching roots every day, but that he would like to continue a discussion of these issues during the face-to-face meeting in Munich, including the process of adding revoked intermediate CAs to the Disallowed Certificates in the Microsoft CTL.
- Discuss errata proposals and ballot drafts – Domain Validation Change Proposal: Rich said he feels that the proposal sent out by Jeremy yesterday has most of the problems worked out. Most language from the EV guidelines has been left in, but the proposal would allow additional BR techniques in section 11.2.6 where the applicant is not the registered owner of the domain. Jeremy said that the proposal basically allows two additional methods for control of a domain without a letter, and the requirement would still be to check the WHOIS records first, but if the applicant did not have the right information available through WHOIS, you could still validate the domain by other methods. The plan would be to get feedback now before it goes up to ballot so if anything needs to be changed, that we can resolve concerns. The proposal also follows Mozilla’s recommended practices for verifying domains. Eddy asked what the browsers might think of the proposal before we go forward with it.
Tom said it is mainly up to the members of the CAB Forum to decide and Microsoft did not have a position unless it affected code, processing, browser operations, etc. Geoff said he looked at the recent edits and that he still had concerns because it seemed to be the same thing re-edited-it proposes to remove “exclusive” and that the applicant knows about the certificate request, etc. Jeremy said that the latter part has been left in Section 11.2.6(3). Rich said that the “exclusive right to use” language has never been fully understood, and that is why we should take it out. Geoff asked whether the “exclusive right” caused problems. Jeremy said it does because it requires people to get attorney letters. Eddy asked what was wrong with WHOIS and you don’t need an attorney. Jeremy said that the WHOIS records are sometimes difficult to rely upon because of delays in updating them, etc. Eddy disagreed that WHOIS was difficult to update. Jeremy said many people don’t have access to update WHOIS, even though a party has control, but the information isn’t accurate. Eddy said that it was a problem in itself. Jeremy said another example is the subdomain where an applicant doesn’t really have direct control of the domain registration information but does have control of the subdomain, like the chemistry department at a university. Eddy said he didn’t believe that the Baseline Requirements allowed validation in that situation. Rich said the BRs do allow it under the 5 types of domain administration email addresses there is an option to create email addresses by pruning zero or more components from the requested FQDN. Ben noted that in the attorney opinion letter template at the end of the EV Guidelines it also mentions “exclusive control” and that some attorneys have crossed exclusive out when it is a subdomain.
Discuss errata proposals and ballot drafts –DC Naming Proposal: Ben said that Steve Roylance wanted to conduct further review of the proposal to modify the language concerning DC naming because he thought it might break something that GlobalSign was considering as a technical mechanism for controlling sub CAs through critical domain name constraints and would we also need to look at any RFC 5280 issues. Jeremy said that he had circulated some examples of what is being done in the Grid community and a proposed ballot as well. He said that the Grid community has well-established precedence in how they are implementing DC naming and that our language in the BRs should not override their precedent. The grid requirements have also been circulated for everyone to review. Ben asked what the plan should be. Jeremy said that there is an immediate need to revise the BRs so that publicly trusted Grid certificates are considered compliant and that issues raised by Steve R. could be reconciled later. Robin said that he supported the concern and ballot. Ryan S. said that since we are talking about domains we should understand the issue more, but it sounds like this is similar to the approach that has been taken with the OU field and verified vs. non-verified information. Ben suggested that an explanatory preface be added to the proposed ballot. Jeremy said he would take a look at the language and tweak it. .
Attorney/Accountant Jurisdictions: Ryan K. noted that the definitions section for accounting practitioner talks about “country” rather than just “jurisdiction”, but then section 11.10.2 for accountant it has to be in the jurisdiction, which seems to be an oversight/errata because in the section for legal practitioner/attorney, “in the country of” is still in there. He said that when he raised this last January, Kirk and Don Sheehy both weighed in to discuss state-to- state jurisdictional issues for accounting professionals, etc. Ben said he understood the issue and it shouldn’t be any different between accountants and attorneys in the same country, so he would support putting the word “country” back in. Ben will work on an errata motion to fix it and other similar typos that we’ve found in the BRs and EV Guidelines.
IPR Policy: Ben said that he had circulated a draft IPR Policy Agreement for Interested Parties and asked whether members could send it to their attorneys to take a look at. Tom said he forwarded it to Microsoft’s attorney, but there has been no time yet for a response. He asked whether Ben had forwarded it to the CABF IPR legal committee and he said he hadn’t but he would do that right away. Tom also expressed concern that this IPR is a subset of the CABF IPR – “Why do we need an IPR that appears to bind people to the subset?” Ben said he would expect the IPR legal review committee to discuss that issue.
Update – Code signing working group: Jeremy said that the WG had met last week and the meeting went well. They are working on verification requirements and key storage requirements. The general consensus is that identity vetting would be similar to what is required for OV, but they are looking for something else for key storage that is secure. Jeremy is working on a draft and hopes to have it done for next week’s call. Dean said he expects that we’ll be able to get everything ironed out in Munich. He also noted that a new member has joined the CA Browser Forum from the Czech Republic, and also another member request came in from someone in Germany.
Update – NFC Forum: Jeremy explained that the RFID industry is looking for a way to sign RFID tags. He asked whether we should have a working group inside or outside of the CAB Forum. One issue is that the NFC Forum has its own IPR Policy. Someone here would have to look at it and make sure it’s OK. Then we could sign an MOU and the relationship would be similar to CABF with ETSI. Jeremy asked if anyone was interested. Rick and Wayne said there might be sufficient interest within the CAB Forum to work on it, but if it becomes a battle over IP policies, then it’s not worth it. The group briefly discussed the advantages/reasons for working on this in the CA Browser Forum as opposed to another group. Jeremy noted that the documents are really about vetting and the processes would be very similar to EV Code Signing. Jeremy noted that most mobile browsers are part of the NFC Forum, and Ben noted that mobile browsers are becoming more important to the CA Browser Forum. There was discussion that we might or might not have all of the right players here, but so far we have enough to get started and the right documents. Wayne suggested that we might put the proposal for an MOU with the NFC Forum out on the list and see if anyone objects. If so, then those interested can go another way about it separate from the CAB Forum.
Agenda planning for Munich: Ben said that he and Dean will get together and put up a rough agenda on the wiki. Dean said that even more people have signed up to attend.
Next call: May 30.
Meeting adjourned.