CA/Browser Forum posts
Ballot 99 – Add DSA Keys
May 3, 2013 by Ben WilsonBallot 99 – Add DSA Keys (Passed) Motion begins Erratum begins In the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, Appendix A, add to each of the tables (1) Root CA Certificates, (2) Subordinate CA Certificates, and (3) Subscriber Certificates a new row with these three column entries (comma-separated): Minimum DSA modulus and divisor size (bits) ***, L= 2048, N= 224 or L= 2048, N= 256, L= 2048, N= 224 or L= 2048, N= 256
May 3, 2013 by Ben WilsonBallot 99 – Add DSA Keys (Passed) Motion begins Erratum begins In the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, Appendix A, add to each of the tables (1) Root CA Certificates, (2) Subordinate CA Certificates, and (3) Subscriber Certificates a new row with these three column entries (comma-separated): Minimum DSA modulus and divisor size (bits) ***, L= 2048, N= 224 or L= 2048, N= 256, L= 2048, N= 224 or L= 2048, N= 256
2013-05-02 Minutes
May 2, 2013 by Ben WilsonNotes of meeting CAB Forum 2 May 2013 Version 2 Present: Steve Roylance, Ryan Koski, Erwann Abalea, Mads Henriksveen, Atilla Biler, Mert Ozarar, Ben Wilson, Eddie Nigg, Dean Coclin, Arno Fiedler, Jeremy Rowley, Wayne Thayer, Joe Kaluzny, Robin Alden, Gerv Markham, Rich Smith, Stephen Davidson, Phillip Hallam Baker, Rick Andrews and Geoff Keating Guests: Andy Regenscheid, Deb Cooley, Mike Jenkins, Mike Boyle, and Jeff Burke Agenda review: Version 1 of the agenda was reviewed. Gerv suggested that Item 9 (Mozilla Inclusion Policy and Certificate Suspension) be stricken from the agenda because it had already been handled online with discussion between Jeremy and Kathleen. Review Reference CP (NIST IR 7294): Andy explained that NIST has worked with NSA in an effort to raise the bar for public CAs. The reference CP is a starting point that will be used to get feedback from a wider audience. Work was motivated by security incidents from CAs that have highlighted the need for stronger security practices. The audit programs used in the past have not been strong enough to find the security weaknesses. This effort is part of an effort to push for stronger CA security practices. He said that we should all be working towards the same goal. It is his hope that a well-written set of baseline requirements in the standard RFC 3647 format will advance CA statements of policies and practices that will improve audits. The draft CP was based on input from CA/B Forum guidelines, audit programs, Federal PKI, NIST documents, the Canadian government, and PKI industry standards and papers. The federal PKI common policy was used as a starting point because it has a strong baseline that is achievable and it has well-written procedural requirements, trusted role requirements, key management and certificate lifecycle sections. It references the CA/B Forum identity proofing sections. The reference CP improves upon the common policy CP by adding more detail to access control, system integrity, isolation and boundary protection, remote access, and network monitoring … those are the areas that needed to be addressed based on the threats we have seen. NIST is seeking feedback from CA/B Forum members, U.S. Government PKI, and other organizations. It should be recognized that this is just a starting point for further work. Our partners should recognize that for this to have impact, we need to have input so that everyone will see value in the requirements and so that the CA/B Forum will incorporate these into its own requirements and so that other industry organizations will integrate this reference CP into their PKIs. As you may be aware, there are related efforts underway ITU-T, ISO, CA/B Forum, etc. This document is up for public comment until June 7. The authors would be happy to go over things in more detail, but they just wanted to give an overview of what they would like to achieve. Question from Ben: When you were working on it, did you try to accommodate an international audience? Answer: We are hoping this will be applicable to a broad community. If there are things that anyone doesn’t feel are appropriate for the international community, please let us know, give us feedback, and we will look at that. Comment from Stephen: For outside the US, there are CAs that may be under a voluntary accreditation scheme in their country where the local regulator will have a requirement that is similar, but will make the terms more specific and demand that they be stated in the CP or CPS and be given higher priority. If so, when they see a standard originating out of the US, they are more hesitant to embrace it. Response: We all have an interest in having a consolidated set of requirements to use as a baseline that we can work towards, and we will all be better off if we can get behind some minimum expectations on the security controls in place. Question from Ben: Are delegated third parties addressed in the reference CP? Such as internal CAs, external CAs, or registration authorities? Is there anything in here about that, or has that not been addressed? Answer: There is an expectation in the reference CP that all requirements would apply equally to other organizations, like RAs. Question from Rick: Would it be helpful to point out certain sections that are more important for us to focus on in providing our comments, or highlight those that people should especially look at? Answer: The computer lifecycle and network security control sections (5, 6 and 7), the certificate lifecycle sections, section 5 on audit logging, incident response, and personnel security controls are also places we changed the most, but we would like to get feedback on the document as a whole. The other sections should be looked at carefully as well, for those of you who are not familiar with the existing federal PKI Common Policy. Question from Ben: Have you thought about creating an annotated or other type of document to go along with the reference CP, maybe as interpretive guidance? Because certificate policy documents are often brief and narrowly written, and with audit criteria this is often the case. Comment from Arno: Yes, with ETSI, the audit guidelines, interpretative documents, audit scheme, and the education and qualification of the auditors are very important, sometimes more important than the policy itself. Answer: We agree-the audit scheme is very important. As we’ve been working on this we’ve been hoping to develop clear requirements for auditing programs. In response to the question on annotated format, that’s what we’ve tried to do. We’ve been calling it a reference policy because that is kind of what it is. There are sections that are best left to a particular PKI community to determine for themselves. Some sections have suggested text or blanks to allow for this. There are also informational sections to explain what kind of security we’d like to achieve and what information we’d like to see in the area of certificate application requirements. Comment from Jeremy: We will prepare comments and send them over to NIST before the deadline. Response: We would be happy to sit down and talk to people individually or as a subgroup interested in this. Ben: Digicert will provide comments, but does everyone want to provide comments on a unified prospective using a comments matrix. Dean: Does the CA/B Forum want to organize a comment matrix? Jeremy: Maybe as a group we could highlight the differences between the BRs and this document. Going through there are a lot of things that are different and it would be interesting for CA/B Forum members to see these, and we would be interested to hear why certain things were left out and others were put in, etc. Dean: Vetting and authentication are an example of how this has been left open. Jeremy: But there is discussion of how to handle an individual requesting a certificate, and the validity periods of certificates are also addressed. Deb: The certificate validity periods are one of those situations where you would fill in for your particular need. The guideline for our recommendation of an appropriate number could be changed. Jeremy: The concern that I have and maybe Kirk has as well is that this becomes a baseline for what CAs are expected to be doing. The problem is how this gets implemented by browser root programs or how CAs may interpret what they should have to do to comply with it. If people are free to change the numbers however you want, then how can it be a baseline. Andrew: We’ve had conversations about how different communities might implement this, but each community will have to look at the considerations applicable to them when deciding how they implement this and apply the appropriate numbers. The intent is just as guidance, and there is not set validity period that you should meet. It is just a Reference CP that people can use when writing their policies, but it also represents a minimum set of policies that we feel is appropriate for publicly trusted CAs. Stephen: There is a lot of support across the industry for improving the security of CAs, but during the process of creating a universal vetting practice across the industry we realized that it gets pretty tough. For example, just one thing that popped up as I leaf through this document is Section 3.1.3, it says that CAs should not issue pseudonym certificates, but under many international and European accreditation schemes are allowed, or may be required for certain uses, as long as the real person is identified by the CA. Deb: The CP uses the group certificate and the role certificate, rather than a pseudonymous certificate. Stephen said he’d send some information to Ben for the minutes. Subsequently Stephen sent the following for inclusion in the minutes, “ETSI TS 101 456, Section 7.3.3, allows “the name of the signatory or a pseudonym which shall be identified as such”, which ties into the EU Data Protection directive as an option. The rules are the CA must know the person’s real identity and must divulge to authorities under appropriate process/circumstance.” Arno also requested the following addition “TS 101 456 from 2007 is only about qualified certificates issued to natural persons for electronic signatures that are legally equivalent to hand-written signatures. A qualified certificate is a certificate that meets the requirements of Annex I of Directive 1999/93/EC and is provided by a certification-service-provider fulfilling the requirements of Annex II of the Directive. So EU Data Protection is important to TSPs/CAs wanting to issue qualified certificates in Europe. Also, ETSI and CEN are working within the EU Mandate/460 to develop a new set of standards for the prosed EU EIDAS Regulation.” Andy: We really hope to influence change in the sector, but NIST is not a regulatory authority, and we cannot effectuate change on our own. Please look at it and give feedback on where it doesn’t go far enough or goes too far, and we hope you find this valuable and will provide feedback as appropriate. Approve Minutes of 18 April 2013: Approved as published. Review of Ballots: Ballot 99 closes on Friday, 3-May-2013. Rick stated that he received comments and questions from Tom on the Guidelines for EV processing, but that he hasn’t had time to look at those yet. Atilla said that they had voted in favor of Ballot 99, but they did not see that vote come across on the public list. Ben said that we can confirm that vote offline via direct email. On the OCSP responder concern, Joe said that he is concerned and surprised that Microsoft does not have plans to revise their product to prevent OCSP “good” responses for non-issued certificates. Stephen said that CoreStreet responders might have trouble, too. Joe said he was surprised that more CAs were not alarmed and that he will either need to look at switching to another solution, which will take time, or change the Baseline Requirements, depending on how many vendors are supporting the change. Phillip said that CoreStreet (HID/ActiveIdentity) and any other company that wants to remain in this business should support a mandated feature. It may be that Microsoft developers responsible for this product segment are not aware of this requirement or they lack incentive to change this functionality because it comes “free”, as part of Microsoft’s CA product. Stephen D. said that some CAs were uneasy about putting a hard deadline on this when it was adopted because it was an external dependency on whether it would be supported. The August deadline might be easy for CAs who have developed their own OCSP responders internally, but it is difficult for CAs who depend on off-the-shelf solutions. Arno said that it may be difficult for CAs in Europe where this non-compliance might be found as a security violation. Stephen said that a similar issue exists with Certificate Transparency for smaller CAs relying on their off-the-shelf infrastructure. Joe suggested that the OCSP provision might be modified to a “should” rather than a “must” because he cannot meet the August date, or the CA/B Forum needs to make a definitive statement that the requirement will not be modified. Steve R. said that he was in discussions with Microsoft on the EKU problem and would raise this issue, too. Phillip said that it is one thing to slip the date, but we shouldn’t relieve vendors from the pressure to get their product up to spec. Otherwise, we’ll come back in a year and none of them will have done anything to fix their product. Stephen said we ought to look at OCSP responder behavior, just like the IETF WPKOPS project on client behavior is looking at clients. Rick noted that yesterday he had sent around an email from CoreStreet that indicated they had a workaround called Smart Data Bridge, but that users of that product would have to evaluate for themselves whether it would be in compliance with the BRs. Steve R. said that we may have lost 18 months by not moving forward better on this with the vendors of software products like Microsoft and Entrust. Other Announcements – Date Change for Ankara F2F (September 24-26); recent ITU Actions: Ben announced that it looked like the Ankara F2F meeting would be held on September 24-26 based on the comments that had been received. With ITU, it appears that there have been efforts to revise X.509. Copies of the documents are being circulated for review. The concern is that with the ITU the group perpetuates with involvement from too few participants in industry implementing the standard. The other problem also is that there are national debates going on as well. NFC Forum proposal to revise Signature Record Type Definition – Technical Specification (NFCForum-TS-Signature_RTD-1.0): Jeremy announced that Tony Rosati of Blackberry/RIM and the NFC Forum wanted to know whether CAs were interested in developing policy similar to EV Code Signing and issuing certificates that would be used to support digitally signed RFID tags that would have a very long validity period. Any CA interested in getting involved in reviewing draft policies and working on this should contact Jeremy. Continued discussion of audit requirements / technical constraints for external subCAs: Steve R. said that as part of the technical constraints issue he has been discussing the EKU for OCSP signing with Microsoft. The EKU for OCSP signing would need to be present for certain CAs and sub-CAs. He does not have solid feedback needed to resolve the issue, but by sometime next week he hopes to have edits to the current draft on his ballot to address Name Constraints, Auditing and EKUs. Steve provided an overview of the issues. First, there is an open issue on how the audit requirements flow down to third parties when technical constraints like name constraints are available for sub CAs. If we are able to clarify how browsers will treat these then we have alternative ways for growing the use of PKI with an expanded CA hierarchy. One option is to hold a straw poll to determine whether the Baseline Requirements apply to everybody in the system or whether there are possible exceptions. Dean expressed concern that Apple does not enforce the critical name constraints policy, and if we allow this exception for 10% of the ecosystem, then how is that 10% protected? Steve said that it is a chicken-and-egg problem – how will Apple implement it if no CAs are implementing it? If auditing is mandated, then it just becomes too expensive, so implementing name constraints is a better, more cost-effective alternative. Similar to the CoreStreet example earlier, we need to make sure that name constraints are clearly written in the requirements so that they can be used in different architectures, including such things as signing certificates and other solutions beyond what we’re talking about today. Rick said that we need to define how name constraints should work, because even across browsers today it is clear that there is disagreement on how they should work. Steve noted that the use of directory names as a minimum standard, as discussed on the mailing list, is an example of how tying this down will allow us to grow name constraints for client certificates and other uses and models. At some point we’ll be able to switch over from non-critical to critical, but we’ll need to get that 10% support from Apple, but they’re not going to do it unless we’re actually using them and relying on them. Rick said that as Dean asked, is it unsafe to use them until we have better understanding and agreement across all browsers on (a) using them and (b) how to use them? Steve said that the unsafe alternative is not to use them and instead rely on auditing, which is completely open so that if you are attacked the whole world is exposed, but if you use name constraints the attack surface is smaller–you can only attack the browsers that don’t support them or the domain name in that certificate, so I’m a proponent of name constraints and to make them critical because as has been shown in the past you can’t rely on audits. Dean said you could do a combination of both name constraints and audits until all browsers support name constraints. Steve said that he has that internal audits continue in Section 17, which CAs are going to be concerned with, which will tie into the OCSP responders as well, because we need to make sure that the database saves OCSP responses, and that will all tie in nicely, but if we mandate audit and name constraints, will only discourage people from using PKI, which is not what we want. Rick said that he disagreed with Steve’s statement that anyone using name constraints can only shoot themself in the foot. For example, if there is a constraint on DNS names, but no constraints on IP addresses, some browsers will obviously constrain DNS names, but then browsers are inconsistent with what that means for IP addresses. Some browsers will interpret that to mean the certificate cannot sign anything for an IP address, while others will interpret it to mean that IP addresses are not restricted, so that leaves IP addresses open to attack. Those subCAs can shoot anyone else in the foot, as long as they don’t violate the specified name constraint. Steve said that particular issue was included in the Mozilla inclusion policy, which I’ve included in the wording-permitted and excluded, so IP addresses are mandated to be taken out, so you don’t have that issue, and all browsers should be moving that direction. Audits help you close the holes, but they do not help you reduce the attack surface. Rick said that while Internet Explorer, Chrome, and Firefox might implement name constraints in some form, we do not know whether they allow issuance of IP address certificates when there is only a name constraint. Steve said that IP addresses are not currently the major means of attack, it is the *.google.com certificate that is an issue. Rick said that there may be more scenarios beyond the IP address example, given the confusion around interpretation of name constraints. Ben said he believed that the US Government and DOD seem to know how to implement name constraints, and they must have browser validation criteria they use to test, for instance, whether Safari meets the processing requirements. Dean suggested that this issue be at the top of the agenda during the meeting in Munich. Steve said that he would have some materials ready to review prior to the F2F meeting, but he would like to tie down Microsoft on this issue first. Dean said he and Rick just want to know how we’re improving the security of the ecosystem. Steve said that by deploying more PKI for enterprises using client certificates with Microsoft CAs instead of usernames and passwords we’re enabling better enterprise security that is needed with the growing use of mobile devices, etc. As we’ve discussed in Tokyo and Paris we cannot audit everyone, so we need to find better technical constraints that work to reduce risk. So with name constraints we need to convince Apple to close that gap. Stephen Davidson seconded Steve Roylance’s comments. Any Other Business: Dean said that 28 people from 10 different countries have signed up to attend the F2F meeting in Munich. Anyone who has not registered yet should do so as soon as possible because we are almost out of rooms. Next Code Signing meeting will be next Wednesday, May 8, at 1600 UTC, this time using the same CABF dial-in number as for this call. Next CAB Forum call will be Thursday, May 16, at 1600 UTC. Meeting adjourned.
May 2, 2013 by Ben WilsonNotes of meeting CAB Forum 2 May 2013 Version 2 Present: Steve Roylance, Ryan Koski, Erwann Abalea, Mads Henriksveen, Atilla Biler, Mert Ozarar, Ben Wilson, Eddie Nigg, Dean Coclin, Arno Fiedler, Jeremy Rowley, Wayne Thayer, Joe Kaluzny, Robin Alden, Gerv Markham, Rich Smith, Stephen Davidson, Phillip Hallam Baker, Rick Andrews and Geoff Keating Guests: Andy Regenscheid, Deb Cooley, Mike Jenkins, Mike Boyle, and Jeff Burke Agenda review: Version 1 of the agenda was reviewed. Gerv suggested that Item 9 (Mozilla Inclusion Policy and Certificate Suspension) be stricken from the agenda because it had already been handled online with discussion between Jeremy and Kathleen. Review Reference CP (NIST IR 7294): Andy explained that NIST has worked with NSA in an effort to raise the bar for public CAs. The reference CP is a starting point that will be used to get feedback from a wider audience. Work was motivated by security incidents from CAs that have highlighted the need for stronger security practices. The audit programs used in the past have not been strong enough to find the security weaknesses. This effort is part of an effort to push for stronger CA security practices. He said that we should all be working towards the same goal. It is his hope that a well-written set of baseline requirements in the standard RFC 3647 format will advance CA statements of policies and practices that will improve audits. The draft CP was based on input from CA/B Forum guidelines, audit programs, Federal PKI, NIST documents, the Canadian government, and PKI industry standards and papers. The federal PKI common policy was used as a starting point because it has a strong baseline that is achievable and it has well-written procedural requirements, trusted role requirements, key management and certificate lifecycle sections. It references the CA/B Forum identity proofing sections. The reference CP improves upon the common policy CP by adding more detail to access control, system integrity, isolation and boundary protection, remote access, and network monitoring … those are the areas that needed to be addressed based on the threats we have seen. NIST is seeking feedback from CA/B Forum members, U.S. Government PKI, and other organizations. It should be recognized that this is just a starting point for further work. Our partners should recognize that for this to have impact, we need to have input so that everyone will see value in the requirements and so that the CA/B Forum will incorporate these into its own requirements and so that other industry organizations will integrate this reference CP into their PKIs. As you may be aware, there are related efforts underway ITU-T, ISO, CA/B Forum, etc. This document is up for public comment until June 7. The authors would be happy to go over things in more detail, but they just wanted to give an overview of what they would like to achieve. Question from Ben: When you were working on it, did you try to accommodate an international audience? Answer: We are hoping this will be applicable to a broad community. If there are things that anyone doesn’t feel are appropriate for the international community, please let us know, give us feedback, and we will look at that. Comment from Stephen: For outside the US, there are CAs that may be under a voluntary accreditation scheme in their country where the local regulator will have a requirement that is similar, but will make the terms more specific and demand that they be stated in the CP or CPS and be given higher priority. If so, when they see a standard originating out of the US, they are more hesitant to embrace it. Response: We all have an interest in having a consolidated set of requirements to use as a baseline that we can work towards, and we will all be better off if we can get behind some minimum expectations on the security controls in place. Question from Ben: Are delegated third parties addressed in the reference CP? Such as internal CAs, external CAs, or registration authorities? Is there anything in here about that, or has that not been addressed? Answer: There is an expectation in the reference CP that all requirements would apply equally to other organizations, like RAs. Question from Rick: Would it be helpful to point out certain sections that are more important for us to focus on in providing our comments, or highlight those that people should especially look at? Answer: The computer lifecycle and network security control sections (5, 6 and 7), the certificate lifecycle sections, section 5 on audit logging, incident response, and personnel security controls are also places we changed the most, but we would like to get feedback on the document as a whole. The other sections should be looked at carefully as well, for those of you who are not familiar with the existing federal PKI Common Policy. Question from Ben: Have you thought about creating an annotated or other type of document to go along with the reference CP, maybe as interpretive guidance? Because certificate policy documents are often brief and narrowly written, and with audit criteria this is often the case. Comment from Arno: Yes, with ETSI, the audit guidelines, interpretative documents, audit scheme, and the education and qualification of the auditors are very important, sometimes more important than the policy itself. Answer: We agree-the audit scheme is very important. As we’ve been working on this we’ve been hoping to develop clear requirements for auditing programs. In response to the question on annotated format, that’s what we’ve tried to do. We’ve been calling it a reference policy because that is kind of what it is. There are sections that are best left to a particular PKI community to determine for themselves. Some sections have suggested text or blanks to allow for this. There are also informational sections to explain what kind of security we’d like to achieve and what information we’d like to see in the area of certificate application requirements. Comment from Jeremy: We will prepare comments and send them over to NIST before the deadline. Response: We would be happy to sit down and talk to people individually or as a subgroup interested in this. Ben: Digicert will provide comments, but does everyone want to provide comments on a unified prospective using a comments matrix. Dean: Does the CA/B Forum want to organize a comment matrix? Jeremy: Maybe as a group we could highlight the differences between the BRs and this document. Going through there are a lot of things that are different and it would be interesting for CA/B Forum members to see these, and we would be interested to hear why certain things were left out and others were put in, etc. Dean: Vetting and authentication are an example of how this has been left open. Jeremy: But there is discussion of how to handle an individual requesting a certificate, and the validity periods of certificates are also addressed. Deb: The certificate validity periods are one of those situations where you would fill in for your particular need. The guideline for our recommendation of an appropriate number could be changed. Jeremy: The concern that I have and maybe Kirk has as well is that this becomes a baseline for what CAs are expected to be doing. The problem is how this gets implemented by browser root programs or how CAs may interpret what they should have to do to comply with it. If people are free to change the numbers however you want, then how can it be a baseline. Andrew: We’ve had conversations about how different communities might implement this, but each community will have to look at the considerations applicable to them when deciding how they implement this and apply the appropriate numbers. The intent is just as guidance, and there is not set validity period that you should meet. It is just a Reference CP that people can use when writing their policies, but it also represents a minimum set of policies that we feel is appropriate for publicly trusted CAs. Stephen: There is a lot of support across the industry for improving the security of CAs, but during the process of creating a universal vetting practice across the industry we realized that it gets pretty tough. For example, just one thing that popped up as I leaf through this document is Section 3.1.3, it says that CAs should not issue pseudonym certificates, but under many international and European accreditation schemes are allowed, or may be required for certain uses, as long as the real person is identified by the CA. Deb: The CP uses the group certificate and the role certificate, rather than a pseudonymous certificate. Stephen said he’d send some information to Ben for the minutes. Subsequently Stephen sent the following for inclusion in the minutes, “ETSI TS 101 456, Section 7.3.3, allows “the name of the signatory or a pseudonym which shall be identified as such”, which ties into the EU Data Protection directive as an option. The rules are the CA must know the person’s real identity and must divulge to authorities under appropriate process/circumstance.” Arno also requested the following addition “TS 101 456 from 2007 is only about qualified certificates issued to natural persons for electronic signatures that are legally equivalent to hand-written signatures. A qualified certificate is a certificate that meets the requirements of Annex I of Directive 1999/93/EC and is provided by a certification-service-provider fulfilling the requirements of Annex II of the Directive. So EU Data Protection is important to TSPs/CAs wanting to issue qualified certificates in Europe. Also, ETSI and CEN are working within the EU Mandate/460 to develop a new set of standards for the prosed EU EIDAS Regulation.” Andy: We really hope to influence change in the sector, but NIST is not a regulatory authority, and we cannot effectuate change on our own. Please look at it and give feedback on where it doesn’t go far enough or goes too far, and we hope you find this valuable and will provide feedback as appropriate. Approve Minutes of 18 April 2013: Approved as published. Review of Ballots: Ballot 99 closes on Friday, 3-May-2013. Rick stated that he received comments and questions from Tom on the Guidelines for EV processing, but that he hasn’t had time to look at those yet. Atilla said that they had voted in favor of Ballot 99, but they did not see that vote come across on the public list. Ben said that we can confirm that vote offline via direct email. On the OCSP responder concern, Joe said that he is concerned and surprised that Microsoft does not have plans to revise their product to prevent OCSP “good” responses for non-issued certificates. Stephen said that CoreStreet responders might have trouble, too. Joe said he was surprised that more CAs were not alarmed and that he will either need to look at switching to another solution, which will take time, or change the Baseline Requirements, depending on how many vendors are supporting the change. Phillip said that CoreStreet (HID/ActiveIdentity) and any other company that wants to remain in this business should support a mandated feature. It may be that Microsoft developers responsible for this product segment are not aware of this requirement or they lack incentive to change this functionality because it comes “free”, as part of Microsoft’s CA product. Stephen D. said that some CAs were uneasy about putting a hard deadline on this when it was adopted because it was an external dependency on whether it would be supported. The August deadline might be easy for CAs who have developed their own OCSP responders internally, but it is difficult for CAs who depend on off-the-shelf solutions. Arno said that it may be difficult for CAs in Europe where this non-compliance might be found as a security violation. Stephen said that a similar issue exists with Certificate Transparency for smaller CAs relying on their off-the-shelf infrastructure. Joe suggested that the OCSP provision might be modified to a “should” rather than a “must” because he cannot meet the August date, or the CA/B Forum needs to make a definitive statement that the requirement will not be modified. Steve R. said that he was in discussions with Microsoft on the EKU problem and would raise this issue, too. Phillip said that it is one thing to slip the date, but we shouldn’t relieve vendors from the pressure to get their product up to spec. Otherwise, we’ll come back in a year and none of them will have done anything to fix their product. Stephen said we ought to look at OCSP responder behavior, just like the IETF WPKOPS project on client behavior is looking at clients. Rick noted that yesterday he had sent around an email from CoreStreet that indicated they had a workaround called Smart Data Bridge, but that users of that product would have to evaluate for themselves whether it would be in compliance with the BRs. Steve R. said that we may have lost 18 months by not moving forward better on this with the vendors of software products like Microsoft and Entrust. Other Announcements – Date Change for Ankara F2F (September 24-26); recent ITU Actions: Ben announced that it looked like the Ankara F2F meeting would be held on September 24-26 based on the comments that had been received. With ITU, it appears that there have been efforts to revise X.509. Copies of the documents are being circulated for review. The concern is that with the ITU the group perpetuates with involvement from too few participants in industry implementing the standard. The other problem also is that there are national debates going on as well. NFC Forum proposal to revise Signature Record Type Definition – Technical Specification (NFCForum-TS-Signature_RTD-1.0): Jeremy announced that Tony Rosati of Blackberry/RIM and the NFC Forum wanted to know whether CAs were interested in developing policy similar to EV Code Signing and issuing certificates that would be used to support digitally signed RFID tags that would have a very long validity period. Any CA interested in getting involved in reviewing draft policies and working on this should contact Jeremy. Continued discussion of audit requirements / technical constraints for external subCAs: Steve R. said that as part of the technical constraints issue he has been discussing the EKU for OCSP signing with Microsoft. The EKU for OCSP signing would need to be present for certain CAs and sub-CAs. He does not have solid feedback needed to resolve the issue, but by sometime next week he hopes to have edits to the current draft on his ballot to address Name Constraints, Auditing and EKUs. Steve provided an overview of the issues. First, there is an open issue on how the audit requirements flow down to third parties when technical constraints like name constraints are available for sub CAs. If we are able to clarify how browsers will treat these then we have alternative ways for growing the use of PKI with an expanded CA hierarchy. One option is to hold a straw poll to determine whether the Baseline Requirements apply to everybody in the system or whether there are possible exceptions. Dean expressed concern that Apple does not enforce the critical name constraints policy, and if we allow this exception for 10% of the ecosystem, then how is that 10% protected? Steve said that it is a chicken-and-egg problem – how will Apple implement it if no CAs are implementing it? If auditing is mandated, then it just becomes too expensive, so implementing name constraints is a better, more cost-effective alternative. Similar to the CoreStreet example earlier, we need to make sure that name constraints are clearly written in the requirements so that they can be used in different architectures, including such things as signing certificates and other solutions beyond what we’re talking about today. Rick said that we need to define how name constraints should work, because even across browsers today it is clear that there is disagreement on how they should work. Steve noted that the use of directory names as a minimum standard, as discussed on the mailing list, is an example of how tying this down will allow us to grow name constraints for client certificates and other uses and models. At some point we’ll be able to switch over from non-critical to critical, but we’ll need to get that 10% support from Apple, but they’re not going to do it unless we’re actually using them and relying on them. Rick said that as Dean asked, is it unsafe to use them until we have better understanding and agreement across all browsers on (a) using them and (b) how to use them? Steve said that the unsafe alternative is not to use them and instead rely on auditing, which is completely open so that if you are attacked the whole world is exposed, but if you use name constraints the attack surface is smaller–you can only attack the browsers that don’t support them or the domain name in that certificate, so I’m a proponent of name constraints and to make them critical because as has been shown in the past you can’t rely on audits. Dean said you could do a combination of both name constraints and audits until all browsers support name constraints. Steve said that he has that internal audits continue in Section 17, which CAs are going to be concerned with, which will tie into the OCSP responders as well, because we need to make sure that the database saves OCSP responses, and that will all tie in nicely, but if we mandate audit and name constraints, will only discourage people from using PKI, which is not what we want. Rick said that he disagreed with Steve’s statement that anyone using name constraints can only shoot themself in the foot. For example, if there is a constraint on DNS names, but no constraints on IP addresses, some browsers will obviously constrain DNS names, but then browsers are inconsistent with what that means for IP addresses. Some browsers will interpret that to mean the certificate cannot sign anything for an IP address, while others will interpret it to mean that IP addresses are not restricted, so that leaves IP addresses open to attack. Those subCAs can shoot anyone else in the foot, as long as they don’t violate the specified name constraint. Steve said that particular issue was included in the Mozilla inclusion policy, which I’ve included in the wording-permitted and excluded, so IP addresses are mandated to be taken out, so you don’t have that issue, and all browsers should be moving that direction. Audits help you close the holes, but they do not help you reduce the attack surface. Rick said that while Internet Explorer, Chrome, and Firefox might implement name constraints in some form, we do not know whether they allow issuance of IP address certificates when there is only a name constraint. Steve said that IP addresses are not currently the major means of attack, it is the *.google.com certificate that is an issue. Rick said that there may be more scenarios beyond the IP address example, given the confusion around interpretation of name constraints. Ben said he believed that the US Government and DOD seem to know how to implement name constraints, and they must have browser validation criteria they use to test, for instance, whether Safari meets the processing requirements. Dean suggested that this issue be at the top of the agenda during the meeting in Munich. Steve said that he would have some materials ready to review prior to the F2F meeting, but he would like to tie down Microsoft on this issue first. Dean said he and Rick just want to know how we’re improving the security of the ecosystem. Steve said that by deploying more PKI for enterprises using client certificates with Microsoft CAs instead of usernames and passwords we’re enabling better enterprise security that is needed with the growing use of mobile devices, etc. As we’ve discussed in Tokyo and Paris we cannot audit everyone, so we need to find better technical constraints that work to reduce risk. So with name constraints we need to convince Apple to close that gap. Stephen Davidson seconded Steve Roylance’s comments. Any Other Business: Dean said that 28 people from 10 different countries have signed up to attend the F2F meeting in Munich. Anyone who has not registered yet should do so as soon as possible because we are almost out of rooms. Next Code Signing meeting will be next Wednesday, May 8, at 1600 UTC, this time using the same CABF dial-in number as for this call. Next CAB Forum call will be Thursday, May 16, at 1600 UTC. Meeting adjourned.
Announcing the formation of the Code Signing Working Group – Call for Participants
April 22, 2013 by Ben WilsonThe CA/Browser Forum has chartered a Code Signing Working Group, the purpose of which is to come up with Baseline Requirements to reduce the incidences of signed malware. The CA/Browser Forum would like to invite interested third parties to participate. The working group meets bi-weekly by phone and had its first face to face meeting in Munich on June 13th coinciding with the regular CA/Browser Forum meeting. Interested parties will need to:
April 22, 2013 by Ben WilsonThe CA/Browser Forum has chartered a Code Signing Working Group, the purpose of which is to come up with Baseline Requirements to reduce the incidences of signed malware. The CA/Browser Forum would like to invite interested third parties to participate. The working group meets bi-weekly by phone and had its first face to face meeting in Munich on June 13th coinciding with the regular CA/Browser Forum meeting. Interested parties will need to:
2013-04-18 Minutes
April 18, 2013 by Ben Wilson18 April 2013 Present: Ben Wilson, Mads Henriksveen, Jeremy Rowley, Gerv Markham, Rick Andrews, Tom Albertson, Ryan Koski, Atsushi Inaba, Wayne Thayer, Robin Alden, Eddy Nigg, Kirk Hall, Wendy Brown, Atilla Biler, Stephen Davidson, Don Sheehy, and Joe Kaluzny Agenda review: Version 2 of the agenda was reviewed, which included discussion of Ballot 99, which Rick had requested previously. Ben mentioned that he will start keeping a list of some action items not on the agenda at the bottom of each agenda he sends out, just to keep them in mind. Approve Minutes of 4 April 2013: Mads asked for clarification on Item 14 in the draft minutes regarding Phill’s draft white paper on code signing, which had not been circulated to the Forum as indicated. Tom clarified that it had been sent only to the code signing working group. With that correction, the minutes of 4 April 2013 were approved for publication. Announcements and Review of Ballots: There are no ballots pending. Ben stated that several CABF members had requested that we move our Ankara F2F meeting away from October 1-3 because it conflicted with their OTA meeting in Bellevue, Washington, on those same dates. Gerv suggested that we hold another straw poll. DSA Keys Ballot 99: Rick is writing up the text on Ballot 99 to amend Appendix A to add DSA 2048 to list of approved algorithms. Report of NIST Workshop: Ben explained that the purpose of the workshop was to review the industry solutions that require multi-stakeholder involvement-mainly DANE and CT-although several similar technologies were discussed. There was general consensus that DNSSEC when fully deployed as a separate technology will help improve the overall security of the Internet. One of the barriers to DANE is the lack of full DNSSEC deployment throughout the Internet. There are also issues with CT that need to be worked out-primarily who will run and manage the CT logs and will they be sufficiently robust. Another issue is how many log records will have to be embedded in certificates. Stephen noted that the presentations on CT are helpful in understanding how the log servers will work, but there is little information on what CAs will need to do to participate in pilot testing. It was suggested that we start a list discussion to gather more information on this topic and that the resources be collected on a wiki page dedicated to CT. Rick said that Adam, Ben, and Emilia from Google have been very helpful. Stephen said that CAs developed in-house will have an easier time implementing CT than those who have acquired their systems off-the-shelf.During the NIST Workshop OCSP Stapling and Must-Staple were also discussed. The take-away is that we need to identify remaining gaps that prevent implementing OCSP must-staple as a solution. Another take-away is that CAs need to do a better job working with their customers and provide better advice on server configurations and the use of SSL/TLS. The Dutch Government presented on Diginotar. Fox-IT’s time-lapse animation of OCSP responses for the *.google.com from the Black Tulip Report was shown a couple of times. (http://youtu.be/wZsWoSxxwVY). It showed how use of the certificate concentrated in Iran, but then spread to other parts of the world as a result of DNS redirection, etc. Jens Bender presented on his work on strengthening audit requirements for issuers of qualified certificates and EV certificates. Ben presented an overview of current audit frameworks, including ETSI and WebTrust.Other technology discussions included CAA, HSTS, pinning, and hierarchical geographic / DNS scoping. There was consensus that, putting aside any potential anti-competitive lock-in concerns, CAA would not break anything and so should be considered as a partial solution. HSTS and pinning received favorable responses. Pure hierarchy-based geographic and jurisdiction-based domain name scoping were not received favorably. However, critical name constraints were viewed as a potential solution, provided that all browsers implement them in a similar fashion. Rick noted that no solution was identified as a fix-all, so the recommendation was that all parties should try and implement as many of the solutions as they deemed feasible so that we can experiment with them and get a better feel for what works and what doesn’t work. Another related point was to identify how well each of the solutions mitigates the threat and/or vulnerability that it aims to address. Wendy said that from her perspective, the workshop organizers did not want everyone going off and trying all of these different solutions, but that they were trying to get people to come to consensus on which of the solutions would provide the biggest bang for the buck, as opposed to spreading efforts across all potential efforts. Ben noted that NIST was hoping a coordinating group would emerge that would give direction and encouragement to the efforts already underway at IETF, CAB Forum, etc. Ballot 89 Relaunch of EV Processing Guidelines: Rick updated the document following the F2F in Mountain View and would like to put forth a ballot that either adopts an update to the current EV Processing Guidelines on the web site or removes the current one. Ben suggested that the ballot could be made in the alternative, as outlined by Rick. Rick noted that there has been a certain degree of fatigue from those who have worked on the revisions thus far. Tom offered to review the current version 2 draft with people at Microsoft and Mozilla, including Kathleen, but it might be a couple weeks before he is able to provide feedback. Browser implementation of Critical Name Constraints and use of DirectoryName and DNSName to technically constrain external subCAs: Ben said that this agenda item was related to a proposal by Steve Roylance to amend the Baseline Requirements, which has been discussed on the list, and comments made during the NIST Workshop about whether browsers were properly implementing critical name constraints, particularly Apple. The proposed ballot also addresses audit exceptions when sub CAs are technically constrained, and the Mozilla policy includes similar language. While Steve could not be on this call, he had previously noted that we need to keep moving forward on resolving this critical name constraints issue. Wendy reminded the group that certificate validation will fail if you add a subject alternative name that does not follow the pattern used for critical name constraints (for instance, if you include a GUID/UUID in the SAN). A take-away from criticality is that it makes it more likely that something will fail if you don’t do it right, and this might be one reason why Apple has not implemented it. Robin noted that criticality, per se, is not the issue with Apple–Apple simply ignores name constraints altogether, but Geoff has indicated previously that fixes to name constraints are part of Apple’s product plans. However, no one currently has information on the status of that fix. Rick said we should also check to see if all other browsers handle critical name constraints properly.Kirk wondered whether the proposed ballot was to address audits of RAs under Mozilla’s policy, but that anyone with problems implementing name constraints should take it up with the particular browser. Robin said that Mozilla has a clear position, but how it fits in with the root programs of other browsers is also an issue. Ben asked whether Tom could discuss name constraints with Kathleen if he is going to talk to her anyway to see whether all browsers have a common approach to name constraints. Tom and Gerv said that they support name constraints, so there may not be an issue to discuss. Any Other Business: Joe Kaluzny raised the issue from the Baseline Requirements’ prohibition on responding “good” to a non-issued certificate (Ballot 80). August 1, 2013 is fast approaching, and we had said that we would revisit this prohibition if CRL-based systems had not been patched in time. Joe said that their Microsoft OCSP responder is based on CRLs and they are concerned that a patch will not be available. He also said that some vendors may decide not to support that capability. Gerv said that before we take action to postpone this deadline, it would be good if we could get reports back from vendors who are not compliant with this requirement to find out what their plans are, and if they are going to patch this, their anticipated date of delivery. Joe said that from his last discussions with Microsoft he did not believe that they were planning to patch this. Wendy and Jeremy discussed whether the revision to RFC 2560 would also address this. Ben said that those planning on presenting a ballot to eliminate or delaying the requirement should also present what efforts they are making to address the problem of “non-issued” certificates and moving certificate status technology forward beyond where we are today-not that this suggestion is tied to the ballot, but just advice that they should be looking at the solutions that are out there-including security mitigations that show their risk posture is the same or better than modifying their software to not respond “good” for non-issued certificates.Next Code Signing meeting will be next Wednesday, April 24, at 1600 UTC. Next CAB Forum call will be Thursday, May 2nd, at 1600 UTC. Meeting adjourned.
April 18, 2013 by Ben Wilson18 April 2013 Present: Ben Wilson, Mads Henriksveen, Jeremy Rowley, Gerv Markham, Rick Andrews, Tom Albertson, Ryan Koski, Atsushi Inaba, Wayne Thayer, Robin Alden, Eddy Nigg, Kirk Hall, Wendy Brown, Atilla Biler, Stephen Davidson, Don Sheehy, and Joe Kaluzny Agenda review: Version 2 of the agenda was reviewed, which included discussion of Ballot 99, which Rick had requested previously. Ben mentioned that he will start keeping a list of some action items not on the agenda at the bottom of each agenda he sends out, just to keep them in mind. Approve Minutes of 4 April 2013: Mads asked for clarification on Item 14 in the draft minutes regarding Phill’s draft white paper on code signing, which had not been circulated to the Forum as indicated. Tom clarified that it had been sent only to the code signing working group. With that correction, the minutes of 4 April 2013 were approved for publication. Announcements and Review of Ballots: There are no ballots pending. Ben stated that several CABF members had requested that we move our Ankara F2F meeting away from October 1-3 because it conflicted with their OTA meeting in Bellevue, Washington, on those same dates. Gerv suggested that we hold another straw poll. DSA Keys Ballot 99: Rick is writing up the text on Ballot 99 to amend Appendix A to add DSA 2048 to list of approved algorithms. Report of NIST Workshop: Ben explained that the purpose of the workshop was to review the industry solutions that require multi-stakeholder involvement-mainly DANE and CT-although several similar technologies were discussed. There was general consensus that DNSSEC when fully deployed as a separate technology will help improve the overall security of the Internet. One of the barriers to DANE is the lack of full DNSSEC deployment throughout the Internet. There are also issues with CT that need to be worked out-primarily who will run and manage the CT logs and will they be sufficiently robust. Another issue is how many log records will have to be embedded in certificates. Stephen noted that the presentations on CT are helpful in understanding how the log servers will work, but there is little information on what CAs will need to do to participate in pilot testing. It was suggested that we start a list discussion to gather more information on this topic and that the resources be collected on a wiki page dedicated to CT. Rick said that Adam, Ben, and Emilia from Google have been very helpful. Stephen said that CAs developed in-house will have an easier time implementing CT than those who have acquired their systems off-the-shelf.During the NIST Workshop OCSP Stapling and Must-Staple were also discussed. The take-away is that we need to identify remaining gaps that prevent implementing OCSP must-staple as a solution. Another take-away is that CAs need to do a better job working with their customers and provide better advice on server configurations and the use of SSL/TLS. The Dutch Government presented on Diginotar. Fox-IT’s time-lapse animation of OCSP responses for the *.google.com from the Black Tulip Report was shown a couple of times. (http://youtu.be/wZsWoSxxwVY). It showed how use of the certificate concentrated in Iran, but then spread to other parts of the world as a result of DNS redirection, etc. Jens Bender presented on his work on strengthening audit requirements for issuers of qualified certificates and EV certificates. Ben presented an overview of current audit frameworks, including ETSI and WebTrust.Other technology discussions included CAA, HSTS, pinning, and hierarchical geographic / DNS scoping. There was consensus that, putting aside any potential anti-competitive lock-in concerns, CAA would not break anything and so should be considered as a partial solution. HSTS and pinning received favorable responses. Pure hierarchy-based geographic and jurisdiction-based domain name scoping were not received favorably. However, critical name constraints were viewed as a potential solution, provided that all browsers implement them in a similar fashion. Rick noted that no solution was identified as a fix-all, so the recommendation was that all parties should try and implement as many of the solutions as they deemed feasible so that we can experiment with them and get a better feel for what works and what doesn’t work. Another related point was to identify how well each of the solutions mitigates the threat and/or vulnerability that it aims to address. Wendy said that from her perspective, the workshop organizers did not want everyone going off and trying all of these different solutions, but that they were trying to get people to come to consensus on which of the solutions would provide the biggest bang for the buck, as opposed to spreading efforts across all potential efforts. Ben noted that NIST was hoping a coordinating group would emerge that would give direction and encouragement to the efforts already underway at IETF, CAB Forum, etc. Ballot 89 Relaunch of EV Processing Guidelines: Rick updated the document following the F2F in Mountain View and would like to put forth a ballot that either adopts an update to the current EV Processing Guidelines on the web site or removes the current one. Ben suggested that the ballot could be made in the alternative, as outlined by Rick. Rick noted that there has been a certain degree of fatigue from those who have worked on the revisions thus far. Tom offered to review the current version 2 draft with people at Microsoft and Mozilla, including Kathleen, but it might be a couple weeks before he is able to provide feedback. Browser implementation of Critical Name Constraints and use of DirectoryName and DNSName to technically constrain external subCAs: Ben said that this agenda item was related to a proposal by Steve Roylance to amend the Baseline Requirements, which has been discussed on the list, and comments made during the NIST Workshop about whether browsers were properly implementing critical name constraints, particularly Apple. The proposed ballot also addresses audit exceptions when sub CAs are technically constrained, and the Mozilla policy includes similar language. While Steve could not be on this call, he had previously noted that we need to keep moving forward on resolving this critical name constraints issue. Wendy reminded the group that certificate validation will fail if you add a subject alternative name that does not follow the pattern used for critical name constraints (for instance, if you include a GUID/UUID in the SAN). A take-away from criticality is that it makes it more likely that something will fail if you don’t do it right, and this might be one reason why Apple has not implemented it. Robin noted that criticality, per se, is not the issue with Apple–Apple simply ignores name constraints altogether, but Geoff has indicated previously that fixes to name constraints are part of Apple’s product plans. However, no one currently has information on the status of that fix. Rick said we should also check to see if all other browsers handle critical name constraints properly.Kirk wondered whether the proposed ballot was to address audits of RAs under Mozilla’s policy, but that anyone with problems implementing name constraints should take it up with the particular browser. Robin said that Mozilla has a clear position, but how it fits in with the root programs of other browsers is also an issue. Ben asked whether Tom could discuss name constraints with Kathleen if he is going to talk to her anyway to see whether all browsers have a common approach to name constraints. Tom and Gerv said that they support name constraints, so there may not be an issue to discuss. Any Other Business: Joe Kaluzny raised the issue from the Baseline Requirements’ prohibition on responding “good” to a non-issued certificate (Ballot 80). August 1, 2013 is fast approaching, and we had said that we would revisit this prohibition if CRL-based systems had not been patched in time. Joe said that their Microsoft OCSP responder is based on CRLs and they are concerned that a patch will not be available. He also said that some vendors may decide not to support that capability. Gerv said that before we take action to postpone this deadline, it would be good if we could get reports back from vendors who are not compliant with this requirement to find out what their plans are, and if they are going to patch this, their anticipated date of delivery. Joe said that from his last discussions with Microsoft he did not believe that they were planning to patch this. Wendy and Jeremy discussed whether the revision to RFC 2560 would also address this. Ben said that those planning on presenting a ballot to eliminate or delaying the requirement should also present what efforts they are making to address the problem of “non-issued” certificates and moving certificate status technology forward beyond where we are today-not that this suggestion is tied to the ballot, but just advice that they should be looking at the solutions that are out there-including security mitigations that show their risk posture is the same or better than modifying their software to not respond “good” for non-issued certificates.Next Code Signing meeting will be next Wednesday, April 24, at 1600 UTC. Next CAB Forum call will be Thursday, May 2nd, at 1600 UTC. Meeting adjourned.
2013-04-04 Minutes
April 4, 2013 by Ben WilsonHere are the notes from our penultimate telephone call, held 4 April 2013. Item 14 was amended from the draft minutes to clarify that the draft white paper had been circulated to the code signing working group and not the CABF as a whole. Present: Rick Andrews, Atsushi Inaba, Dean Coclin, Robin Alden , Steve Roylance, Wayne Thayer, Gerv Markham , Ben Wilson, Rich Smith, Phil Hallam-Baker Agenda review: The agenda was not sent out ahead of time due to a mix-up but was announced at the start of the meeting.
April 4, 2013 by Ben WilsonHere are the notes from our penultimate telephone call, held 4 April 2013. Item 14 was amended from the draft minutes to clarify that the draft white paper had been circulated to the code signing working group and not the CABF as a whole. Present: Rick Andrews, Atsushi Inaba, Dean Coclin, Robin Alden , Steve Roylance, Wayne Thayer, Gerv Markham , Ben Wilson, Rich Smith, Phil Hallam-Baker Agenda review: The agenda was not sent out ahead of time due to a mix-up but was announced at the start of the meeting.
2013-03-21 Minutes
March 21, 2013 by Ben WilsonNotes of meeting CAB Forum 21 March 2013 Version 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 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.
March 21, 2013 by Ben WilsonNotes of meeting CAB Forum 21 March 2013 Version 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 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.
2013-03-07 Minutes
March 7, 2013 by Ben WilsonNotes of meeting CAB Forum 7 March 2013 Version 2 Present: Rick Andrews, Atsushi Inaba, Dean Coclin, Ryan Koski, Atilla Biler, Jeremy Rowley, Gerv Markham, Brad Hill, Ryan Sleevi, Ben Wilson, Rich Smith, Wayne Thayer, Phill Hallam-Baker, Mads Henriksveen, and Cornelia (Connie) Enke Agenda review: The agenda was reviewed and approved. Approve Minutes of 21 February 2013: The minutes of 21 February 2013 were approved as published. Review of Ballots: Ben stated that Ballots 96, 97 and 98 all passed. He didn’t send out an announcement yet that Ballot 98 passed, but he will. Straw Poll for the meeting in Turkey, Ben has not tallied up the total, but he thinks that B and C are in the running and that B is the choice. He will confirm it and send out an email.
March 7, 2013 by Ben WilsonNotes of meeting CAB Forum 7 March 2013 Version 2 Present: Rick Andrews, Atsushi Inaba, Dean Coclin, Ryan Koski, Atilla Biler, Jeremy Rowley, Gerv Markham, Brad Hill, Ryan Sleevi, Ben Wilson, Rich Smith, Wayne Thayer, Phill Hallam-Baker, Mads Henriksveen, and Cornelia (Connie) Enke Agenda review: The agenda was reviewed and approved. Approve Minutes of 21 February 2013: The minutes of 21 February 2013 were approved as published. Review of Ballots: Ben stated that Ballots 96, 97 and 98 all passed. He didn’t send out an announcement yet that Ballot 98 passed, but he will. Straw Poll for the meeting in Turkey, Ben has not tallied up the total, but he thinks that B and C are in the running and that B is the choice. He will confirm it and send out an email.
Ballot 98 – Public Voting
February 22, 2013 by Ben WilsonBallot 98 – Public Voting (Passed) Motion Gervase Markham made the following motion, and Jeremy Rowley and Kirk Hall endorsed it: Motion begins The CAB Forum wishes to require that the votes of Members on CAB Forum ballots be public information. For avoidance of doubt, a consequence of this change is that the voting information for ballots will be public. Therefore, effective immediately, the CAB Forum Bylaws[0] are updated as follows:
February 22, 2013 by Ben WilsonBallot 98 – Public Voting (Passed) Motion Gervase Markham made the following motion, and Jeremy Rowley and Kirk Hall endorsed it: Motion begins The CAB Forum wishes to require that the votes of Members on CAB Forum ballots be public information. For avoidance of doubt, a consequence of this change is that the voting information for ballots will be public. Therefore, effective immediately, the CAB Forum Bylaws[0] are updated as follows:
Ballot 97 – Prevention of Unknown Certificate Contents
February 21, 2013 by Ben WilsonBallot 97 – Prevention of Unknown Certificate Contents (Passed) Motion Jeremy Rowley made the following motion, and Ryan Hurst and Robin Alden endorsed it: Motion begins Erratum begins A. In Section 10.2.3, after the first paragraph, insert: “The CA SHALL establish and follow a documented procedure for verifying all data requested for inclusion in the Certificate by the Applicant.”
February 21, 2013 by Ben WilsonBallot 97 – Prevention of Unknown Certificate Contents (Passed) Motion Jeremy Rowley made the following motion, and Ryan Hurst and Robin Alden endorsed it: Motion begins Erratum begins A. In Section 10.2.3, after the first paragraph, insert: “The CA SHALL establish and follow a documented procedure for verifying all data requested for inclusion in the Certificate by the Applicant.”
2013-02-21 Minutes
February 21, 2013 by Ben WilsonNotes of meeting CAB Forum 21 February 2013 Version 1 Present: Phill Hallam-Baker, Ben Wilson, Atsushi Inaba, Ryan Koski, Eddy Nigg, Gerv Markham, Wayne Thayer, Sara Morris, Dean Coclin, Paul Lambert, Atilla Biler, Rich Smith, Mads Henriksveen, Sissel Hoel, Mert Ozarar, Jeremy Rowley, Stephen Davidson, Tom Albertson, Agenda Review The agenda was reviewed and Item 6 (Wi-Fi Alliance) was moved forward to Agenda Item 4. Approval of the Minutes of 24 January 2013. The minutes of 24 January 2013 were approved as published.
February 21, 2013 by Ben WilsonNotes of meeting CAB Forum 21 February 2013 Version 1 Present: Phill Hallam-Baker, Ben Wilson, Atsushi Inaba, Ryan Koski, Eddy Nigg, Gerv Markham, Wayne Thayer, Sara Morris, Dean Coclin, Paul Lambert, Atilla Biler, Rich Smith, Mads Henriksveen, Sissel Hoel, Mert Ozarar, Jeremy Rowley, Stephen Davidson, Tom Albertson, Agenda Review The agenda was reviewed and Item 6 (Wi-Fi Alliance) was moved forward to Agenda Item 4. Approval of the Minutes of 24 January 2013. The minutes of 24 January 2013 were approved as published.