2014-01-02 Minutes
2 January 2014
Version 1
1. Roll Call: Moudrick Dadashov, Caroline Oldenburg, Dean Coclin, Atsushi Inaba, Ben Wilson, Doug Beattie, Atilla Biler, Mads Henriksveen, Sissel Hoel, Rich Smith, Ryan Sleevi, Eneli Kirme, Jeremy Rowley, Rick Andrews, Imren Altepe, Robin Alden, and Kirk Hall
2. Agenda Review: Approved as presented.
3. Minutes: Minutes of 19 December 2013 were approved for publication as circulated.
4. Discussion of Ballots: Voting on Ballot 113 starts Monday. Ben will circulate a redlined version of the language and Ballot 89 (EV Processing) will be re-introduced today. Ballot 103 (Must Staple) is awaiting an OID assignment from IANA/IETF. Brian Smith will reach out to Sean Turner for clarification on when that might occur. Drafting work continues on other Ballot 107 (removing version specificity for ETSI TSs), 110 (Amendment to Bylaws), and 112 (Definition of “Internal Server Name”). Discussion of Ballot 108 (Scope of BRs ) continues on the mailing list and is agenda item number 6 below.
5. Upcoming Face-to-Face Meetings:
The plan for Mountain View will be for working groups to meet on Tuesday, February 18, beginning with discussions of code signing requirements, followed by discussions of SSL performance, and then the EV Guidelines. This will be followed on Wednesday and Thursday with CABF F2F meetings. For the Israel F2F in June, currently the plan is to meet in Eilat for the working group meetings on Monday, June 16, and the CABF F2F Tuesday and Wednesday the 17 and 18 of June. People can either fly or bus to Eilat on Sunday, 15 June, or thereafter depending on each person’s itinerary. Ben is interested in finding out who might be interested in traveling to Petra, Jordan, Thursday (and possibly other parts of Israel through Saturday before flying out the following Sunday). Kirk suggested that we ask people whether they know of any scheduling conflicts or other events during that week that might create some type of scheduling conflict. We should finalize this plan within the next two weeks. Ben will circulate information about the travel agency. A group greater than two people will reduce tour guide expenses.
6. Scope of BRs
Ben opened the floor for a discussion of the BRs and the definition of SSL certificate.
Ben: The issue involves what is the scope of the BRs, what is an SSL certificate, how do SSL certificates compare with other types of certificates like Qualified Certificates, Grid Certificates, etc..
Kirk: I think Jeremy was coming close to a definition in a recent email. We should publicly send it to the browsers and ask them whether they will incorporate the definition about the anyEKU EKU in their rules. I know that Iñigo had concerns. Would he say that QCs shouldn’t apply to the BRs? We should send it to the browsers and at the same time send it to those issuing QCs.
Jeremy: From a practical standpoint, there is a problem because they don’t qualify under the BRs, but depending if there is a domain name in them, they could be used for SSL.
Kirk: They should be compliant, unless they want to change their EKU. Maybe it will take them some time to become compliant, but we should put forth a concrete proposal so that we’re talking about adoption or not, instead of going around and around on this issue.
Ben: Maybe we make a statement in the BRs that makes it even more clear that certain types of profiles are clearly not conformant or compliant with the Baseline Requirements.
Moudrick: Maybe we should say that they must not be mixed. The concern as Jeremy just mentioned is that there is the potential that those certificates could be used for SSL, but if we say you cannot mix the use for qualified digital signatures, that might fix the issue. If QC can be recognized effectively as a QC for electronic signature, that means then that they shouldn’t be recognized for SSL.
Jeremy: They can because they contain the anyEKU EKU. Any certificate that has the anyEKU, or lacks the EKU, can be used as an SSL certificate.
Moudrick: But it depends on how you prioritize the interpretation of the certificate. So if we say we recognize it as qualified electronic signature certificate, then all other interpretations should be irrelevant. We should just say they can’t be mixed.
Jeremy: So if it has the qualified statement in it, that should be the best solution, but that only excludes qualified certificates. What if you have grid certificates or federal government certificates, which are not qualified certificates, but might have the anyEKU or other profiles that allow them for use as SSL without conforming to the Baseline Requirements?
Rick: Can they be used for SSL, rather not “can they”, but “are they intended” to be used for SSL? Not whether they can be, because Moudrick is saying they are not intended to be SSL certificates, so if a browser can detect that they are a qualified certificate, then they should not be used for SSL.
Jeremy: Right, but these are not necessarily qualified certificates. They are not intended for use as SSL, but they can be used because of the anyEKU EKU. My concern is that even if we create a rule for US Common Policy certificates and for EU QCs, we have to discover all of the others before we can create a hard-and-fast rule.
Rick: Can we have a rule that prohibits the anyEKU EKU. I think the browsers would support the position that anything used for public trusted SSL should not be used for anything else, so you could make the argument against the anyEKU. So could we phase out the anyEKU in these types of certificates over time?
Jeremy: That’s browser behavior, and the browsers have never been willing to support anything that mandates browser behavior. And you have the problem that RFC 5280 requires that you allow the anyEKU to be used for any EKU, as Ryan S. pointed out in his email. But, you’re right, because working with a smaller group of CAs that can manage the use of the anyEKU would be easier than changing the rules for everyone concerning the anyEKU.
Ryan: I can tell you that changes to use blacklist for QCs won’t work. We’re having this discussion to clarify the scope of the BRs for audit purposes, so I can understand the goal to find a short solution, but changing the browsers’ use of blacklists to recognize QCs is not in our plans. I am much more in favor of whitelists, and we do not want to alter behavior contrary to RFC 5280 unless we have to. I can’t see any short-term solution, so we need to get all of this discussion out in the open for a path forward, but I don’t think a black list is not going to be a solution.
Ben: I don’t see why we can’t refuse to follow RFC 5280 with a resolution that browsers “should not” allow a publicly trusted SSL certificate with the anyEKU to be used as an SSL certificate.
Ryan: RFC 5280 deals with path-building and how that path building goes on, so we could say that end entity certificate must have the TLS server EKU, but RFC 5280 says the anyEKU EKU must be treated as an EKU. With the Microsoft and Mozilla implementations, there is the EKU chaining behavior, which in part did not mitigate the Flame attack, because the Intermediate certificate did have the anyEKU EKU and not just the terminal services EKU.
Ben: What about saying “if you’re going to have the anyEKU, you have to have the TLS server EKU as well?”
Ryan: We could do that, but we are going to have to look at a large number of intermediate CAs and address the anyEKU.
Ben: I know it doesn’t solve the security issue with the intermediates, but can’t we just address end entity certificate requirements?
Ryan: Part of the goal is to define the scope in the requirements to include the intermediates, because there are parts of the Baseline Requirements that apply to intermediates. Once you determine how to handle multi-purposed intermediates that will help resolve potential confusion about the requirements. So there may be need for more discussion on the list.
Jeremy: I think it is something we can solve more easily once we convert to the RFC 3647 format and we can scope the CP to address security and data protection generally, and then validation requirements and profiles specifically to certificate types. All publicly trusted CA should be protected and securely operated and support the provision of revocation information. I say we address it as part of that if we cannot find some other more immediate solution.
Ben: We have gone over our time on this topic, but we should look at the RFC 3647 as part of the new year. Is there a committee so we can make progress from call to call. We need to make progress.
Jeremy: If we need to make progress, all we need is someone to review the documents.
Ben: We need someone to take up the responsibility to take a look at it.
Ryan: I think Tom and I committed to taking a look at it in the new year leading up to the face-to-face meeting in February.
Ben: I don’t want to flood the list with discussion of the RFC 3647 format, so just to keep a dialog going, maybe those interested like Tom, Ryan, Jeremy, me and others can keep this moving forward.
7. Pre-Certificates and CT Logging
Discussion still ongoing and deferred for continuation on the mailing list.
**8. Working Group Updates **
Dean said that meetings of the code signing group will re-commence. Of note, Microsoft would like to explore whether key storage could be required just on USB hardware, and not necessarily FIPS. If private keys still remain on the system then the USB storage just duplicates the risk of compromise. The EV Working Group will meet next week (9 January 2014). Performance Working Group will be looking at certificate profiles and OCSP to maximize performance of SSL.
**9. Any Other Business: ** None.
10. Next Phone Call: Thursday, January 16, 2014
**11. Meeting Adjourned **