[cabfpub] Notes of Face-to-Face Meeting in Munich - June 2013

[Ben Wilson]

These are the consolidated minutes of the Munich Face-to-Face meeting held June 11-12, 2013.  Differences in writing/formatting styles are attributable to the fact that the minutes were transcribed by different persons. 

Opening: Dean Coclin welcomed everyone to Symantec’s offices and reviewed the logistics. Ben Wilson read the antitrust statement. 

Updates from Browsers and Other News 

Representatives from Opera, Mozilla, and Microsoft were present. 

Dean: Oracle is interested in joining the CABF as a root store (Java root store). Also, a CA from Germany, Atos, contacted him with a view to join. 

Gerv (Mozilla): Mozilla is internally (and will soon externally be) formulating a more explicit policy on revocation. Plans are still being developed, but the current concept is that Mozilla will encourage sites to use OCSP stapling with their end entity certificates, and Mozilla will implement a CRL-set-like mechanism for roots, intermediates, and other certificates. That means they don't have to wait for multi-stapling to become a standard and to be implemented, and sites that want it (with a must-staple certificate extension, or http header) can get hard-fail. This gives per-site opt-in. Some sites are keen for hard-fail, others not so much. In response to a request from Rick about the level of granularity, Gerv said that CAs may insert must-staple in all, or some, or no certificates, and that the use of an HTTPS header would also provide a per-server option. Mozilla will invite wider comment when there is rough consensus within Mozilla. 

Sigbjorn (Opera): Opera has recently switched to Chromium Blink engine for rendering. This includes a few changes to how they deal with the root store. Opera now uses the native trust store of the OS. There have also been a few changes to revocation behaviour. Sigi is not sure how that pans out in the long term, but they are now more similar to Chrome than they have been before. Opera will still have their own version of the root store for mobile devices and a delta store to add and subtract roots from desktop operating systems. 

In response to a question about the caching behaviour of revocation information, Gerv said that for their "CRLsets" there will be a daily download. Although Google crawl a bunch of existing CRLs, and that works well for end entity certificates, Mozilla may want more direct CA involvement. For stapling the caching behaviour is not so relevant. 

Sigbjorn: Opera caches by default for a week or so. Not sure how it will end up. It may well change! 

Gerv: If stapling were the only deployed use of OCSP it would reduce the latency problem and uptime requirement of live OCSP responders. We're a long way from that now - but it may be a goal. 

Sigbjorn: for Opera, failed revocation lookups will no longer downgrade the site (i.e. no longer supress the secure indicator). They may restore the behaviour in the future. They are moving to be more like Mozilla, at least temporarily. This is because of the engine switch, not a design decision. 

Tom (Microsoft): Since the release of Vista, Windows has relied on the certificate trust list for distribution of roots. They have a new revocation policy for sub-CAs and intermediate CAs. Instead of relying on CRLs, they will rely on the 'disallowed' list. Instead of relying on a CRL which may be valid for 12 months, the disallowed list can react within hours if needed. They will change the policy (in light of NISTIR 7924) so that in the event of a compromise of a sub-CA or intermediate they will expect a notification from the root within 24 hours. They will authenticate the request and then go through the mechanism to issue a new disallowed list. 

Rick: Suggested that Microsoft coordinate with other browsers and define a common CA compromise notification mechanism. Tom replied that NIST says CAs should notify, but don't say how! It would be nice if the CABF came up with a mechanism. Gerv said that Mozilla would be interested in getting these notifications in a structured form, too. There should be a central clearing house, maybe. It would be good to have a single mechanism which mustn't be spoofable. Rick noted that Symantec often will have to revoke an intermediate CA when an affiliate is no longer doing business. He is concerned that these occasional not appear in a CTL (or some other mechanism) where some people might misconstrue that (e.g.) 5 sub-CAs were revoked so there must be some sort of disaster, which could lead to a PR nightmare. The CRLs and OCSP in use today allow revocation without fanfair. Gerv: pointed out that the revocation reason field might be utilized. Rick: expressed his concern still that with a new mechanism some may errroneously infer that something is wrong. 

Tom: no matter what the CABF comes up with, Windows is looking to September 2013 for a solution. He would be working with CAs in the short term for good authentication mechanisms & standard notification methods. He said revoking sub CAs won't happen every day, but he wants to start setting up the procedure. He is looking for volunteers to try out and make suggestions for the authentication scheme. Arno said that ETSI has a similar policy. Tom said that Microsoft is reflecting the NIST draft Certificate Policy because they think it has value. 

Tom: CRL&OCSP. Instead of allowing both, Microsoft is going to start relying exclusively on OCSP. CRLs don't scale so well. They will start to abandon CRLs - before some time in 2014. On all supported Windows platforms--Vista and beyond--Windows 8 phone, included. Rick asked that the Fforum be pointed to a knowledgebase article, when one is available. Tom said that there would be one. Microsoft knows that it is a big issue and will document it well. 

ICANN -- New gTLDs and Request for Internal Name Usage Data 

Tomofumi (ICANN): ICANN has engaged contractors to study the prevalence of use of internal domain names to be complete in time ahead of the Dhurban meeting (e.g. 3/4 July). Francisco has requested data so they can include it in the study. Tomofumi is here to answer questions. Jeremy said that use of internal names with SSL is a more immediate problem than SMIME. They want a summary or list of each internal name with a tally by expiration year. They are just asking for aggregate info. It was noted that only asking CABF restricts notice to CABF members (e.g. would miss Entrust). Ben: Will circulate the list offline. He spoke with Francisco and he will try to send it out individually to get a better response. Gerv and Kathleen have been emailed with the suggestion it may be possible to email all members of the root programs. Jeremy: The message needs to get out to all CAs. 

Tomufumi: The reason we approached the CABF is because our study deadline is pretty tight. We want to make a difference, so we must hit the next ICANN meeting (15-17 July) so deadline for delivery of information is end of June. Other thing is that the initial spreadsheet asked for too much detail and it makes CAs uncomfortable. Current state of spreadsheet is TLDs and numbers. 

Rick: Initial internal name spread-sheet request from ICANN had made him uncomfortable. Jeremy: Advantage of removing SMIME certs is that they will tend pollute the data. Either do SSL only, or give SMIME and SSL and indicate which is which. Gerv: the advantage of obtaining untrusted stuff from CAs is that it gives you hints about how much non-routable TLDs are used generally, and it is unwise for ICANN to cause a lot of people a lot of stress! Jeremy: ICANN wanted a 2 factor approach 1) Try to get CAs off internal names before the switch 2) try to get server operators to switch away from internal names They care about both. Time is tight! Rick: SSL should be prioritized over SMIME. Robin: They'd like everything, but they *need* SSL. Jeremy: Let's suggest that the request be amended to just SSL and resent. 

Other News 

Jeremy: There was an email about an ISO call for contribution from Scott Perry. Sounds like there is an overlap with efforts to address the Web PKI with NIST, ITU, IETF, etc. Should CABF respond to ISO telling them what we have and what we've done and put them in touch with NIST? Is that something we can do as a Forum? Dean: We could propose that on the management list, but yes, he agrees that something should be said. Iñigo: Email came from a joint ISO/ETSI meeting. ISO is trying to create a new set of standards for PKI & deployment, but ISO is wider than ETSI, but asking the whole world what to do regarding the development. 

Iñigo: ETSI is internally discussing and working with ISO, trying to apply 27001 controls in ETSI standards. Jeremy: Are ISO going to do this no matter what? Iñigo: The idea is to see what ISO does and what ETSI does so they work together. Arno: It's a different process of dealing with a PKI management system. Different audit concepts. Tom: The only ISO standard that seems to touch ETSI and Webtrust was ISO21188 (auditing scheme), but it hasn’t been touched since 2007, and it is a bit unloved. Arno: There is Sub-committee 38 for cloud systems. Mert: There are new EN standards, too. Iñigo: We have a presentation later this morning on ETSI 102042 and how that will be changing that way. Ben: That's what this whole morning session is about. Webtrust, then ETSI, then more of this discussion. Jeremy: Is everyone OK with us sending some sort of response - should I draft one? Ben: We need to be careful. Not objecting, but this is a pattern in the information security industry as a whole--that we write things down in different groups and say the same thing in varying degrees of specificity, but we here are the primary group that is most concerned about the outcome. The letter should say we are the ones who are concerned with this and how do we influence something else that comes out in this area so that we can ensure consistency. Dean: We should draft something and send it around. It is important to highlight the work that we in the CABF have already done. Kirk: Whatever happened to the Network Security Guidelines? Jeremy: People asked that we wait until after NIST came out with NISTIR. We actually have two different documents. The Network and Certificate System Seurity Requirements were adopted and effective January 1 and are going into the audit regimes. Don will talk about this later. Jeremy: The second part are the new draft operation guidelines, which aren't passed yet. We will continued working on them. 

WebTrust for CAs 

Don: A few highlights on WebTrust recent past: Some movement on the taskforce. Mark Lundin is no longer on the WebTrust task force, but he is still an advisor. Reema Anand of KPMG has taken his seat. Mike Green (EY) has been too busy, so David Roque out of EY's SF office is taking his place. Next meeting planned for 3rd week of July. Brian Walker is still working on WebTrust operations. WT for CAs 2.1 (which includes the security requirements) has been drafted and should be finalized in July. It has been hard to incorporate the network security requirements into the existing 3 sets of criteria because of the difference in level of detail. For non-publicly issuing CAs, they aren't convinced of the need for it. Having as a separate group allows them the flexibility to bring it into those audits if required. Dean: So version 2.1 includes the Network Security Requirements? Don: Yes, it has been drafted and it is going through the assessment stage. Dean: When will the 1st CA be audited in accordance with WT v. 2.2? Don: The next audit after July and fall onwards. Kirk: Has it been circulated yet? Don: No, not yet. 

Ben: On the seal for Baseline Requirements, I don't think we need another seal because we only have room for one. Don: I hear the opposite. Don: The initial BR reports--over the last few months--were point-in-time reports. I'm not into seal design! But if we've got one, then I'm happy. In the same way today that Symantec, Entrust, do it, EV and standard back to back on the secure site, may expect to see the BR seal there, too, even though there's only so much real estate on a page. 

Don: WebTrust for RAs has not proceeded so fast. We'll discuss it the third week of July in SF. Also, Kirk circulated something a while ago on the use of the word ‘errata’ in each ballot to amend CABF and Don agrees that it shouldn't be used. These are usually not errata but are amendments. 

Kirk: On auditing of the BRs, I felt there was a lot of confusion. WT for BRs was finished. CABF didn't pick an effective date. Don: Kathleen picked a date at MountainView. Kirk: Could you tell us when version 2.1 is finished so CABF can adopt a ballot to encourage the browsers to adopt it as of a given date? So if WT tells the Forum when it is ready, or better when it will be ready so we can work towards that? Don; We're never going to tell you when to implement. In the same way we don't set the technical standards (you do) we don't set the timescale (you do). Jeremy: We talked about having a freeze date in September and adopt into audit criteria early the next year. Ben: Do we need to write down what the steps should be. I think we had a rough outline of the steps. Jeremy: Thought we were waiting for dates from ETSI? Don had said that if we checked in everything by August, then WT could adopt by January, ETSI weren't sure they could meet the dates, but still waiting for ETSI response. 

Don: Give us the standards and we'll audit to them. Kirk: I thought the network security controls are a major new requirement and should have their own timing. Don: Sure. Kirk: but for smaller revisions would like an agreed release timescale. 

ETSI Presentation Iñigo (ETSI): ETSI documents don’t talk about CAs, they talk about TSPs (Trust Service Providers), although they're equivalent. The new regulation isn't just about certs, but also about signatures and formats, policies, additional services like timestamping, requirements, etc. in a legal framework. Iñigo will discuss more specifics, including news from meeting in Poland, but first Arno will present. 

Arno's presentation: Europe made the first law on electronic signatures in 1999; in 2010 they realized that it wasn’t the right approach. They had lots of regulations but no legal framework, so 12 months ago, the EU parliament made new regulations about trust services in Europe. They hope it will come into force in 1.5 years. 

Overview of Mandate 460 standardization of e-signatures. In Germany, they have another approach for certificate validation checking compared to other countries (was the certificate valid when it was signed). But now we have signature validation policies that we can put into XML machine-readable form. We have standards and procedures for signature generation and validation. 

Signatures cover XML, CMS, PDF, mobile. The document includes timestamps, creating and validation of signatures. Secure Signature Creation Devices (SSCDs)- are they smartcards, HSMs, signing services, etc.? There will be 4 official European standards next year covering them. Iñigo said HSMs are not considered secure signing devices in some countries, because of questions about the sole control over the private key. Plus there are different security levels of HSMs. NIST talks about FIPS levels, but that's not an international standard. It’s not clear if signing in the cloud meets requirements. 

Don asked if we should skip talking about signing by individuals and limit ourselves to CAs which are our focus. Ben said that we also cover code signing, which is by individuals. 

Arno said that the Common Criteria specification should be accepted as equivalent to FIPS. 

There are no more Common Workshop Agreements (CWAs) for this task; they are now European Norms (ENs). Iñigo is working on a policy for SSL certs. Ben asked if this is similar to NIST; Iñigo said no, it's better :^) 

Each EU member state is obliged to maintain a Trust Service List (sort of a white list) that contains status, which can change over time, from trusted to untrusted and back. Ben asked if there is documentation on TSLs. Arno said yes. It’s not clear how these TSLs get incorporated into software. It needs infrastructure. They may not be incorporated into browsers, but applications. For example, health care providers use them. Tom said people ask what will Windows do with TSLs? This needs to be answered at the application level, not at Windows level. Different apps might have different TSLs on the same Windows platform. Arno said you start with the policy, but then you need to have controls in place to enforce it. 

Iñigo's presentation: STF 458 comes from STF 412 (includes guidance for issuing EV certs for auditors and CSPs) + STF 438 (includes guidance for issuing TLS/SSL certs for auditors and CSPs). See Iñigo’s slides for details of these. 

A new TR (Technical Recommendation) 102 042 will include the CABF BRs. Tom asked which version of the BRs? Iñigo said 1.1. Tom asked how much work this was to develop? Arno said it's been very involved. 

New STF 458 for e-signatures covers two areas for standardization: 

*	Area 1: Signature creation and validation 
*	Area 2: TSPs 

Deliverables of interest to CABF include: 

*	EN 319 411‐4: Policy and Security Requirements for Trust Service Providers Issuing Certificates; Part 4: Policy requirements for certification authorities issuing TLS/SSL Certificates 
*	EN 319 412 Part 1‐5: Profiles for Trust Service Providers issuing Certificates ; Part 4: Profiles for SSL/TSL certificates issued to organizations (Baseline & EV) 
*	EN 319 403: Conformity Assessment for Trust Service Providers 
*	EN 319 413: Conformity Assessment for Trust Service Providers for issuing certificates 

Browsers will have to shift from old requirements to new requirements. 

EN 319 411‐3 (CA issuing public key certificates) is for non-qualified SSL certs, and not code signing nor SMIME (no specific requirements for them). 

These are the audit requirements. Instead of a three-year term / audit cycle, they are moving to a one-year term / audit cycle. This is an EU directive, but every country can tailor them to its needs. When this becomes applicable, there will be no variation. Countries can only translate the documents into their native language. 

Mads asked if the NIST reference certificate policy document would satisfy these requirements? Arno said many things are missing from the NIST document. 

Iñigo said that not all TS and TRs will become ENs. He said that a TS (Technical Specification) is like an RFC, a recommendation, but an EN is something mandatory. 

EN 319 411-4 will reference CABF specific controls as appropriate. 

Sigi asked what will happen when BRs change. Iñigo and Arno said that the EN needs to be updated too, but obviously that will take time. Updates will be made to EN 319 401/411-x to enhance network security controls to align with CABF network security recommendations. Every change to the EN (to reflect BR updates) means we have to propose the change and ask the countries for approval. We can say that we need 9 months or 6 months to achieve that. If someone raises an objection, that could slow the process. 

The strategy is for 319 411-4 and CABF BRs to be in alignment. ETSI will recommend reference to the current TS 102 042. Draft EN 319 is planned for publication in April 2014, with the final appearing in October 2015. Arno said that input from US agencies like NIST would be welcome. 

The plan is to extend EU standards to Arab countries. Iñigo noted that Japan is already using these standards. 

The draft EU Regulation on trust services will be published around March 2014. Articles 9, 10, 13 and 15 are of interest to CABF 

*	9 conditions on liability to third parties 
*	10 TSPs from third countries 
*	13 supervisory body 
*	15 security requirements applicable to TSPs 
*	16 required audit for qualified level (applies to EV as well) 

Arno said that as a reaction to Diginotar, there's a clause that the supervisory body can control external TSPs. 

Coordinating audit and standards cycle 

Ben Wilson: We don't want a moving target as to applicable CA standards, we and the auditors want to know when a changed standard becomes effective and auditable. Also, it would be nice to coordinate the timing for WebTrust and ETSI so the standards are in parallel. For this, we need to create a regular process. 

Don Sheehy: This may be easier for WebTrust to accomplish than ETSI due to large number of ETSI countries. There are generally two kinds of changes: 

(1) Simple amendments / errata to existing standards - maybe create a hand-off date of Sept. 30 for all new CABF rules to be given to WebTrust and ETSI, with revised audit guidelines to be issued six months later (e.g., March 31). This is doable for WebTrust. The browsers can move faster if necessary to impose a new rule, as in Comodo incident - later, the CABF can enact a new rule, and the auditors can then incorporate the change in audit standards.) 

(2) Totally new standards (e.g., BRs) - the timing for completion major new standards by CABF can be at any time, and we don't need to establish an annual cycle. 

Auditors can't audit to a new CABF standard until it's incorporated into an audit standard. 

Sigi stated there was a third type of standards modification planned future changes - deprecation of a practice, etc. 

Tom Albertson - Emergency browser rule changes are not that hard to introduce and monitor on a short-term basis as needed, and Microsoft will do it again in the future if it would be too slow to go through the regular CABF rule issuance and new audit standards cycle. Any emergency browser program rules can be picked up in later audit rules. But ETSI has indicated it needs at least nine months to implement any new CABF changes, so perhaps the auditors should build changes on an annual basis - instead of creating a new point version of audit standards at odd times. 

Sigi, Opera - We need the auditors to be very clear which versions of the CABF standards are being used to create the various versions of the audit standards, so the browsers can decide if they want to impose the updated CABF standards via browser program rules. 

Ben Wilson - All existing CABF standards have initial paragraphs indicating their version number, as do the audit standards. Should we ask CAs to promise to follow new CABF standards before they are incorporated in new audit cycles? 

Iñigo: Minor changes in CABF standards can be incorporated fairly quickly into ETSI audit standards. The reorganization of CABF standards section numbers can be confusing. It would be helpful if all CABF standards were combined in a single document (BRs, EVGs, and Network Security Requirements). (But some of the CABF standards are for SSL only, while others are for all types of trusted certificates, which could make it hard to incorporate everything in a single document.) 

Gerv: Are CAs now being audited against the Network Security Guidelines? For CAs subject to ETSI audit standards, yes; for CAs subject to WebTrust audit standards, no. 

Kirk: CABF standards are not really mandatory requirements on CAs until auditable standards are created - until then, they are only best practices which are not enforced against CAs. Maybe the CABF should have a hand-off date each year of, e.g., Sept. 1, with an expectation that the audit bodies will have updated audit guidelines by nine (9) months later (so ETSI and WebTrust can both implement the new audit standards at the same time). 

There was further discussion of best way to coordinate ETSI and WebTrust audit standards so that new CABF standards can be implemented and audited at the same time by all auditors. 

Jeremy: we should re-circulate the proposals we previously discussed about creating an annual CABF standards/audit standards update cycle process again for consideration by the Forum. 

Gerv: it looks like it may be difficult to get WebTrust and ETSI to coordinate their effective dates for updated audit standards, and it's not clear that this is a useful goal. The CABF can issue new point version numbers from time to time, and there is no real reason for an annual hand-off date from the CABF to the auditors. Instead, it may be better to let the auditors decide when they want to update their audit standards based on changes to the CABF guidelines. 

Don: An annual hand-off date for CABF standards changes is a good idea to create predictability for the auditors and CAs, so that the audit standards don't change weekly or monthly. 

There was further discussion about whether ETSI can update its audit requirements without having a specific CABF document number to refer to. Also, whatever the CABF does, the browsers will have to decide when to make a new audit standard a requirement for their trusted root programs. 

Jeremy Rowley: Can ETSI move faster than nine months to adopt new CABF requirements as ETSI audit requirements? Iñigo: No. Jeremy: It's probably best to have an annual cycle for changing audit standards so that no CA is subject to more than two audit standards covering its annual audit cycle. 

Ben Wilson: Perhaps the CABF should use Oct. 1 each year to deliver all CABF changes to WebTrust and ETSI for implementation as revised audit standards as soon as possible (e.g., within six months or nine months). 

Tom Albertson: Microsoft likes to process program changes on an annual basis, so it favors an annual release cycle. It would be best if all the browsers can coordinate the effective dates for when CAs are required to follow updated audit standards. 

Mads: We should remove all references in the various CABF guidelines as to specific WebTrust and ETSI version numbers, as this creates a circular and inconsistent result. Other CABF members indicated their agreement. 

Kirk: He will circulate again his prior proposal re an annual cycle for changes to CABF standards and WebTrust/ETSI standards with modifications based on the discussion by the group, with input from Jeremy and Don. 

There was further discussion of how the browsers can coordinate on adopting updated audit standards - the CAs would appreciate clarity and uniformity on effective dates for audit requirements. 

Tom Albertson - Microsoft will likely impose a new root program rule that states new audit requirement will be imposed one year after handoff of CABF changes to the auditors (to let the auditors implement the CABF changes as new audit standards). 

Other Discussion Topics 

*	Iñigo: ETSI is creating a website that lists all the national schemes and accredited auditors who can perform an ETSI audit. 
*	The new ISO proposal is still not fully understood by most CABF members. 
*	CABF requirements allow government audits instead of WebTrust or ETSI - which government audits qualify? Tom Albertson: Microsoft has found most government audits are following ETSI standards. However, government auditors generally are not ETSI qualified. Microsoft is studying the issue - most governments originally followed the European directive on electronic signatures, but some of these standards may be out of date. Microsoft may ask governments to pursue a WebTrust or ETSI audit (using an ETSI qualified auditor). Microsoft would like to move away from pure government audit standards, but has not yet made its decision. Ben Wilson: in general, government criteria and qualification of auditors should be equivalent to ETSI or WebTrust - but only the browsers can impose that as a requirement. 
*	Other countries - Japan, Singapore, Arab countries - are showing an interest in adopting ETSI standards. 

The meeting was adjourned for lunch. 

NIST 

Ben: who has had a chance to read through the CP and write up responses to the NIST document? 

<some assent> 

Ben: FPKI Certificate Policy Working Group have commented as well, and their comments were in line with ours - they are trying to do too much, referencing Federal government documents too often, without a real vision for what they are trying to accomplish. 

Kirk: Can someone briefly summarise why NIST did this document? What is their expectation? It rather appeared out of nowhere. 

Ben: The rationale is to raise the bar. 

Kirk: Why did they decide it needed raising? 

Ben: Diginotar. 

Kirk: Why did they decide to do it in the form of a model CP and CPS? 

Ben: I'm speculating, but I would speculate that sections 5, 6 and 7 of the CP framework are really what they were trying to go after. Secure practices to apply to CAs which are in line with what a CA is expected to read and do and follow. 

Kirk: Were they familiar with our work? 

Ben: They were. They've gone beyond that. They've taken what we have and added to it. They also took the Canadian Government's certificate security model, and some concepts from the Canadian CP. 

Kirk: Were the authors familiar with running a PKI? 

Dean: Did you see the response that Andy from NIST put on the Mozilla list a few weeks ago? A lot of these questions were also asked in the Mozilla forum. Some of the authors came from the Federal PKI team, who do operate a PKI. 

Ben: They operate in a different model, a different environment. I really don't care about anything before section 3-something, and I don't really care what the document says about vetting. 

Jeremy: The vetting requirements are very stringent and go a long way beyond the Baseline Requirements. We should get rid of those. It's very US-centric. 

Ben: Reading email from Andy and paraphrasing, "Yes, some of this came from US Government documents. NIST has an interest in the security of the CA ecosystem. 
After Diginotar, we saw a gap - the need to establish stronger and more auditable security practices. Much of the draft CP was to improve this. The US Government Federal PKI Common Policy was the base document, and they tried to make it more applicable to CAs outside that. We do want to hear comments, which is why we put it out for public comment." 

Ben: They do want it adopted and implemented by a broader community. Andy's response was in response to concerns raised by various international positions on the Mozilla list, which came in response to my comment to the Mozilla forum which suggested that everyone pay attention to it. 

Gerv: By what process would this ever become binding on anyone? 

Ben: Because these concepts form part of the overall stream of thought... some security documents came from a time when people were mainly worried about people fiddling with their mainframes. But now we are in a different world, so we need to ask where we can do better. This document has influence because the intention of NIST to push forward this effort on a broader stage. 

Dean: They have had comments back from 10-15 companies, and we should see another draft as a result. 

Kirk: It's unfortunate; I wish they had approached us. A CP and CPS template seems a really inefficient way of doing it. 

Tom: Leaving aside the way they came into being, I really like the NIST guidelines; what they suggest makes abundant sense to a layman. How much work would it be to go through line by line and formally adopt them? I mean, e.g. if you don't have a disaster recovery plan, you're not ready. 

Kirk/Jeremy: Both WebTrust and BRs require that, and we have it. 

Tom: I prefer to work with a loose industry organization whose membership is 50% outside the US, whereas their focus is narrower. I only want one thing, not 3 (CAB Forum, NIST, ISO) so I would like the CAB Forum to step up and take the best from this document. 

Dean: NIST don't want to own this document long term, so they'd like to have some industry association or group take it over. Even if the CAB Forum stepped up, I have a hard time thinking someone like Paypal would agree to that. So who's it going to be? ITU? OTA? 

Kirk: Has NIST ever given up a document before? I'm not aware of that. 

Tom: Let them worry about ownership. We should absorb their best ideas. 
We are far from experts in network security; NIST is good at that. 

Jeremy: A lot of the NIST stuff is things we threw out of the network security guidelines because e.g. they didn't work for smaller CAs. 

Dean: Small vs. large - all publicly trusted CAs have the same power. That's what Diginotar told us. 

Tom: We battled over this network security issue and who it applies to. 
We can tell NIST we came out with a different conclusion. 

Jeremy: Is the goal then for the CAB Forum to submit something like that? Because the deadline was last Friday. We've rather missed it... 

Dean: Well, we could ask them for more time. 

Jeremy: I am not looking forward to having all the same discussions again. 

Wayne: Tom, I'm hearing you saying that we should try and adopt whatever NIST puts out, but there's a huge gap between them and where we are now. 

Ben: We could adopt certain sections only. 

Tom: I think it's OK to selectively adopt only the things that make sense. Europe is about to set new controls for a wide swathe of people in the PKI business. Perhaps NIST needs to branch out and tackle categories. 

Ben: The problem with Web PKI is because it's all one product, we have to meet the highest standard everywhere, and you end up with economic and regulatory issues. 

Kirk: Are there any issues with the fact that this is a US government agency? 

Tom: I gave big feedback that this is very US-centric. CAB Forum did all the background checks with international lawyers; they didn't do any of that. 

Gerv: We wouldn't want to tie ourselves to a document maintained by a US Government agency, but taking their good ideas is fine. 

Dean: They are looking more at an international standards body to take control of this. 

Kirk: Ben, why don't we get another committee going? Someone could just do a comparison table of what we have in our guidelines and what they have, and we could go through it section by section to see if we wanted to make changes. 

Ben: It's a lot of work, though... 

Kirk: Well, yes. But if there's good stuff in there, we should use it. 
If there are places we can improve, let's do it. But it's a big job. 

Tom: I'll volunteer. I'll probably have to review it anyway. 

Ballot Status 

Ben: All ballots now closed, and the two most recent ones passed. Ballot 100 (to extend the deadline for good vs. unknown in OCSP responses) was withdrawn by the proponent. 

Dean: Ballot 101 and 102 have passed. 

Jeremy: Ballot 103 was the fix of the OCSP AIA exception. 

Rick: So for Ballot 100, the original deadline of August 1st stands. 

Simon: Steve Roylance is working on an amendment to take into account name constraints; he'll have that ready in the next couple of days. 

Gerv: We thought that an exception for name constrained CAs would solve the problem. 

Rick: Problem with that is that name constraints requires issuance of a new intermediate; what about the old one? 

Dean: So summary: ballot 100 is withdrawn, waiting for a new proposal from Steve, no status, and he's running out of time because August 1st is just around the corner. 

Rick: Ballot 89. This was the relaunch of the EV Processing Guidelines, a doc from 2007 I took it upon myself to update. At the MountainView F2F I said I would either update it or ballot to remove the current one from the website. There's been a certain degree of fatigue. Tom offered to review the current version with other browsers, but that was a couple of months ago. So the status is that I'm just waiting for that feedback, and I'll decide whether to take it from there. 

Jeremy: Ballot 103 to fix a gap regarding OCSP where it technically implies that you could issue a certificate with no revocation information at all (if you intended to staple), and this ballot would fix it so you cannot. Rob Stradling sent a suggestion round. 

Ben: There was an argument that it should always be there even for stapling so that the server can get it. But others argued that you can always program around that. 

Robin: This was my fault; it turns out that I don't know of anyone who wants certs without OCSP URLs in them. 

Ben: And you need it in there for clients that don't yet support OCSP stapling. 

Robin: We've endorsed it; you need one more. 

Rick: I might endorse it if I can see it first. 

Ben: What's next? 

Dean: One thing is that 1024-bit cert revocation at the end of this year. It's come to our attention that a lot of subCAs were not aware of this, and were not planning for it. So the question is: what is going to happen to SSL certs of this type found beyond December 31st 2013? 

1024-bit Phase-Out 

*	1024- bit SSL cert revocation - Dean said many sub-CAs may not be aware of this requirement. 
*	Rick said that Microsoft and Mozilla both state that 1024-bit certs must expire by Dec 31, 2013. 
*	Iñigo said that we decided 2 years ago to stop issuing 1024-bit certs. 
*	Rick said that Mozilla is saying they will stop trusting 1024-bit roots early next year. 
*	Rick asked for clarification on the following: if this applies beyond SSL and to non-Web PKI, and if it only applied to certs issued under the BRs? 
*	Jeremy read Mozilla's policy on 1024-bit certs. 
*	Gerv said that policy applied to all certs regardless of issue date. 
*	Rick said he plans to document certs not used by the Web PKI (browsers) and not revoke or even stop issuing these certs this year. 
*	Gerv asked if this is our problem to address? 
*	Rick said these devices are 10 years old in some cases and only support SSL 2.0. 
*	Sig asked if these certs could be used in the Web PKI. Gerv said yes, but only for the specific common names. 
*	Gerv said the risk is that someone could factor the key and steal credit card data. 
*	Rick said there are 150K of these devices in use. 
*	Gerv asked what language we can use to carve out this exception. 
*	Gerv suggested that we could remove the language from the BRs altogether and leave it up to browsers, who would then presumably adopt language similar to Microsoft's. 
*	Tom said that when a 1024-bit factoring attack is "imminent" (about to be announced), Microsoft will react, probably by putting intermediates on the disallowed certificate trust list (CTL). 
*	Kirk said that this requirement should not apply to certs issued prior to the effective date of the BRs. Rick said that if so this doesn't affect code signing certs. 
*	Sig asked if Opera could just blacklist the intermediate. Rick said no, there are probably Web PKI certs issued from the same intermediate. 
*	Gerv said that his takeaway is to change their policy to cover non-leaf certs only. He will take that back to Mozilla for discussion. 
*	Robin said that if we take the 1024-bit requirement out of the BRs, he will lose the leverage he has with customers who resist the change. 
*	Jeremy suggested that we should add an exception for a documented technical reason or substantial economic cost using the same language as for issuing directly from the root. 
*	Kirk asked if the browsers will start showing warnings for 1024-bit certs on Jan 1, 2014? Tom and Gerv said no, but Gerv said they reserve the right to do so. Tom said the goal is to wean users off of 1024-bit so that no one notices when these roots are disabled. 
*	Rick asked to summarize the answers to Rick's questions. 
*	Gerv said the Mozilla policy rules apply to all certs (SSL, code signing, etc.), it only applies to certs issued under the BRs, and the changes we've discussed are our attempt to make it apply only to the Web PKI. 
*	Sig and Gerv suggested that from this point on the certs issued under this exception should be issued under a separate intermediate in case it needs to be distrusted. Rick agreed. 

Day 2 

*	



EV Re Invigoration 



*	Domain validation 
Jeremy outlined attempts to make EV Domain validation guidelines more similar to BRs. 



*	Geoff Keating had objected to removal of the term "Exclusive" 



Wayne proposed just referring to BRs. 
Jeremy: BRs allow " any comparable method". 



Gerv not happy with "any comparable method" in EV. 



Wayne and Simon suggested robust alternative specific methods that are acceptable for EV. 



*	Kirk requested that several wording issues are tidied: 
"Exclusive right to use "confused, could have multiple certs with same domain. Intent was not clear. 



Jeremy made point subdomains can be contractually bound to have exclusive right to use subdomains. e.g. rick.domain.com and tom.domain.com even if not technically possible. 



*	"Parent Subsidiary" wording not clear. 
"Aware of application" part confused and may be superflous as it's intent was to cover spoofing attacks and covered elsewhere in validation. 



*	Too complex to deal with at F2F. 



Actions : 
All to send specific proposed verification methods to Jeremy for inclusion in BRs. 



Jeremy to work up new ballot that tidies language, adds specific validation methods to BRs, changes EV guidelines to refer to BRs. 



*	Kirk proposed informal WG to discuss EV choke points / problems with EV valiidation process. 



SHA1 



*	Tom outline an Advisory note that is in draft. 
When a "Collision attack" is announced: 
A 39-month limit on expiration of SHA1 will be initiated. That helps "encourage" users to migrate to SHA2. 
When a "Chosen prefix attack" is announced: 
Will require immediate switch off of SHA1 issuance. 



Ben suggested that CAs make SHA2 default to encourage more uptake. 



*	Rick has customers look at NIST and see that SHA2 is "required" and are confused. 
Customers struggling to understand greater ubiquity vs higher security. 
Sigi suggested mandating SHA2 for EV. Debate that EV should not imply greater security, only enhanced verification. Not good data on what applications/platforms are broken with SHA2. Tom stated that once collision attack announced then it's irrelevant, move will have to be made immediately. 
Lenka has been using SHA2 only with no issues. 
Don aware of customers who use SHA1 but who are happy to migrate. 
BRs allow 5-year certs and SHA1, but risks of revocation. 
Kirk proposed a 5-year sunset for SHA1 certificate. 
Don - Suggested we prepare a CABF Whitepaper to help users understand risks. Arno suggested reference to existing materials. 



*	



Actions: 



*	Proposed ballot to make SHA2 Default 
Raise as an Ankara agenda item 



Revocation Discussion Revocation - validity, OCSP responses 
Notes by: Tom Albertson, volunteer scribe 10-11 am 
Jeremy suggested framing the discussion with the Netcraft report - key point was how revocation doesn't work in practice. The report cited Firefox and Chrome and Safari as being deficient, Opera and IE revoked properly. 
Rick - certs are out there with CRLs but not OCSP, which means FF doesn't check revocation properly. 
Revocation by blacklist (disallowed CTL) doesn't work because the publicity of revocation decisions can be negative. 
Gerv - Bryan is posting something to the Mozilla discussion listserv for discussion - we want CAs to support OCSP stapling and browser hard fail. 
Dean - A second Netcraft article cites hundreds (800) of SSL certs that are unrevocable because they lack entries in the CRL or OCSP URL. 
Gerv - we want everyone to use OCSP Stapling, and we're trying to remove the exception from OCSP stapling. 
Dean - lack of OCSP URL is endemic, per Netcraft. The (single) Microsoft cert without an OCSP URL was issued to login.skype.com March 2013. [TOM WILL INVESTIGATE THIS WITH MSFT SSLADMIN] 
Sigi - after the effective date of the BRs, browsers should be blocking negotiation of certs without an OCSP URL. Rick says there is no requirement in the BRs to do that. 
Rick - We would get better PR for CABF if the browsers would implement some of these checks. 
Gerv - if we are criticized for browser failures, that's valid and we're not avoiding them. 
Ben - let the notes reflect that it's a good idea to follow up on certs without OCSP URLs with CAs who issue them. The next question is, what do WebTrust and ETSI do to audit this? 
Iñigo - auditors are selective, less than 3% of transactions are reviewed. Chances of catching patterns of inaccuracies or errors are hit or miss (Don says they are not a control point. 
Gerv - Mozilla policy was phrased, are you compliant now or when do you expect to be; so Mozilla compliance is a separate issue from BR compliance. 
Ben - do we want to talk about OCSP Must Staple? 
Robin - a number of CAs are converging on using a small number of CDNs to delivery OCSP Responders. 
Rick - the only way to get the response time that browsers demand, you have to go to a CDN to deliver responses in 10-50 msec. CA only CDN systems can get something but not quite as good. 
Ben - Ballot 103 had language on Must Staple OID, any concerns about that language? The ballot language heeds to change from MUST NOT to SHOULD NOT be marked critical. No actual response to this. 



Ben - let's move on to Technical Constraints. 
Rick - we have some external sub-CA customers, and proposed technical constraints, they said they don't work, they acquire companies and can't accommodate name constraints. Tom said Microsoft has heard anecdotally from several enterprises who are opting for WebTrust audits, and Microsoft as an enterprise is also pursuing a WebTrust audit as Mozilla's technical constraints are impractical. 
Simon and Robin have a few companies that did name constraints in conjunction with a managed service offering. 
Gerv asked did everyone get offered the managed service offering, Tom said that Microsoft put out an RFP and every CA responded with a managed service offering. And the experience at enterprise CA was very similar. He said that was a pretty powerful negative effect to have on the enterprise space. 
Steve Roylance pointed out that the BR says sub-CAs have to be audited, Mozilla says they have to be technically constrained or audited. Gerv questioned the validity of the BR language. Rick checked into it - Ben said that section 17.5 audited and delegated functions covers this. Jeremy says you can outsource domain validation and be audited. Safari doesn't even check for technical constraints. 
If we technically constrain a sub-CA, it's up to the CA to audit their compliance with the constraints. 
Steve's argument is that enterprises who screw up are only shooting themselves in the foot. Rick says that Netcraft doesn't distinguish between enterprise CAs and commercial CAs. 
Simon - can we come up with a checklist of things we are concerned about? 
Robin - what are the risks to the internet users that we need to protect against? Or, what should we require action of the CA if we find a constrained sub-CA who issues a bad cert? 
Ben - what if the sub-CA makes a contractual commitment to comply with the baseline requirements in addition to technical constraints. Jeremy: The BR 14.2.2 already says the CA shall internally audit the sub-CA for contractual obligations. 
Tom - Microsoft prefers the contractual constraints - status quo - but frankly we could not devise a policy option as powerful as the technical constraints option. 
Sigi - would a test suite to verify browser compliance with the BRs help things? 
Gerv - it likely doesn't matter whether these browser revocation issues are called out in a test suite or in a document. Rick will tell you he has been working on the browser processing requirements as well, but because conventional wisdom about what we should do will change over six months we shouldn't be trying to hit a moving target. 
Ben - doesn't NIST or WPKOps have a test suite we could use? Rick says the test suite is the equivalent of an audit for BR compliance. Ben says they are looking at the test suite option and how to put it together - top 10 items, fundamental architecture, etc - what's most important to the developers of the tool? 
Robin - CAB Forum Policy checking tool. 
Don - question, it is not unusual for one person to take the info and have another person validate it: that counts as the audit for some CAs. The 3% is the after the fact monitoring, not part of the pre-issuance workload. (The general consensus was Don's interpretation was valid). 



Videotaping Ceremonies 

Atilla - under the BRs the root key pair should be audited or videotaped. Under EV Guidelines 1.3 says the root key pair must be audited and videotaped. Root or chain? (Consensus is split on this - Don thinks the whole chain, Iñigo and others say just the root). We need to discuss and amend the EV Guidelines. Iñigo says you can generate as many sub-CAs as you want - you can revoke sub-CAs with problems as many times as you want, but revoking a root means you are dismissing it. Many felt: 
Roots should be witnessed under BR or EV. 
Sub-CAs do not need to be witnessed because many sub-CAs make witnessing impractical. 
The Forum launched into multiple conversations, and I could not capture every comment. 
Atilla thinks the current language must be made more explicit. 
Don - Evidence of an accurate creation - can be done by a witness or by videotaping. What's important is consistency between BR and EV; EV is a tougher standard. 
Kirk - BR 17.7 says the CA should prepare a script and have a qualified auditor or do a video. 
Ben - we should have a ballot on this: we can amend the EVGs and revise them to be more like the BRs; for issuing CAs maybe you have to have a script and documentation without auditor witness. This will make it clearer to CAs. 
Kirk - the BR procedures cover EV scenarios too. 
Tom - NIST has something to say about this - NIST 9724 6.1. 

Website Editing CAB Forum Day 2 Afternoon Meeting Notes (12.06.2013) 
TOPICS 



*	Reinvigorating the EV SSL 
*	Bylaws 
*	IPR issue 
*	Network Security 
*	Web Site 
*	NIST Document 

NOTES 



1.	Dean said we could discuss the web site this afternoon and work on it in different groups. 
2.	Bylaws: Discussion about press announcements. CAB Forum can express its opinions in different organizations. Interested parties and observers can also be invited to CAB Forum meetings. Relying parties, third parties etc. can be invited. They can also join working groups. Examine the "Bylaws of the CAB Forum". 
3.	Section 3.1 is about interested parties. Observers are not covered by these bylaws so they should be, said Kirk. We don't have a participation agreement, said Gerv. Jeremy said we had signed similar kinds of agreements before with ETSI, ICANN, and the like so they can be used as templates. 
4.	Interested parties are people who will be involved in specific issues like working groups (Kirk). So first, the lightweight IPR should be written. Ben will work on with better understanding base on comments from Gerv. 
5.	Press is not qualified as an interested party said Dean. Press, for instance can be an interested party on an ad-hoc basis even for partial participation said Kirk. Whereas, an observer is joining the F2Fs fully, as a difference to mention. 
6.	Jeremy mentioned that it would be difficult to organize the meetings with so many participants as interested parties etc. 
7.	Web Site: Topics to be selected. 

1.	For instance "Information for consumers: Types of SSL certs. DV, OV, EV, etc." should be edited by the CAB Forum members. Basic PKI and SSL information should be gathered here. Already some info have been inserted to web page during Mozilla meeting (previous F2F). 
2.	Dean said, the contents will be prepared and then passed to Wayne for a new design and web site structure. 
3.	Ben said, the home page is to help consumers to get information about CAB Forum. Visitors of this web page will be consumers, web owners, sys admins, auditors, people interested in being a forum member, regulators (Dean). 
4.	"News" link on the web page also means to include "Press". "Information for Press" is also included. Document section is added. 
5.	Information for potential CABF members. The criteria are given. For observes and interested parties, criteria will be put again. 
6.	Information for auditors should be enriched by current links and documents etc. (WebTrust and ETSI). 
7.	About Section: 

1.	"Mission" of the CABF. About CABF. "Governance, Procedures, Bylaws and Leadership" merged. "Members" with links to their home pages to be updated. 
2.	"Documents" and "FAQs" to be revised. 
3.	"Working Groups" to be updated. 
4.	"Transparency Issues" will be deleted as it is redundant. 

8.	"Recommendations" will be deleted. 
9.	Tools and Resources: Links to browsers' technical pages will be added. 
10.	Proceedings: Public list for ballots will be linked. 

8.	Assignments will be made for CABF members for preparing the sections of the web site. 

1.	Info for Auditors: Don and Iñigo 
2.	Info for Consumers: Simon 
3.	Info for Web Site Owners and Sys Admins: Robin 
4.	Info for Manufacturers and Developers: Rick 
5.	Info for Potential CABF Members: Dean 
6.	Info for the Press: Gerv 
7.	Mission, Governance, Procedures, Bylaws and Leadership: Ben 
8.	Mailing Lists: Ben 
9.	IPR: Ben 
10.	EV Guidelines: Mads 
11.	BR: Mert 
12.	Working Groups - Code Signing: Dean 
13.	Browser, root and Other Info: Cornelia 
14.	Liaisons: Arno 
15.	Proceedings: John 
16.	Browser OS Versions: Sig 
17.	Research Statistics: Don 

CAA Records Phone: Review of what CAA is - system for domain owners to add themselves to list of high risk domains for which CAs should make extra checks before issuing certs. 

Two parts to proposal, in the BRs - Part 1 - it is a recommendation/requirement that CAs use and implement CAA records; and part 2 - that CAs must state in their policy / practice statement how they use the DNS / CAA records. 

Question - do CAs have discretion in how to apply this? 

Phil: Don't expect CAs to simply not issue certs to sites listed. But all CAs should at least investigate, stop automatic issuance, and move to procedures for handling anomalous requests where a diffferent CA is listed in the CAA. 
Ben: Should be treated as high risk? 
Gerv: A question about what we should do, not must do. Is this a hard requirement? 



Phill: It is an implicit requirement only, a CA could say that they don't use the records. 
Gerv: Should say if they use records, or how they use the records? 
Phill: Just putting on the policy that CAs don't check CAA, might in itself make it more wanted to start using it. 

Phill: Regarding a future effective date, it is not about getting support or whether it is a normative requirement, but we want to get something into the Baseline Requirements as soon as possible, and it is unknown how these records will end up working in real world. Need data before we can predict corner cases. Instead of having a long theoretical discussion now, let's get a requirement that the CA address CAA in their CP/CPS into the BRs now, which means CAs must at least investigate and decide what they want to do. 
Gerv: Why are you not asking for something stronger, is it just to be cautious? 
Phill: Happy to do something stronger. If people say they can't I am also happy. Purpose of records is to help CAs. 
Gerv: Say we set an effective date, no automatic issuance for risky domains after that date? 
Wayne: For example a company is customer of CA1, CA1 automatically create a CAA record, without customer knowing, which binds the customer to CA1. 
If company buys cert from CA2, tries to get cert, but it now takes longer, as it cannot be automated. 
Ben: Think cautious approach is better. First part of proposal is also open, that we recommend using these. 
Rick: Valuable to know who supports this. 
Gerv: But if nobody starts looking at this, how will it be an incentive to start supporting it? We will be stuck where we are. 
Phil: Want to avoid deadlines, want to avoid arguing about extensions later, prefer a situation where we decide now, CAs must put it on their roadmaps. Then later, with real world data, we understand what a stricter requirement might be. 
Jeremy: Deadline to make a deadline? If we don't make a deadline now, just leave it to CAs, as we don't have a standard yet. 
Gerv: For Mozilla, having this information in the CPS would be informative, then we can discuss more in a later meeting. If nobody does anything, we might need to push it more then. 
Ben: What is the deadline for updating the CPS? 
Kirk: What if the person who buys certs is not in control of DNS records. 
Are DNS records secure enough? Big companies use many different CAs. Not satisfied CAA is a good proposal. 
Gerv: If CAs do this without users knowing, this would be bad. 
Kirk: But that would be the right thing, we put our name into the records. 
The spec allows you to have as many names as you want. Why don't we also check at browser time. 
Gerv: This is not the design, the DNS might be updated after the cert has been issued. 
Phill: The IETF decided to take this out. 
Jeremy: becoming supportive. this can be treated as high risk, which is good. 
Kirk: what do customers do if they can't get a cert? 
Phill: CAs must assure themselves that they deal with the right customer. 
Proposal just says that you have to spell out what you do in such cases. 
Jeremy - if this was just a high risk check, it would be a good requirement. 
Phill: Fine with pushing it through as part of the high risk screening requirement. 
Do CAs' know how to do this? 
Rick: Writing documentation for customers how to do this. What if the DNS records have typos? 
Phill: Assure yourself that no CAs have similar names, then do it as high risk process, which you would do anyway. 
Wayne: Potential benefits outweigh the risk, the risk is CAs not playing nice. 
Kirk: Turns sales into a two-step process, and the two people responsible within the customer's organization might not even know each other. 
Can issue certs even when not listed in the CAA records, just have to use a non-automated/high-risk process. 
Might be a bad idea if it becomes too widespread. Might happen if in the BR, or browsers mandate. 
Wayne: Possible arms race between CAs, if all CAs say they must be used, this become commonplace, and not worth as much 
Gerv: CAs saying these records are required would be lying 
Kirk: Worried about articles, saying "Comodo issued certs to a company it was accredited for" 
Robin: This is for domains which care about which CAs they use, all owners might not care. E.g. a company might want to know if someone in their own company tries to buy certs. 
Gerv: There might be additional checks in the CAs when they find this record. 
Kirk: This would work also for subdomains? 
Phil: Yes 
Ben: So a motion could be that these records would make it into high risk. 
This would be auditable, not needed in CPS. 
Rick: Another way to move forward in baby steps. Browsers and CAs create their own CAA records. We will all figure out how difficult this is, and learn, then discuss more. 
Kirk: Is it easy to find this data? 
Rick: Not easy, tools don't support this yet. 
Ben: Rephrasing: If browsers have this as a CAA records, then CAs must use it? 
Rick: first step is only to update the records, then report back. next step might be for CAs to add records for themselves. This has nothing to do with the root program of browsers. 
Phil: Sounds like a good first step. Ben, can you write it up? 
Gerv: I don't think it is unreasonable to state how CAAs are used, in the CPS. I can't force any DNS updates for us, but I can ask for it to be done. 
Rick: This might be the same as for other customers. 
Gerv: The spec exists, and sites might start using it anyhow, this might cause pressure for CAs. Especially if there is a misissuance. We have hundreds of websites, this might be a good test case. 
Rick: Don't need DNS records for all domains, start with just one. 
Robin: What will happen in year or two, and CAs want to make CAAs easy, they will then create a tool to do so. 
Rick: Yes, we will help them do so. 
Robin: The tool will put in the name of the tool creator, but should allow other names. 
Iñigo: Once one CA starts, it will force other CAs. 
Gerv: Do any domains have CAA records already? 
Phil: I can't find any 
Kirk: What if CAs require their customers to change their CAAs? 
Rick: It is in the customer's best interest to add their CA. 
Gerv: If it is so easy that everyone will do it, then it will also be easy to change it afterwards too. 
Rick: If a CA says all other CAA records must go, this would be unethical. 
Wayne: This might become a blocking mechanism. 
Gerv: Key pinning has the same problem. The site will only allow certs from certain CAs, so this too might make it harder to switch CAs. 
Wayne: I don't want to accidentally misissue certs, so I think this is good, but here are risks, and in reality, some unethical behaviour will happen. 
Rick: The abuse is most likely from a big CA, and big CAs are less likely to be hurt. 
Wayne: Depends on the CA, and the rules. E.g. automatic/non-automatic issuance policies, market share, customer types and their knowledge. 
Robin: This gives a company a means to state their CAs in some way. I don't think there will be a huge takeup, but it is worthwhile for those who care. 
Simon: Will there be a market pressure for customers to do this? 
Kirk: If we do this, we should be explicit and say that this does not block other CAs to issue certs. I would like to see some info first, not vote on it yet. 
Gerv: Depends on the setup, some companies might be easy, e.g. for hosting, it might be impossible. 
Conclusion: Ask browsers to update their CAA records, will look at reports afterwards. 

Reinvigorating the EV SSL Certificate 
This section started with some discussion on statistics, EV SSL has 2% adoption of all SSL certificates according to Netcraft statistics, but there was uncertainty whether this was related to the number of SSL sites or the number of SSL sessions. A single SSL site with many users could be responsible for many SSL sessions. 
Ben: Regardless of what the statistics are, I think it's worth discussing reinvigorating the EV SSL Certificate. One of the things people talk about when they talk about success in this industry and the things that we have worked on, it's the EV SSL Certificate. 
Jeremy: I think the EV (code signing) group that Kirk recommended goes a long way towards addressing a lot of those issues, as far as validation goes. But one of the limitations is entity type, i.e. EV for individuals. What do people think about doing a Kantara-type level 3 (aka a NIST 800-63 level 3) for EV vetting for individuals? Where you have done that vetting, you have an ID document and you could put a hash of that into the certificate as the unique identifier. This could be used for both EV SSL and EV Code Signing certificates. 



Jeremy: The U.S. government has said that the medium assurance level (equivalent to NIST level 3 or Kantara level 3) is an appropriate level for establishing that you know who the individual is, you know their identity. And you do because you have an identity document better than lot of the organization documents with an id number on it that could be verified by a notary or an attorney. You could include that into a registration field. 



Kirk: When we discussed this a few years ago we could not, at least from the US perspective, maintain a list of notaries. There was no effective way to confirm the notary. 
Jeremy: Just to simplify then, we could do this with an attorney just as we do with the current verification practices we already have in place and for the independent confirmation provisions of the EVGs. 
Kirk: How many individuals have a friendly attorney that they could go in to see and have this done? 
Jeremy: The benefits of EV for individuals will be seen most in Germany because they have a lot of sole proprietors who do not qualify under the current EVGs. There you could verify who they are with notaries for EV. 
Kirk: And you could figure out that they really are notaries and not photo-shopped? 



Jeremy: Yes, you can look up their telephone number on the official notary website, call them and say Did you verify this person on this day with this passport number and with this id? (independent confirmation). Then you can verify that person and this is actually more assurance about who that person is than a lot of governmental databases. 
Kirk: If there is a way to confirm the LRA (Local Registration Authority), then I think we should do individual EV certs. But I don't know if that's a big market. 
Gerv: Is it going to be necessary to roll this out on a per country basis or are we going to write something that is worldwide? 
Jeremy: If it is worldwide, it would not apply to a lot of countries. Like Kirk said, you can't verify notaries in the US that easily. You could verify an attorney that would say you have to do an independent confirmation. It's very simple to change the guidelines to say that. 
Gerv: You would list the things that have to be true about a country in order to use in such a procedure. And those things will be true only in some countries. 
Jeremy: And that's actually the same as it is for EV right now. You can't do a lot of verification EV in certain countries because the checks you have to do are not true. 
Robin: How would you define the level 3 type assurance, will you take it from NIST or somewhere else? 
Jeremy: I will probably take it from Kantara because it's supposed to more international than US-oriented NIST level 3. Kantara is a different industry body that set identity proof requirements for anything. Kantara level 3 applies to various countries and is equivalent to NIST level 3. 
Ben: Netcraft indicated that EV was dropping down. Are there other things we could do to improve EV? 
Jeremy: The big question is what is limiting the growth of EV? If it's validation requirements, we should address those. If it's price, it's up to the individual CAs to figure out. 
Kirk: How many websites have their certificates bought for them by their outsourced website managers? They may not want to bother with EV certificates. 
Jeremy: Yes, that's true, hosting companies are particular reluctant to EV. And they are buying certificates for their customers and I am not sure how to solve that issue. Improving domain registration practices could be a good start. 
Ben: Are the browsers happy with EV? What's your experience with EV? 
Sigi: What is really the difference between DV and EV for an end user? We are struggling to come up what is actually needed for the user. It's ultimately about the trust you put in the site you are surfing on. 
Gerv: EV is about knowing whose site it is. You have the ability to present the actual name of the company rather than the domain name. You don't think the consumer is appreciated being told that he is on Marks and Spencer in UK rather than m&s.com? DV certs don't have that information at all. 
Sigi: But Google is google and Yahoo is yahoo, they are their domain names. That's not much more to it than that. 
Rick: Ebay is ebay, but I can get a domain name for shopebay.com, but I am not Ebay. And a DV certificate will not tell you that. I will not be able to get an EV certificate for Ebay. 
Sigi: You could probably get an EV certificate for shopebay. You could register a company called shopebay in country where you don't have trademark law stopping that. If you absolutely want it, you can get an EV certificate for shopebay as well. 
Kirk: Sigi is saying that the users don't care about the information in the certificates, only the green bar. 
Gerv: It may not help that the marketing surrounding EV has not been so much about identity as about 'the green bar makes you safer' or 'the green bar is better'. 
Sigi: I don't think that the entire idea of educating the user is the wrong way to go, but what does the user need? What can we give the user; we can add more to the EV certificates, like requirements for the server as well. 
Rick: That's a good point, it could be difficult to do, but it's worth discussing. Should EV mean more than enhanced validation? Should it mean that the CA or an independent body has verified that you get a higher score in SSLLabs, and not allowing SSL2.0, and things like that. 
Ben: EV might mean Extended Validation, but we could come up with other requirements. 
Gerv: If something technical (like SSL2.0) is insecure we should switch it off, not only for EV but for all SSL certificates. If it's dangerous, why the difference? 
Sigi: SSL3.0 is dangerous, RC4 is dangerous, unpatched renegotiations is dangerous, but all is allowed by default. But you could disallow that in a higher security brand. 
Kirk: One problem could be that we will sell fewer certificates. 
Gerv: In this discussion of increasing the EV take-up, it seems that we have ideas that will decrease it. 
Ben: It would be good to figure out what first little step we could take to improve the security for end users. 
Rick: The fundamental problem with EV is that it relies on the user to remember that when I used to go to a site this used to have a green bar. 
Ben: We have fifteen minutes left, Jeremy will follow up on EV for individuals, but we'll need to finish this discussion later. 
Trusted Service List (TSL) 
Tom: A question for Arno; can you use TSL to verify whether the identity was confirmed by an approved TSL vendor and rely on that to authenticate somebody as a legal individual? In other words, could an application be written for CAs that verifies an appropriate TSL vendor, and use that confirmed identity of the applicant to approve the application for an EV Certification and just leave it at that? 
Arno: OK, in the domain of TSL it is possible to provide a reliable link to an organization. If you ask for a registry or directory service we have only the AIA tool for authority input. There is a service identifier for requesting registry services for companies. I am not sure whether there is a registry service that ties into identification systems of persons. 
Iñigo: And all the CAs are covered by the TSL, including sub CAs and their services. The only mandate is that this is for Qualified services, so SSL certificate services are not considered qualified (at least not now). This has nothing to do with DNS, domains or registrars etc. 
Tom: Can I use the TSL if I have the need to verify the identity of people receiving healthcare services. 
Arno: We have done this in Germany for 7 years. 
Iñigo: For citizens, companies and employees, there is no problem. 
Tom: I link the idea of transitive trust, you guys have done all the hard work. You can just rely upon that and issue the certificate. 
Kirk: Can we read it? Can we receive information from an id card put into a computer. Can we as a CA read it? 
Arno: You can link to a trustworthy source. 
Iñigo: The TSL is just a list of trust services. 
Arno: Another initiative is authentication in the new regulation. In 18 months' time this could be included as verification services. You can never get access to the German registry. The registry can only verify information, but not give information. 
Ben: Let's wrap up for the meeting. Thanks everyone and thanks to Symantec for hosting this face-to-face meeting. 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130812/6775cbcd/attachment-0002.html>