2014-10-16 Minutes
Minutes of CA/Browser Forum, 16 October 2014
Antitrust Statement was read.
Roll Call: Aaron Kornblum, Atilla Biler, Ben Wilson, Dean Coclin, Atsushi Inaba, Phillip Hallam Baker, Doug Beattie, Eddy Nigg, Mads Henriksveen, Jeremy Rowley, Kelvin Yiu, Erwann Abalea, Robin Alden, Wayne Thayer, Tim Shirley, Gerv Markham, Patrick Tronnier and Tim Hollebeek
Agenda reviewed.
Minutes of 2 October 2014 were approved.
Ballot Review.
Ballot 136 – Dean Coclin of Symantec has been elected incoming Chair of the CA/B Forum. Dean and Ben will work together on the transition over the next few weeks. Please let Dean know if you would like to volunteer to help on any ongoing logistical items or CABF operations tasks.
Voting for Vice Chair will begin tomorrow/Friday, assuming that Ballot 137 passes. Ben will send out an email with the vice chair election ballot. Don and Arno have given Ben their email addresses to send the votes to, and Ben will distribute that information with the ballot. If any of the candidates wants to have a say in what the ballot says, then they can let Ben know, but he intends to will just list names in some alphabetical order and provide the voting procedure from the new bylaws and provide other information, such as the previously circulated candidate statements, with the ballot.
Dean: Thank you personally, and on behalf of all of the forum members, Ben, for all of the work you have done, and I will be calling on your help for a while. Thanks.
Ben: Dean has been doing a lot to help out and has done a great job as Vice Chair. Thanks, Dean, for helping out with various tasks that might have otherwise fallen through the cracks. I know that Dean will do a great job as Chair.
Dean: We have three great candidates for vice chair. We will submit all of the responses to Don and Arno, and then once the conclusion comes about, Don and Arno will announce the new vice chair.
Gerv: Single transferable vote or first past the post?
Ben: It’s just one vote. Unless there is a tie, then we do another election with just those two candidates.
Dean: We may need to reschedule the next meeting in two weeks, or Ben will have to run it if we don’t have a Vice Chair, because I’ll be on a plane and won’t be able be on the call.
Ben: We might want to look at the calendar anyway, with Thanksgiving coming up on the 30th in the U.S.
Other Ballots: Voting will close today on ballots 118, 123, 134, 135, 137, and 138. They all have quorum and a sufficient majority. Ben will update the bylaws and guidelines accordingly.
Voting on Ballot 133 (EV Insurance) started yesterday and will end next Wednesday.
Dean: What about Kelvin’s comments on Ballot 118, the SHA1 ballot? Kelvin posted a correction at the end of the comment period. The ballot is building on the version proposed before his correction.
Kelvin: If it needs to be corrected, then we will propose an amendment, but I’d rather have this ballot pass than pull the ballot and correct it. The issue is that it says a SHA-2 certificate can be issued from a SHA-1 certificate, but that is not Microsoft’s policy. We need to move away from SHA-1 to SHA-2.
6. Compressed CRLs.
Phill Hallam-Baker and Rob Stradling have come up with a new technique for compressing datasets that has an impact on SSL. They have written a paper and submitted it to IETF with an IP declaration – http://datatracker.ietf.org/doc/draft-hallambaker-compressedcrlset/.
The problem with CRLs is that they can be too big when you have to measure them in terms of megabytes. OCSP was an attempt to shrink the size of status information. Using this compression technique, we can compress a CRL of 250,000 certificates into a 170kb file. If we go to a delta-encoding scheme, then we can do that in 3kb with the scheme listed in the Internet Draft, and with Rob’s scheme we can do it in 1.5kb, which is less than OCSP traffic, so we do have a significant game changer in the PKI space. There are some caveats. You do need to change the way that you issue revocation lists. The reason that we can get this compression is that we have the bad and the good. All of those things you have to do for CT, you would have to do to compress CRLs. So, I’ll be presenting this at IETF in Hawaii with 10 minutes during the Monday Trans meeting, and then hopefully we’ll have some side meetings. This is a general technique that will make PKI available to many other applications than have been able to use PKI thus far.
Ben: So would this be a new CRL version number, like we have a v2 CRL right now? How would you identify this?
Phill: Basically we are talking about compression encoding. The data might get wrapped as ASN.1 in a CRL packet, but to get that type of compression, we are not using ASN.1. Basically, you would have a data blob that would have the data in it. How you would wrap that in a CRL, that would be a different question.
Ben: Where are you on this, you’ve come up with a way of doing it, how will this be communicated within systems. Until there is something that everyone can build to, you can’t move forward.
Phill: We are not anywhere close to building anything. First, we need to talk to the browser vendors and the rest of the community to see what we would want to build and what characteristics we would want it to have. We’ve got to decide how we want to build this technology, depending on what people think.
These could be delta CRLs or distributed by browsers like Google’s CRL Sets, etc. At the moment, we have design space, and I would like for people with opinions to let me know.
Discussion will be on an IETF list, which is the best place for all of this discussion to take place, given IPR concerns, and at this point, we are looking for early comments and reaching out to everyone here for additional suggestions to make sure we are covering all of the things that people care about.
Gerv: So did I hear you say you get 250,000 revocations in 1.3kb?
Phill: 250,000 revocations in 170kb. That’s all of the data. So, if you had a daily update, then the average number of certificates is about 136th of that, so the daily update of that would be about 1.5kb with Rob’s scheme and 3kb with mine. How it is done will depend on what people want and whether or not you want to do the extra work, and whether that makes sense. If we are talking about a difference of 1.5 kb, then doing a lot more work might not be more attractive. If we are working with huge CRL sets, then Rob’s scheme is worth the extra work. ASN.1 itself will add more, but if everyone wants to do CRL sets, and do it all at once, then Rob’s scheme is worth an extra code pass.
Ben: If it isn’t ASN.1, what is it?
Phill: ASN.1 does not have an efficient bit-packing scheme. We’d use run length encodings … we can compress the information depending on how you want to deploy it. It’s probably going to be an ASN.1 wrap-around, which is what is done for other stuff.
Erwann: You can also use packed encoding, PER, which is more efficient than JSON-B that you propose.
Phill: I’ll have to look at that, but on the outside, it is going to look different than the inside, like jpeg.
Erwann: So, if I understood your paper correctly, you need to have all certificates revoked and valid. You need to have certificate transparency. If you don’t have all the certificates, you cannot tell if a certificate is revoked or not.
Phill: You have to know what the population of certificates you issued is. And whoever has to produce your certificate revocation list must have it. Now that might be seen as blocking, but if you think about what we have been asked to do with EV and CT, we are already asked to look at that kind of infrastructure anyway, so that is a good reason to work on this now, while people are thinking about how they are going to build that infrastructure. People might want to look at compressed CRLs at the same time. CAs should know all of the certificates they’ve issued.
Erwann: Yes, but you are talking about something further than CAs.
Phill: One way for this to work would be for CAs to tell one party who will generate a composite CRL. Another way it can work is for CAs to generate the information locally and then communicate it up to a CA or to some central party, or we can go back to the model of each CA generating its own CRL. Instead of making a variety of CRL token, we might want to make them a variety of OCSP token because then we can use stapling. There is a whole range of ways in which we may want to approach this.
Kelvin: What are your plans for starting this within IETF?
Phill: I can’t really answer that question until we’ve had the Trans working group discussion in Hawaii.
- Continued Discussion of Policy OIDs for DV and OV Certificates:
Dean: a couple of weeks ago, we started a conversation about DV and OV OIDs. We had some discussion on the list as to the pros and cons. Ryan expressed some cons on the list of a technical nature. Erwann also made a point, as did Kelvin.
Some questions / discussions were:
Does making an OID mandatory break something, or is it because they are optional that people see potential issues?
Was one of the problems not the use of OIDs, but that if you are using your own OID, then using the CAB Forum OID might break certificate processing?
Can end entity certificates have 2 policy OIDs?
Only a few CAs have responded to the thread. In collecting feedback, most people are already using the BR OID or their own OID. Symantec is transitioning to use of the BR OID.
It also appears that the current inconsistency in CA practice on the use of OIDs makes it difficult for those who are trying to keep track of certificates, and I’m not sure where we are right now.
Ben: Wayne has had some opinions on this in the past, if you can work with Wayne on language to see what he is in agreement with, then maybe DigiCert will endorse it.
Dean: Erwann, can you explain your issue?
Erwann: If you don’t’ have the BR OID or the Any Policy OID in a CA certificate, then you cannot have the BR OID in the end entity certificate. For CAs that do have a policy OID, they can have either their own OID, or the CAB Forum OIDs, but requiring the CAB Forum BR OID can create a problem with certificate processing.
Mads: What is the current practice for setting policy OIDs for certificates? We have both of the BR OIDs.
Dean: Identrust has their own OID and a BR OID. What does DigiCert do?
Ben/Jeremy: We use our own OIDs right now, but we don’t restrict our intermediates at all. It depends on which CA it is. We have some with “any Policy” in them, and there are a few CAs in which we don’t specify any policy-where we’re silent on it.
Robin: We use the Any Policy OID and specific OIDs for the issuing CA, because we include both policy OIDs. At Comodo, we have it according to our CPS and both in the intermediate.
Ben: Section 9.3.3 of the BRs addresses this. It talks about affiliates of the issuing CA and non-affiliates and whether or not they may use the Any Policy OID.
Robin: Appendix B also talks about it.
Kelvin: Windows has an API that calls to find out if a certificate’s chain is EV or not.
Someone: You can tell an OV certificate by the presence of the O field-whether it is supposed to be an OV certificate.
Jeremy: There are a lot of certificates with O fields out there that are not OV certificates. The certificate contents will be slightly different. That’s a problem for certificates issued before the BRs were enacted, like some that are valid for 10+ years, and you cannot rely on the not-before date if the CA issued it as a reissue. There are a lot of certificates out there that are non-compliant with the BRs–which makes it difficult to see if it is non-compliant, or just old.
Dean: I previously asked Netcraft for a list of non-compliant certificates, and I contacted several CAs privately about them. Some CAs were aware and they were old certificates, and some were caught off guard. This could be a problem if they are new certificates.
Robin: If particular OIDs need to be in end entity certificates and the issuing CA, then there are two ways to make that work. One way is putting the “anyPolicy OID” in there, and the other way is putting all possible OIDs in there.
Dean: Since we’re out of time today on this, this will have to be discussed again at some point.
EV Working Group: There are a couple of proposals the WG is working on, but they are not ready. They’ll have more after next week.
Code Signing Working Group: Dean recently sent a note to his contact at Oracle. The WG recently processed the feedback into a next draft that it will be circulating. We are basically at the end of the public comment period beginning of this month. After that we will be ready to see if we want to push it to a vote, or extend the comment period. After the comment period is over and we’re ready to come forward with a ballot we will send it out one more time as an exposure draft to show the changes.
10. Policy Review Working Group: During our last CABF teleconference, it was suggested that the RFC 3647 CP review assignments be placed on Bugzilla. Ben will put the volunteers and their assignments on the Bugzilla tracker as well as the other assignments and we’ll be looking for volunteers. We have a call every other week. Last week we reviewed the network security requirements and the WebTrust auditors’ comments and compared the audit criteria with the Network Security requirements. Nobody on the call could see anything that would cause a problem with passing the BR-with-Network-Security audit.
11. Any Other Business: SSL3 / Poodle: Is it time yet for everyone to move to TLS, is that the consensus?
Robin: we don’t really want people using SSLv3 if we can avoid it, but we’ve found that some legacy systems still want to communicate using SSL, and it’s the same problem that we are dealing with for SHA1. It will break a few clients, and some people are reluctant to break the clients. It is a subset of the same population of users that will be affected by the SHA1 deprecation. For instance, IE 6 supports TLS, it just isn’t enabled by default–there is a box there under advanced options for TLS 1, it just is not checked by default.
12. Next phone call - Thurs. Oct. 30 We’ll talk again in two weeks, if not sooner, and coordinate the meeting schedule with the Thanksgiving holiday.
13. Meeting adjourned.