Minutes of the F2F 30 Meeting in Ankara, Turkey, 24-26 September 2013

Notes of Face-to-Face Meeting in Ankara** **Sep. 25, Wednesday, and Sep. 26, Thursday, 2013

Present: Ben Wilson, Gerv Markham, Rick Andrews, Arno Fiedler, Moudrick Dadshov, Dean Coclin, Jeremy Rowley, Merve Baş, Emrah Durmaz, Davut Tokgöz, Richard Wang, Steve Roylance, Giichi Ishii, Atsushi Inaba, Tom Albertson, Sigbjorn Vik, Mert Özarar, Atilla Biler, Cornelia Enke, Robin Alden, Don Sheehy, Atilla Biler, Mert Ozarar, Melis Avci, Burak Kirimer, Imren Altepe, Onur Kocak, Çiğdem Altin, Yüksel Günaydin, Emrah Günel, Deniz Atak

Everyone introduced themselves, and Ben read the Antitrust Statement.

Working Group update from Jeremy The revocation working group has not progressed as expected so the group wanted to move conversations back to the main mailing list. Dean and Ben suggested to ask the Forum for permission rather than gain it from those in the room.

One other alternative way forward was suggested. To morph the group and add other items such as CT to the groups remit thereby renaming the group. This was not agreed as noted by Gerv that new shiny technology would be of interest to all with a high uptake. Ben also strengthened this by suggesting that Adam had already agreed that CT was not revocation.

The EV working group has made good progress on QIIS and Dean remarked that a suggested update will be circulated within a few weeks. Jeremy clarified that telephone has not yet been addressed due to complications with the verification process from mobile/Skype that are not verifiable.

Another area to work on is refining the language around the roles for Requester, Applicant, Signer etc. Issuance to individuals is not covered but there needs to be work on other structures to allow for other business entities such as small businesses in Germany?

There needs to be work down to fix Insurance needs (Moudrick and Rick) expressed concern on the fact they were very western centric.

Jeremy suggested that any additional points would need a call to action and Ben specifically highlighted the advantage of a Country Specific need such as the one we adopted for Japan etc. We’d need to look at the guideline language and fix it so that Appendices per country do not offer too many differences or cause a conflict with the main body text. Examples were given by Ben hypothetically talking about corporations in one country being different to another. Dean highlighted that the use of mobiles in Africa have specific needs as do LLC’s within Germany?

Steve highlighted that the work being done by the Forum to amend the guidelines for consistency. This good work should also be reflected in work down by the browsers and their GUI representation of the EV OIDs. See his presentation here: Display-of-OIDs Screen grabs will be sent to highlight the specific issue.

The Code Signing working group has been focusing on 3 areas. 1) Improvement of Vetting, 2) provision of recommendations or rules on Key protection and 3) Communication between CAs. The 2nd point being something to hold off to V1.1 or V2.0

Report on ENISA Meeting by Ben Ben highlighted the feedback from the previous day at ENISA (The EU pays €8.7M to fund their work) https://www.enisa.europa.eu meaning that the studies they produce are not necessarily the thoughts of the commission. The actual commission’s feedback will be discussed today (25th September). Slides and note will be sent around.

Both Steve and Ben presented highlighting the CAB Forum and its place in the mindset of attendees. Ben focused on self-regulation model and how closer links to industry are important. (Later on Tom highlighted that the NIST CP policy lacked crucial points due to being too high level) Nick Pope talked and updated everyone on ETSI’s progress and the common understanding was that it all seemed to be working so don’t break the momentum. (Iñigo also presented at that meeting, but his slides were not discussed) Upon review of these minutes, Iñigo clarified that ETSI is not sure whether NIST’s framework fits into the ETSI approach (RFC 3647 conversion will cause significant delays).

Article 15.1 of the proposed regulations on Trust Service Providers highlights the needs for Risk Analysis and improvements on detection. One of the key problems highlighted in the ENISA session was the problem of regulation of the TSP and how TSPs may move to regions where regulation is ‘easier’. There’s a definite need to sort out a level playing field for all. How this maps on to TSPs outside of Europe and what a ‘Qualified Website’ certificate actually is should hopefully be sorted soon. Another key item was the use of the word ‘trust’ in that specifically the academic community highlighted how relying parties are effectively being duped with the work trust when in fact it’s more the authentication of a claim.

Gerv asked if the work was all due to the fall out of the Diginotar attack and the answer was yes. Arno highlighted again that the commission’s actual feedback would be given today (25th). So Steve/Ben/Arno or Moudrick will look to update the group with links from yesterday.

Ben highlighted that the studies done by ENISA cover 56 Qualified TSPs and therefore conclusions are not yet regulation by may provide inaccurate guidance to the commission. Ben highlighted the 5 stages he covered in his presentation: Agenda-setting where you talk about important areas to cover; Problem Identification or also known as Rule making; Decision-making – choosing what’s best for industry and regulators; Implementation – Education is very important - It’s important that the word gets out; and Assessment – Auditing and Enforcement. Ben gave an example of how 1024-bit certificates could be eliminated over time during the implementation and assessment phases by setting milestones to achieve 50% reduction in the total quantity, etc.

Dean mentioned the outreach program by Gerard Galler taking place in Jordon on November 12th. (It is an exploratory seminar on e-signatures for e-business transactions in the Southern Mediterranean region.) Robin would check to see if he would attend. Dean forwarded the mail to the group.

**Open discussion lead by Gerv on Browser developments, NSA/GCHQ, advances, TLS 1.2 adoption, key lengths, SHA2 transition, including mobile (Atsushi) **Gerv led the discussion on browser developments, TLS 1.2, key sizes, etc. Gerv mentioned that TLS 1.2 is planned for Firefox 27 in January 2014. Gerv also highlighted the history of the chain building engine from the legacy code, through LibPKIX which was more of a Java to C++ hack with 17 layers and finally the new proposed Insanity::PKIX library which will be ready in 3 weeks’ time. How this moves forward and whether it makes it to FF 27 is to be seen. Rick asked whether it was planned for incorporation into NSS. Gerv answered that there was some controversy due to certain risks inherent with incorporation into NSS (asked by Rick as to whether it was planned) however the big advantage in the future is consistency for OpenSSL, nginx etc. Therefore for now it will only be put into Firefox and therefore Mozilla is very interested in testing and took an action to let people know where the relevant information is located. Rick asked whether it covered EKUs, Revocation, etc. Gerv said he was fairly sure for FF to support stapling but again the information link will clarify.

4K Initial TCP Connection Window Gerv highlighted that Brian Smith is interested in working with CAs on a best practices document on how to fit everything into 4KB for optimum performance of OCSP stapling with the initial window of the TCP connection. He has requested that CAs look at supporting smaller certificate as part of the chain response (to avoid the need for an additional TCP round trip). Ways include not allowing the use of highly verbose OU fields which duplicate the policy statements or CPS assertions. It’s also possible that multiple SANs would also break the limit.

It was agreed that rather than placing these best practice items in guidelines, we simply make recommendations on the CAB Forum website and Ben suggested that it was a potential for a small working group to work on this. This way there’s no confusion on “have to do”, versus “good idea at the time”. (Editorial comment – ECC will change this situation with smaller key sizes changing the best practice.) The basic issue is the TCP Init congestion window which both browsers and Operating systems have effect on. Tom highlighted that someone from Microsoft should be involved. Rick highlighted that CT where embedded proofs are needed is actually the opposite, but we didn’t conclude if the CT proof as an extension affected the size. This is one for the group, so Google should also be involved and here Gerv noted the cypher limits that Chrome already have to make to keep responses small.

Sunsetting SHA1 Tom talked about the Root program specifically SHA256 and the sunsetting of SHA1. He noted that the actual program requirements around SHA1 deprecation will be published very soon. The technical requirements have not been updated since 2009 with the exception of 1024 bit RSA. Microsoft intend to take a holistic view with a number of updates including SHA1 in SSL and Code Signing as well as crypt analysis and advances in pre-image/collision attacks. Although it’s unlikely the average person could do with normal resources Microsoft wish to put forward their deadlines. This is because 98% of SSL certificates are still SHA1 with no significant move seen to SHA256,384,512 etc There are several 5 year certificates so when the attack comes which it will the industry should have taken steps already. Thus, Microsoft will be proposing, that SHA 1 issuance for SSL stops Jan 2016 and for code signing Jan 2015. Microsoft will begin blocking (on the Windows platform) SSL in Jan 2017 and Code Signing Jan 2016. Basically, for SHA1 SSL Certificates, we propose that CAs be required to stop issuing new SHA1 SSL certificates by 1/1/2016. We are also setting a deadline of 1/1/2017 when Windows will stop accepting SHA1 SSL certs issued by CAs in the Microsoft Root CA Program.

SHA1 Code Signing Certs – In scenarios where users run signed code downloaded from the Internet, the use of SHA1 (including code signature and SHA1 certificates) will not be accepted for code signed after 1/1/16. Windows will continue to accept SHA1 for code time stamped before 1/1/2016 using the Authenticode timestamp.

Ben asked about SHA1 roots to which Tom said that’s a good question and therefore needs to be clear in the mandates. Gerv highlighted that MD5 was exempt from penalty as root store logic does not rely on the hash in the certificate. Everyone agreed that 3 year SSL certificates were most likely OK, whereas 5 and beyond were not. NIST already forbids SHA1.

Attila mentioned that in Turkey the ICT communications group set rules in July 2013 where QEC (Qualified Electronic Certificates) are not allowed to be issued with SHA1 (There were no SSL rules) and by September 2014 there are to be no SHA1 rules used in any eSignature Application. Tom suggested that from a practical perspective CAs should only issue 2-year certificates with SHA1 and 3-year certificates with SHA2.

Atilla asked if there was a specific security reason or it was simply balanced opinion because the feedback from Government is that there is a need to revoke. Tom said that public details around the decisions would be released.

Richard highlighted the problems with usage of XP in China and pointed to possible problems with Server 2003.

Some suggested fully patched versions should be OK (e.g. SP3 on XP) however as support for XP stops in April 2014 it makes no sense to hold the rest of the Internet to ransom over a small number of users. Microsoft will ensure that all Windows code is SHA2 compliant. Rick asked “Windows” and Tom answered, yes, the basic platform that Microsoft supports.

Gerv asked about SHA3 and there was some small discussions with Arno highlighting that it would be formalized during the 2nd Quarter of 2014. It was concluded that SHA 224 would not be supported but that transition to SHA3 would occur when it is known to be stable. It’s possible for people to refer to http://support.microsoft.com/kb/2862966 when looking at policy around ‘weak keys.’ Tom will be putting significant effort into blogs especially Windows PKI to help highlight background and decisions taken.

Someone asked should these proposals be added to the Baseline Requirements. Gerv suggested that we should look at the longevity question now as it seems that the BR allows for 5 year certs where as in fact the real limit will be only 2-3.

Dean asked about products outside of Windows such as the ‘Visa Terminals’ where 1024 bit issues are seen. Gerv answered that the answer is the same and it should be focused on BR Web PKI. Everyone agreed we were entering a period of Crypto Agility. Ben suggested he was all for simplicity but not sweeping changes. Tom suggested that everyone should simply be smart about this.

Opera update from Sigbjørn Opera are working closely with the Google team on validity periods on the back of the shared code base. Certificates that fail to meet Baseline Requirements will most likely downgrade the session to remove the padlock. Automatic checking methods to be added which look for and implement the rules on duration April 2015 etc. There’s a general cut-off of certificates that were created before the BR date of 7 years, so 1st July 2019 will not be supported. Certificate Transparency will become live in Opera as Chromium supported it due to the shared code base. Sigbjørn highlighted that all recent versions of Opera support SHA256.

Lack of Support for SHA 256 in Japanese Mobile Devices Atsushi Inaba presented the situation for SHA256 in Japan. The changes that Microsoft are proposing will no doubt affect some number of users but as smartphone use is accelerating it’s possible we may be OK. Traditional phones as a definition from the presentation are not ones that have an App store. (Rick highlighted he was forced to upgrade to Internet GPRS 2G). Atsushi Inaba highlighted that digital TVs tend to run the access browser however it’s true that older Qualcomm/Brew devices exist.

Auditors’ Updates – WebTrust (Don) / ETSI (Arno)

Don said that the WebTrust for CAs 2.0 has stabilized and it should be used for audit reports. Previously there were compliance issues with the retroactive application for the Baseline Requirements as of July 1, 2012, which had caused some confusion. Don recommends that we keep the Network Security Requirements separate rather than include them in the Baseline Requirements for SSL audit reports. For an organization issuing EV certificates right now, for example, they have a regular WebTrust report, a WebTrust for EV report, and now a WebTrust for Baseline Requirements report. WebTrust 2.0 is stabilizing, which is what most of the Browsers will now be looking at, and if your audit is not clean because you fail the network security portion, then you might be removed from, or not be able to get into, a browser’s root program, and that might cause some concern. Kathleen expressed this concern earlier this year. He thinks it makes sense to include the Network Security Requirements as separate criteria from the Baseline Requirements, as the Network Security Requirements might be replaced as the Forum reworks the Baseline Requirements using the NIST CP (when it is made available). Don said he thought that a separate Network Security document was the approach of ETSI as well.

[However, on 7-Nov-2013 Iñigo Barreira (based on his reading of a preliminary draft of these minutes) provided clarification that the Network and Certificate System Security Requirements are in fact incorporated into the main part of ETSI 102 042 (section 7.4) and are not an appendix. He also stated that they will be incorporated into the European Norm EN 319 411. So, ETSI already requires CABF network security compliance in order to pass an ETSI audit.] Ben asked Don to clarify progress on the Network Security audit criteria and said that previously in NYC we had discussed that Network Security would go into a WebTrust Version 2.1 of the Baseline Requirements. Don said he suggests that the Network Security Requirements be additional to the Baseline Requirements because meeting the Baseline Requirements is going to be hard enough, and CAs should not be further penalized for not being able to meet the Network Security Requirements, such as access control specifications. Ben acknowledged Don’s concerns that there are areas that might have too much specificity and that it might be better to leave it as an appendix to the main WebTrust audit criteria until those areas of Don’s concern are resolved. Ben said we need to balance between putting provisions in place that move us forward quickly with better CA practices vs. methodically moving CA standards into audit criteria, and eventual adoption/implementation by browsers. So if we need to take one step back and make some minor changes to the Network Security Requirements, we should and then get them over to Don for consideration as part of our new effort to have an annual cutoff date for submitting guidelines to the auditors for translation into audit criteria and as part of the WebTrust and ETSI programs. Ben said he wasn’t sure because he might want to stress that the Network Security Requirements needed to be incorporated into the main WebTrust Audit Criteria rather than the Baseline Requirements, so he asked for more clarification from Don on his proposal will work.

Don said that the audit report provided to browsers would still provide information about compliance with the Network Security Requirements – and compliance issues would still be pointed out, but at the same time those CAs would not be penalized for failing to comply (they would still get the WebTrust seal and wouldn’t be kicked out of the WebTrust seal program and the browser root programs).

Jeremy said he liked the idea, but he was concerned that some CAs might escape an auditor’s review pursuant to the Network Security Requirements. He noted that some WebTrust and ETSI audits that are performed by auditors do not cover SSL certificates because the CAs do not issue SSL certificates, (i.e. the audits are focused on authentication certificates for individuals). He was concerned that the network security aspects of the audits would be missed by an auditor who was only looking at S/MIME and code signing certificates, even though they are also covered by the Network Security Requirements document. Don said that auditors are able to identify in the report what it covers, and so this would require just a little more definition on the front end of the engagement and at the beginning of the report to outline what the audit covers and what it does not cover. Arno said that the auditor report should set forth the policy that the CA is being audited against-that would be in the public report.

Arno asked whether the NIST requirements were being inserted into the Baseline Requirements. Ben and Dean said we’re not ready to do that yet. Dean said that since the NIST document isn’t available yet, we’d be focusing just on the Network Security document and getting those requirements incorporated into the Baseline Requirements. Arno said that before we move forward on that, someone needs to perform a delta comparison on what is missing and what needs to be filled in. Ben said it would be good to have a project plan for the RFC3647 conversion project. Jeremy said that part of the project requires that we have the NIST reference CP to review and address Don’s points about some of them being too prescriptive. The current plan is to transfer the BRs and EV Guidelines into the RFC 3647 framework and to fill in gaps left by NIST (and not necessarily accepting everything in NIST’s reference CP). [In his email of 7-Nov-2013, Iñigo also indicated that adopting NIST’s CP would be problematic and applying RFC3647 would cause serious delays to its ongoing work. ETSI has its own outline and uses RFC 3647 as an informative reference.] Ben also noted that he had received an email recently from Kirk who had asked that we discuss long-term storage of audit logs and record keeping during this meeting-that is the type of thing we might look at-based on a determination of what is appropriate.

Arno said that the NIST document was too US-government-centric, and Ben explained that it was simply a carryover from the Common Policy CP that NIST used to create the template for the reference CP-and the version of the Baseline Requirements that we come out with will be international. Dean said we needed to get back on to the agenda topic of WebTrust Audit. Don said that we need to focus on the September 30th deadline. Some changes can still be made, as long as such proposed changes are not too fundamental. Don said he needed clarification on where we have ended up on this annual wrap-up schedule between the CA/B Forum and WebTrust. Don acknowledged that there was a small window to get guideline amendments finalized during the month of October. Ben said he really wanted to get Ballot 103 passed and that in his opinion all of the other proposed changes to the Baseline Requirements and Extended Validation Guidelines could go into the next 12-month cycle.

Gerv said that if anyone has any motions they ought to get them done by the end of the week and put them into the comment-and-voting track, rather than waiting another 12 months. Don agreed. Jeremy said another ballot that we were working on was to clarify the scope of the BRs. Don said that realistically his meeting is scheduled around November 18th, so everything needs to be final by then, but he’d like everything approved by 10 of November. November 1 would be a nice date to cut off ballots.

Arno reviewed the attached slide presentation ETSI_CABFORUM_Fiedler_Ankara providing a high-level explanation of ETSI’s work in the area of Electronic Signatures over the last 10 years based on the EU Directive, noting that they have incorporated the EV Guidelines and Baseline Requirements into standards that along with about 10 other PKI standards are being converted into European Norms. (Slide 2) He discussed the supervisory scheme of Trust Service Providers and the eSignature Standards Framework, including registered eMail, long-term preservation, and its work with standards for XML and PDF documents. (Slide 3) He said a more recent focus has been on qualified auditors (Slide 4), including rules processes and audit letter contents. He also said that TS 102 042 will be split into multiple parts (Slide 4), and that ETSI is interested in coordinating with browsers on root stores and the use of trust lists. Ben said that the issue about browsers incorporating trust lists came up during the ENISA meeting and that the response was that browsers must be able to control trust, but some EU officials wondered whether there could be a way to incorporate the EU TLs. Arno explained that in Europe there is a single authority for determining what is qualified, through the European Commission, and linked to (guaranteed by) the national governments that supervise issuance. Moudrick said that there was an API for the TSL that he could point people to. Tom said that the CAs he sees populating the TSLs are not typically involved in issuing SSL certificates, but Adobe is going full speed in incorporating the TSL into Reader. Gerv suggested that Adobe must intend to query the TSLs on a regular basis for key material of TSPs, as if they were outsourcing their root program to the European Union. One question was whether the TSLs could be used outside of Europe–Japan, Far East, North America, etc. Atilla asked whether regulation TS 119 612 would be the same for other countries? (Slide 5) Arno said the technical requirements would be international, but that accreditation would be another topic of discussion. Atilla asked whether TS 102 231 would be applicable to all CAs issuing SSL certificates all over the world. Arno said that it is just a technical standard that should be reviewed. Atilla asked about how a company would show compliance. Arno said he couldn’t get into the legal interpretation details. Arno said that auditors must demonstrate that they understand the ETSI requirements. (Slide 6) He pointed out that the National Accreditation Body is linked to the European co-operation for Accreditation (EA) under the new framework. Thus, for CA/TSP compliance, you have the Assessment Criteria, the Qualified Auditors, the National Accreditation Body, and the EA. (Slide 7) Document organization for the European Norm consists of separate documents that map to the ETSI TS documents and the CA/Browser Forum Guidelines. (Slide 8) In conclusion, progress is being made with policy requirements, such as audit practices, other countries including Arabic ones are showing increased interest, and it is a very complex scheme. (Slide 9) Slide 10 has been provided by Iñigo. It shows that the documents are ready for review. The documents are available for download. We are awaiting to see the final version of the law, which will include information about “qualified web site certificates”. ETSI is also collecting survey information about auditing. Ben said we should also think about pre-qualification of auditors, so that we know whether an auditor’s audit will be accepted (e.g. by providing a list of your auditor’s qualifications to your regulator). There were follow up questions about the “qualified web site certificates” and the general response was that we have to wait and see what the European Commission does.

Discussion about Coordinating Guidelines Implementation, Compliance Audits, and Browser Program Expectations (Steve Roylance) Talking to his slide attached here as Talking point on time lines (corrected).

Open questions: There are these factors driving the construction of a CPS:

1. Main business procedures
2. BRs
3. Audit Requirements
4. Root program requirements

There is a chicken and egg problem – what drives what?

The blue period is a 12 month cycle, red is the 3 month audit period. The CPS may change over time. The audit guidelines change over time.

Are audit guidelines driven by root guidelines? Surely it is what is in force at the blue/red boundary that matters (CPS & audit guidelines). So BRs were not in effect until (when!?)

The CPS may include factors not mentioned in audit guidelines.

Ben said that if you adequately disclose your practices and they are auditable then the WebTrust auditor will audit that you do what you say, and Don agreed. Don added that it would be nice to have WebTrust in place, but they would look at CPS anyway. If there are certain things that have been through the root program (i.e. are requirements) through WebTrust or ETSI, and they haven’t yet been put in the CPS then that omission would be an audit issue.

Steve said that you can’t, in the (3 month) audit period, adopt any audit criteria “post hoc”. E.g. SHA-256 – if we add this into the CPS today, when is it actually auditable?

Gerv said (while producing this diagram on a flip-chart Gerv’s flip-chartogram.jpg) that CAs and browsers both provide input to the root program. The CABF produces BRs which may provide some input but not definition into the CPSs. Root program may make unilateral mandates. CAs may choose to incorporate BRs. The CPS forms part of the audit criteria, as do some version of BRs. Some CAs may be audited today against a criteria because the CAs may have chosen to adopt prior to root program adoption.

Ben raised two questions. 1 – if something is urgent enough then the browsers will say they just want it – and won’t wait. 2 – what is the normal case for adoption (incorporating the voluntary track). One is a CA choice, one is a browser choice. When do the browsers expect compliance by one route, when via the other?

Gerv answered that dates may appear direct from browsers or may be imposed through (eg) BRs.

Considering the Network Security Guidelines, if the CABF says ‘CABF members are expected to comply by X’ – how does that date fit?

Dean said that the CABF has said that this is required of all by X date. Please Mr. Auditor, audit back to X date when you are able.

Don replied that the critical date is set by the main user of the report – and that’s the browser. When they see its mandatory people generally pay attention to it. They have not said the same to the Network Security guidelines, yet. E.g. July 1st (BR) some CAs said they were not compliant at that date – impact – zero. Frankly, until the browsers indicate that they will want it…

Gerv said that it sounded as though we (browsers) get to set audit criteria? – That doesn’t sound right. Don replied that we take content from the document, but take effective date from browser. Gerv said that they haven’t set dates for Network Security guidelines because they assumed the date comes from elsewhere.

Ben said that Governments (and other CABF non-member CAs) may adopt Network Security requirements in response to Diginotar and expect audits to follow.

Don mentioned that the issue was Timeframe – for a few meetings there was general agreement that the audit community would take the guidelines as they existed at (eg.) Sep 1st and 9 months later would take them as effective audit criteria. Gerv started to say ‘Presumably once you publish the document, …’ Dean said this is the right question – Are you saying that the date comes from the auditor – or comes from the browser? He went on to ask Don – Are you waiting for guidance from CABF or from Browsers? Don replied by asking about significant CAs who are not members of the CABF, are they to jump as soon as CABF signs an effective date – or is the main use of their report for the browser community?

Dean said that browsers and CAs agreed the guidelines with the intent that the guidelines become required when incorporated by browsers. Don pointed out that you can have a version of WebTrust for CABF members so that a certain number of months after passing something (>= 9 months) it becomes effective criteria. Also a WebTrust for non-CABF (for public SSL) which will be influenced by the browser policy requirement dates. Also a WebTrust for non-public CAs.

Gerv asked if the fact that the browsers voted for the guidelines in the forum sufficient? Robin asked if Don or Gerv intended the CABF to *require* some action of the Browsers? Don said yes, that would be one way. Gerv said that browsers see it is a request to incorporate the guidelines in their policy. Ben asked – What if it was a unanimous vote of the browsers in the CABF? Would they incorporate? E.g. 1024 bit – if it was passed unanimously by the browsers then surely there could be no debate about when it was requested. Gerv said that the Browsers can make unilateral requirements (refer to Gerv’s flip-chartogram.jpg) and that he didn’t feel like they directly required audit criteria. If we put requirements above and beyond public criteria, we may get upset if we find it, but we can’t drive requirements into criteria.

Don said that he had issued special reports for Microsoft (and passed the same to Mozilla). Gerv acknowledged that Mozilla could do (request) the same.

Tom said that landscape keeps changing. 1024 is past. We have certificate reputation scans, and Alexa 1,000 (or 1,000,000) scans to detect it. We consider it a certificate hygiene issue. We don’t have to wait for it to come into audit criteria.

Gerv said OK, so there are some criteria best enforced by technical means instead of audit.

Ben suggested that when we adopt things we perhaps start to identify it as something to go via audit criteria, or that we expect it to be implemented by CAs prior to the audit criteria existing.

Tom pointed out that the BRs have to be auditable.

Dean asked why we put effective dates in the documents as they seem to be meaningless. CAs that are not members still have to implement BRs, surely (because they are subject to the policy of Mozilla who require a BR audit). Giving a stamp of approval to the Network Security guidelines how do we push the date?

Gerv suggested that if the CABF comes up with agreed requirements which incorporate a date, Mozilla might set the same date expectation even though the ability to check may not immediately exist because of lack of audit criteria.

Don asked about the 9 month period which had previously been discussed as intervening before incorporation of new standards into audit criteria? Gerv said that was for audit, and implementation may come sooner.

Ben suggested another option, like an interim step, because no-one wants a finding of non-compliance, that we be required to self audit or self assess or some other sort of compliance documentation. It brings the problem back to a level playing field, maybe.

Steve said that he’d love to have audit guidelines set to a specific time. Consider the recent bad press from NetCraft re dates and BR compliance.. He would prefer dates in audit criteria.

Gerv said that he didn’t think that does away with requirements for earlier implementation. Don asked if it was expected that all external CAs (non CABF) would incorporate the requirements? Gerv pointed out that the requirements that matter are called browser root program requirements.

Tom said that he lives off the audit deadline. Gerv said that in that case Mozilla and MS have different approaches – which is also fine. Mozilla trust and verify when we can, whereas Tom Wants everything via audit. Mozilla’s date would by default be the same as the CABF sets. MS will be when audit criteria are effective and audit completed.

Ben offered a concrete use case. Code-signing. More Microsoft than Mozilla. It would help if we can work on writing in descriptive text what our expectations are. Gerv suggested that if the CABF wants to follow the CABF model, make the effective date based on Don’s timescale – so Sep 1 + 9 months. If you set an earlier date then Mozilla will (probably) support it.

Dean asked about the Network Security guidelines. The requirements are out there. At what date will they be audited from, and when will they go back to? Feedback received, some adjustments will go back to WebTrust. What happens then? Don said that if we (CABF) were sure we’re ready for it, WebTrust are meeting mid-November and this is only one criteria. If you get it back to WebTrust by then they could implement it immediately. It wasn’t a major training issue.

Dean asked a question of the browsers: – of the CAs that are members of your programs and who are not members of the CABF, (probably there are numerically more outside the CABF than within), how well have they been versed on the security requirements including the forthcoming amendments and adjustments? Don interjected to ask if he was going to issue a WebTrust Network Security Guidelines for CABF members for public CAs? – Dean and Gerv both said no. Gerv said that if Tom is interested in them being audited upon then that makes a difference? Tom said that he was positively interested in the Network guidelines and their continuous updates. Tom will wait for them to be audited. ETSI are well along the way. As soon as they are in WebTrust, Tom will require it. As long as Network Security Guidelines is in a WT audit (2.1) then it will be incorporated.

Dean said that in that case we need to get it into an audit ASAP.

Tom added that according to Munich date discussion – now is the time to freeze it (September) to get it into WebTrust. “best efforts”.

Steve asked Don – when you incorporate a new guideline, how far back do you go? Don said that, in terms of an auditor, it’s really not difficult because the criteria are almost binary and security related this would be a scenario where, assuming we get clarification in a few weeks, he would have the next to final draft available for the November meeting and at that point in time the Network Security Guidelines 2.1 would be in effect and could go back to the start of year audit period. A Jan 1 2013 effective date could still be applied to the first auditees.

Tom said that he didn’t like that because some external CAs are not yet aware of these criteria – so it would be effectively retroactive.

Don said that he could have 2.1 available before the end of the year and auditors alerted to the fact it is there for public SSL. He seemed to have support from the CABF to go back to 1 Jan. If the forum continues to reiterate that date then, fine, he will accept it. But an alternate date may be more reasonable and thats fine too. For other changes (e.g. to the BR this week) we will freeze at Sep 30th and issue another version effective for April 1 2014. If someone may have a split year then that’s something that auditors can cope with.

Rick said that Browsers and CAs seem to say July 1 2012 was a fiction. Was that correct? Google and Mozilla have recently said they are going to build in checks for certs issued right after that date. Many CAs were not compliant at that time. Maybe we approach Google and Mozilla and say that the date is not reasonable.

Gerv agreed that we could have a discussion over that.

NIST CP, Baseline Requirements, Network Security, etc. (Tom) Tom presented a comparison of CABF BR v. 1.1.6 with the NIST IR 7924 Draft. He said that he had created a side-by-side comparison from the perspective of the BRs. The purposes of the two documents were stated as follows:

• BR is “to enable efficient and secure communications” and “address trustworthiness of certificates”.
• IR is a “baseline set of security controls” using a reference CP (IETF RFC 3647) and uses the US Govt Federal PKI as a base document (Note Iñigo’s previous comment of concern that RFC 3647 conversion during EU/ETSI formalization processes will cause significant problems.)

He took the BRs, section-by-section, and found matching sections in the NIST IR (if any) and mapped them against each other. He noted that the NIST IR has a lot of things in it which are not in the BRs; that info is not captured in the BRs. The final draft of NIST IR due out hopefully in Nov 2013. Generally, NIST is much more into ‘guidance’ rather than ‘requirements’. (See Tom’s slide deck for comparison of BR and IR strengths and weaknesses- BR+IR COMPARISON) The CABF’s BRs lead in some areas, but they lag behind in other areas. Tom recommends:

• reworking the BRs into the RFC 3647 framework.
• taking some of the NIST guidance on network security

RFC 3647 migration: Gerv recommends a 4-stage strategy:

1. Rearrange document sections, with a map so everyone can check all the same text is still there
2. Search-and-replace changes of terminology
3. Actual editorial changes to make the document make sense again
4. Incorporation of any useful NIST text
5. and 2) are designed to be easy to review, and to make 3) much easier to review because it doesn’t contain distracting mass changes.

Jeremy noted that we should do it for both the EV Guidelines and the BRs at the same time. This is an issue because we want to make changes for EV coming out of the EV Working Group. It was agreed that we could word motions such that the new text was inserted into the current BRs but was also mandated to be inserted into the transformed version. It may be that the NIST text belongs in the Network Security document rather than the BRs; that’s TBD. But it’s still worth rearranging in RFC 3647 format. Updates from ICANN (Francisco) and Collaboration with Other Groups (Ben) Francisco presented his update on the contracted new gTLDs– see ICANN-update-CAB-Forum

1. 47 Registry agreements were signed as of 24 Sep 2013 (12 IDNs, 35 ASCII)
2. ICANN created a mechanism to get new announcements, and a link to a site hosting registry agreements

He discussed the name collision risk management proposal

1. 80% of the proposed new TLDs are low risk, and are proceeding to delegation
2. 20% of the proposed new TLDs are considered ‘uncalculated risk’, and require further analysis
3. 2 are high risk, .corp and .home, and will not be delegated at this time

Gerv asked if anyone who commented to ICANN was in favor of delegating .corp and .home? Francisco said only the registrants were in favor.

ICANN had asked for feedback on these applications

1. As of 17 September, 75 public comments were received
2. ICANN Board NGPC will consider the issue at the upcoming board meeting on 28 Sep 2013

He discussed low risk strings:

1. Registrants will not activate names in DNS for the first 120 days from when the agreement is signed
2. The registry may register names immediately, but may not activate them for 30 days
3. It was proposed that CAs notify DNS requesters of TLD delegation of upcoming activations
4. Rick asked if names registered in the first 30 days will be available via whois. Francisco said yes, they would. CAs could use that to verify that someone with an existing certificate had acquired the right to the subdomain name in their certificate.

Here are some highlights from public commentary:

1. Someone proposed decreasing the 120-day period for revocation of internal name certs
2. Someone suggested revoking certs for all likely new gTLDs as soon as possible without waiting for contract signing, or at least stop issuing certificates for these likely new gTLDs
3. Someone suggested obtaining the list of 2nd-level names related to a new gTLD upon termination of the period where CAs can issue certs for that gTLD (30 days after contract signing). That list could be used by the new gTLD registry to reserve the 2nd-level names involved until the related certs expire or are revoked, closing the door to attacks using the internal name cert vulnerability

The upcoming ICANN meeting will be in Buenos Aires, Argentina 17-21 November 2013. Information is at http://buenosaires48.icann.org

Francisco was asked if there are any specific requests from ICANN for the CAB Forum at this time. Francisco said no. We’ll send out his slides to the list.

Jeremy proposed adopting the suggestion of stopping issuance of pending 80% gTLDs right now. But we recognized that it would be at least a month before it’s passed, and could not wait to get into an audit regime. He’ll do it via the list.

CABF Information Sharing (Ben) Ben stressed the importance of evolving the information sharing infrastructure of the CA/Browser Forum toward better information sharing capabilities and practices.

Sept. 26, Thursday

Malware-Scanning/ Code Signing portal Demo and discuss sec.16 of EV Code Signing Richard introduced and showed the demo of Code Signing portal. (Slides are attached here: WoSign_Proposal. The idea is to take away the private key control from the customer’s hand and scan for malware before signing it. Richard also introduced a misuse blacklist system. When the customer’s certificate is revoked for signing malware, the CA reports the context of the revocation and adds information to the blacklist. The blacklist is also synced with Qihoo 360 Technology Co. Ltd’s malware information. The CA would share information about not selling the Code Signing Certificate to a customer who has signed malware before.

Gerv asked the logic of the judgment of the antivirus providers when “good or unknown” (doesn’t it require additional manual verification?) Rick commented on the concern on the coverage of the Qihoo 360 Technology Co. Ltd as it may not have comprehensive malware coverage from Europe and the US market. Ben highlighted that it may not be the comprehensive risk mitigation tool (as sandboxing would be, for example), but it is definitely good tool for additional control. Tom was concerned about whether the blacklist would be sufficiently dynamic, as there could be the case when a Code Signing private key is compromised and malware is signed using the customer’s signature, which results in a false positive blacklisting the customer. This would harm the ability of a good actor to obtain code signing. We need to be careful in handling these “gray” lists. This topic will continue to be discussed in the Code Signing WG as this was simply a demonstration of the technology and not suggesting the group adopt or use exclusively.

Improving the Meaning of the Green Bar (Sigbjorn) Sigbjorn said that EV usage must adhere to higher standards: for example, TLS rather than SSL 3. He said that this effort cannot be done with regular SSL certs, because too many would break, but that downgrading EV SSL is one way to push improvements. Steve: Only problem is the customers who need to do this are CA customers. He wondered whether there could be a way to show in debug mode that the browsers are degrading EV so they know who is doing it and so they don’t call CAs for support. Ben: There are remedial measures. Let’s choose one thing to screen on and show the downgrade options. Gerv: I think this is agreeable to do. The risk is this reduces the use of EV. Tom: There are things we expect CAs to screen for which is OCSP, no MD5, and 2048 or greater. Then things we can scan for and block like keys less than 2048. But there is a third category of things with debatable value, like CT or no EV display. We shouldn’t settle on the third category without a lot of thought and deliberation. Rick: One of the fallacies of EV is for frequently visited sites, that you remember you had the green bar and now it is missing, so something is wrong. Jeremy: We should use the not before date to safeguard EV for previously issued certs. We cannot do this to existing EV subscribers. And there are massive support headaches halfway after using the cert when the customer doesn’t get their EV treatment that they paid for – you have support costs for remedying their site (removing SSL3 etc). Sig: Ballot might resemble “TLS 1 is required for EV to show the green bar”. Robin A.: CAs are capable of setting up tools to evaluate customer sites to see if they are meeting the bar (ex. not SSL3) [There was a general discussion of the dynamics of client and server negotiated sessions. An EV site can do TLS, but has a lot of connecting clients that don’t support more than SSL3 (ex. in China) – EV enforces failed EV negotiation. Sig: Implementation date? Jeremy: There is still the 27-month issue of valid existing EV certificates and customer support. But also terms of service complications – we need some time to decide how to implement it. We have to wait a full 27 months. Ben: It sound like there might be a need to negotiate between 0 and 27 months before implementing this. Sig: I’ll send out the ballot with the date undetermined, and we’ll reach out to EV CAs for input on the deadline for getting this done.

Recommendations for Processing EV Certificates (Rick) Rick said all of the information can be found on the Wikipage for Ballot 89.

• Ballot 89: Adopt Guidelines for the Processing of EV SSL Certificates
  • Related issues in this document are combined in a table as “Meta Issues”
  • Ben made some suggestions in August 2013.
  • Latest version of the document will be available one week after the forum.
  • After a 1-2 week voting period, the document will (probably) be approved by the end of the year.
  • Steve mentioned that browsers can put a proper (Jurisdiction)name for CAs which Steve answered that will be updated in the current document.
  • There are some localization problems:
• Current EV Processing document is from 2006 and has removed from the web site.
• Each CA is allowed to use its own EV-OID. There is a section for EV-OID: Chapter 12 Certificate Policy Identification.
• Rick states that OIDs are expected for certificates, however having an OID is not the only reason for a certificate to be accepted.
• A CA may have two OIDs, however, Moudrick stated it is good to rely on ETSI.
• As a solution Wosign recommends publishing of CAB Forum OIDs on CAB Forum website.

Audits and Timelines. Dealing with audit and reporting on Network Security Guidelines in WebTrust 2.1.

Given the NIST interest and the ultimate incorporation of the NIST guidelines into WebTrust, to keep WebTrust straight, Don suggests that reporting on the Network Security Guidelines is incorporated as a criteria into WebTrust for BRs. Most browsers will look at the WebTrust report and if not perfectly clean the CA may not end up in root program. For Baseline Requirements, right now, the first reports may not be clean and browsers may cope OK. It makes more logical sense to include the Network Security Guidelines as a separate criteria into the baseline. Don believes this is consistent with ETSI approach. (In response to circulation of the draft minutes of the meeting, Iñigo stated that ETSI disagrees with having a separate audit of the Network Security requirements and the BRs, in fact, in the current version of the ETSI TS 102 042, the Network Security requirements are included, and will be in the European Standards, ENs. So, to get the certification a TSP will have to “pass” everything. ETSI has included Network Security into the main document and not as an annex or appendix.” Believes it would be less exposure for an organization if they have some of the issues discussed yesterday. It will be up to the organizations how to treat a qualified BR report. WebTrust is looking at creating a WebTrust BR Seal.

Ben said that, previously, we’ve talked about WebTrust 2.2. He feels it’s important that we make some forward movement. The other side of him says there may be some small problems. Do we have to be on a fast track ahead to audit, or take a slightly slower route, get changes on Network Security Guidelines to Don over the next month, but as to where those get integrated into the audit framework not be too fussy. Ben admitted to being in two minds as to whether he wants it or not!

Jeremy said that it would then no longer apply to SMIME and code-signing certificates. Don said that we could clarify the nature of the certificates to be reported upon.

Arno said that it was his understanding that the auditors report fulfills the policy. EV – there is nothing more in the public report. He asked if we wanted to put additional NIST requirements into the Baseline Requirements. Ben replied that we’re not there yet, but are still evaluating.

Jeremy said that before we put the Network Security Guidelines into Baseline Requirements, we should take a look at the NIST output. Ben suggested that we should transfer what we have into a RFC3647 format policy with blanks, then we have spaces to fill in with what NIST suggest. NIST isn’t right 1st time and won’t be right 2 time but it will be better – and there may be things there they didn’t catch. Ben mentioned that Kirk had emailed asking about how long audit standard says you keep records for.

Arno said that if we take additional requirements from NIST we should bear in mind we will also be having discussions about Japanese, ENISA, South African (etc, etc) requirements. Ben said that NIST are aware that the NIST CP is NIST-facing.

Don asked for a final clarification on timing. Are we still dealing with Sept 30th + 9 months (+ certain other methods for urgent short-timescale requirements)? Ben said that he thought this timeframe is a good one. Is there a desire that we make minor changes to any of these docs before we pass them to WebTrust? Don mentioned that there are still some changes being made in this 2013 cycle and that the next meeting was not until mid-November and that he could stretch this September to mid October for the hand-over. Gerv enquired if we would use the same cycle for Baseline Requirements and EV and Don said that he thought that would be the ideal.

Gerv asked if Jeremy’s pending changes would make WebTrust in this cycle or the next one. Ben said that Ballot 103, OCSP, needs a one word change to go forward and we shouldn’t be fussy for other changes this cycle. Gerv recommended that we proceed with all reasonable haste to ballot 103 with the hope that we’d cutoff changes for this year after ballot 103.

Jeremy mentioned another pending change was the clarification of scope of Baseline Requirements – for which there was to be a discussion later today. Don said that he had a meeting schedule for November 18th and that if he had the completed ballots in good time for that meeting, say 10th November, that he can deal with them.then can deal. Let’s get everything approved by 10th November. Ben suggested we push for November 1st, which was broadly agreed.

Standardizing SSL, Code Signing, and intermediate CA certificate profiles, browser processing behaviors (Rick) / Innovation in CA-Browser Practices (Ben) It was agreed that consistency in certificate profiles and certificate processing is necessary. Review Interested Party and Observer Status, mailing lists, wiki access, and Invited-Guest during F2F Policy, IPR Policy (Dean/Ben)

The group discussed and recommended the following clarifications to membership categories in the CABF bylaws: Associate Members (formerly known as Observers); special parties such as ETSI, WebTrust, Paypal, ICANN, which need to sign the IPR and can attend meetings but cannot vote. Invitation from Forum required. Added to Management list and granted wiki access; Invited Guests- per the chair’s discretion, invited to local meetings as guest speakers or attendees. No IPR policy required. No mailing list or wiki access; Interested Parties- Those that want to participate on working groups only. Must sign IPR agreement. Added to working group mailing list only. Review CABF Web Site (Ben) The group walked through the menu options for the web site and made various changes.

Planning for Upcoming Face-to-face Meetings (Ben & Dean)

2014 Feb 18-20: Near San Francisco to coincide with RSA Conference. Possible host: Google June: Israel hosted by Startcom Fall: China hosted by WoSign**

2015 Feb: Microsoft July: Zurich hosted by SwissSign Fall: Istanbul hosted by E-Tugra