Meeting 33 – Beijing China

The antitrust statement was read.

Present: Annabel Lewis, Arno Fiedler, Atilla Biler, Atsushi Inaba, Ben Wilson, Blues Lin, Bruce Morton, Cecilia Kam, Chris Bailey, Cui Jiu Qiang, David Chen, Dean Coclin, Don Sheehy, Doug Beattie, Gervase Markham, Haochun Li, Iñigo Barreira, Jeremy Rowley, John Johansen, Kirk Hall, Li-Chun Chen, Moudrick Dadashov, Patricia Forsyth, Richard Wang, Rick Andrews, Ryan Sleevi (by telephone), Tom Albertson, Wayne Thayer, Hanrui Gao (Day 2)

Day 1 – Tuesday, 16 September 2014

Extended Validation Working Group Discussions (prepared by Robin Alden)

1. Summary of results on Verified Method of Communications ballot

This ballot passed. The Wiki will be updated shortly.

2. Status of ballot on Section 11.13 (age of Information) and release timeline

Trying to clarify 11.13 (re-use of info). Try to send out ballot start of next week. The only change is to clarify the existing language.

3. Attorney/Accountant Letter changes – Discuss change of terminology to just a professional opinion letter

Kirk’s proposed change. Kirk leading discussion on this item. Background: today many items can be confirmed during the authentication process by attorney or accountant letter, but other things cannot be. Kirk sent the latest draft on Sunday to EV section. Forwarding now to all present. Look for ‘Attorney accountant letter changes document.’

The first change is in the definitions.

We already have a definition for accountant letter and attorney letter. Kirk added a new term ‘Verified Professional Letter’ (to leave some of the current uses intact.) 9.2.1 new language. If a customer wants to use a trade name, today EV says trade name first and then corporate name in brackets. Kirk proposes that the DBA name (or trademark) could be used on its own. Gerv: I wonder if the original rationale was that the strings be unique. SO only 1 RIM in Canada, so hard for someone else to get something similar – whereas trademarks come in categories – e.g. Microsoft is a brand of ladies tights in France. (as well as a well known software company).

Kirk: In 2005 I might have said – that’s just it’s trademark, not its real name. But today some of the green bars look very strange because it gets truncated in strange ways. Gerv: To argue against myself – particularly on mobile there is very little real-estate.

Robin: We have had a problem with an organization getting (non-EV) code signing certificates from us using multiple DBAs to get many CS certificates with different O= names. Kirk: Yes, we have experienced problems with e.g. ‘Nike’.

Ben: trade names comes first – which is good. Richard Wang: My EV, WoSign first, then full name – which is good. Kirk: I think my idea is a bad idea… There are 4 organization types. Private organization, Government, Business Entities, & international organization. Today we allow attorney letter for government , but not for the other 3 types. I raised a question in the last call why not? Attorneys are really good at verifying businesses exist. Ditto general business entities. My proposal allows for attorney letters for all 4 categories. I added that the professional letters should also attach copies of the documents relied upon. 1 argument we had against this last time – for regular companies it shouldn’t be hard for the CA to look it up (so maybe they should) – to address this I suggested the evidence be provided along with the attorney letter (perhaps so the CA may check)

Ben: What if the basis of the opinion was something other than the options set-out in the amendment? Kirk: I said a copy of any supporting doc. Ben suggested that some explicit examples would be good. Cecilia: What’s the difference between OV and EV, in that case? Kirk: I see your point, but why allow attorney letter for government but not for the other 3. For partnerships, e.g., I would be happier with an attorney letter than seeing the partnership agreement – which could have been photo-altered. Also, what about International Organizations where I can’t read or understand the document. Jeremy: For business entities – need to do F2F. Kirk: I would have the letter replace the ‘principal’ identification. Sub-section 3 and sub-section 4 seem best suitable for this. Cecilia: Can an accountant verify the existence of a government body? Don: National government – sure, easy enough. Local government can be more fluid, but can be done (and must be redone regularly) Arno: Notary? Kirk: Already included. Ben: I don’t have a problem with accountants.

Kirk: Some good points, thanks. At our next meeting lets be prepared to make a final decision on whether all 4 categories is OK. Ben: Gerv said that they can’t do domain validation. I agree with the concept they cant do the technical parts (domain control), but if there is a missing gap you can have the professional tie together the missing part, the technical with the paperwork. (Kirk: We’re coming to that in 11.6)

Kirk: 11.3 assumed name. – changed to VPL (Verified Professional Letter)

11.4 address, changed to VPL 11.5 operational existence, changed to VPL 11.6 domain name. Attestation letter is already allowed. Added a sub-section (b) to accept a VPL. Ben: we talked about this before, but had no caveat on (b). Maybe we add one – provided that the CA has done something else – as mentioned to Gerv. Kirk: I thought you could do a whois lookup. Also customer may say they don’t own, but have licence to use a domain. Gerv: We think its important the CAs use technical means to verify practical control. There are a number of ways that can be done. (listed..). Just getting a lawyer to write the letter is not enough. Kirk: If the customer shows in WHOIS you don’t have to do more..? “1) confirm with registrar?” (whois discussion)

Ben: The document says you can do 1 through 6 (from BR). All I’m saying is that when they’ve done 1 through 6, the CA may not feel certain – and the VPL is a suggestion for a useful addition. Kirk: Leaving that aside for a moment, because a CA can always ask for more. at 11.13.3 sub 1, both already indicate that an attorney letter is already permitted . Ben: We’re not debating over the practical demonstration of control. Kirk: Exactly.

Ben: I agree that you have to have something, because a blank professional letter may lead to problems because they might not have the technical know-how. Kirk: – I’d rather have the attorney do it. Ben: How about having the ‘shall attach supporting docs’ language. kirk: OK, that’s good. Ryan Sleevi: Who is liable: Kirk: The professional is liable for their work. Ryan: Attorneys can make mistakes. Competence. Kirk: Good point, but allowing the use of a VPL, allows LRAs. Good point that the main point of these changes is to say that if it is allowed for some things why not for others.. Ryan: (inaudible)

Kirk: Anything an attorney letter talks about must have attached documentation. Maybe we say the CA must examine it (consider documentation in other languages?) The other thing is, for misbehaviour you can report the professional to their professional body. They risk their license. Annabel Lewis: A single occurrence wont risk their licence, but the more egregious or frequent it is the more likely they will lose their licence. Ben: Perhaps we should have a separate letter set out. Kirk: If they don’t understand they mustn’t sign! Ryan: Are there financial incentives to do the wrong thing? Kirk: An attorney letter is a big deal to attorneys. They can have huge liability. Ryan: (inaudible) Kirk: Accounting firms, has anyone been reported for doing an inadequate audit? Gerv: I was hoping we could take some action, but it didn’t happen. On another recent occasion there was concern that an audit didn’t come up to scratch, but we may discuss further tomorrow. If Mozilla’s public discussion process reveals problems that an audit should have found, then either the CA can come up with a letter from the same auditor explaining the reasons it wont be missed again – or find a different auditor. Kirk: 11.13.3

Allow reuse of information if it’s a new change. Added a new b,c,d. Why can’t you continue to use the VPL for name, title, authority, business address, phone number. Cecilia: I think this is already allowed. Ben: me too. Let’s take that offline. Perhaps it needs to be clearer. Kirk: Does anyone disagree with the concept of allowing a VPL to continue to be used. Ben: How do you know it hasn’t changed (Does the tree falling in the forest make a sound when there is no-one there to hear it?) Kirk: I need to clean it up, but I will bring back the next draft and collapse it all to say may continue to rely on an VPL. Ben: Just as long as we don’t fall into the trap of assuming something true remains true for ever. Dean: So Kirk you will revise Kirk: yes.

4. Permit professional letters for use in verifying domain names

5. Permit professional letters for use in verifying legal existence and identities

discussed above.

6. Revisions to section 11.7 – changes for apparent authority and agency and clarify what we are actually verifying

Kirk: 11.7 we go back and forth between authorized, expressly authorized, etc. Agency, signing authority, many terms used. We’re not really verifying agency. We are verifying apparent agency or authority. Ben: What if we don’t say ‘agency’ in the legal sense, but head more towards ‘authorization’ in the network security concept. Or if we use agency we take it and make it more conceptual – say the agency step, not legal agency. Sounds same as authorization. Employment.. Are they employed? – If so we assume they are authorized. We assume that if they have a certain title we assume they have authority to sign. Maybe that’s all you have to do. Kirk: Not trying to change the steps, just changing what we pretend we’re doing. We’re not really verifying agency. I will come back with language.

7. Domain validation using DNS changes within a certain window

Jeremy: Ryan’s proposal. Nothing new really. Reusing existing DV control, (or IP ownership) make sure …….

Ben: Complex to work out the exact language. We’re talking about two issues.

1. validity of information

2. make provisions concerning domain control – there is a gap – if you make a change on a website then that shows control – my issue is that if someone can make a change to the DNS zone then that is a game-over situation – so should be more restrictive than making a change to a random self-restricted webpage

We’re not talking about a change period for domain, we’re talking about an additional item that isn’t related to website changes, but related to a change in the DNS zone. Some CAs use it because it is a demonstration of control. Kirk: sub 6 says ‘having an application make a change on a site…’ Ryan’s language goes there(?) Ben: Suggestion, mixed in with that, is a separate subsection about DNS method. Ryan: I agree.

There was talk of adding additional methods and that should be balloted. Ben: OK, the actions are:

1 come up with separate ballot for DNS method. (Ben) 2 Idea of tightening the change of website – so more detail over what you can do or not do. (Ryan) 3 duration and reuse of received info (11.1) (Ryan)

8. Insurance Proposal

Ben made an introduction to the topic of Insurance. Atilla had had a concern about insurance. Ben had said insurance coverage must be global. ($ figures in this section are illustrative rather than actual $ costs) Atilla says his insurance can give him a policy for (say $20k pa) but doesn’t cover USA. Including USA costs (say) twice as much. The practices of a CA might be local in effect and action, or global in nature. How do we accommodate the fact that the internet is global in nature.

Kirk: I introduced this discussion. Do we need insurance? You (Ben) said – can we make it more relevant. I’m not sure we can. Keep working if you like, but not sure its getting better. Ben: Insurance is changing for the better. Kirk: No, it isn’t. (agreement not reached) Ben: We are trying to solve the more general problem of the CA, general liability, etc. Ryan: I am pessimistic about the value of insurance. Dean: Do you feel that CAs (somewhere in source doc) need insurance to operate. Globally we don’t licence CAs. Ryan: In an ideal world I’d love CAs to be financially stable, etc, but in the real world it can’t be done. Ben: Ask your risk management (or contracting) department if they have any agreements in place where Google are named in 3rd party insurance policies. Ryan: I Can’t do that.

Dean: We should broaden the discussion to the whole CA scope – not just EV.

(break for tea)

EV: Dean: Is anyone having problems with EV? Ben: Is there anything lost in interpretation, or social structures, international differences? Dean: Arno – I’ve heard of cases in DE or NL where people are classified as sole proprietorships but can’t get an opinion letter. Cecilia: Kirk raised this for #3. Jeremy: That doesn’t replace that they have to verify registration with the government – and there is no registration for some classes of sole propietorships. It takes months not days to register in DE. Arno: Different registers. Deutsche Telecom and DTrust don’t do EV for natural persons – only for organizations (public, non-profit). Ben: Dean’s question reminded me we had the comment from Richard about the attorney letter and site visit being problematic. With regards to Japan – Attorney letter and accountants – we were able to identify what was an adequate level of competency. We felt it was satisfactory to use the Japanese words for their legal persons/roles/bodies. The problem is that in the US/Canada there are too many(!) lawyers – so they are easy to find. In other countries there may be ways to define (e.g.) to have an appendix for China (as we do for Japan) to specify more precisely what we can expect. We were going to write an appendix for DE too, but never got around to it because we felt the current wording was probably sufficient, but it is an option for DE, CN, and any other country. Richard: Every CN company operates at the address in its business licence. The company cannot operate at a different address. (repeats in Chinese) (discussion in Chinese) Brian Hsiung (Sunrise CPAs): It is illegal to carry out business other than at the (a) registered address. David Chen: Taiwan – The same, but not so strict. Ben: Perhaps we say it in English, but with some Chinese words in (an appendix) .

Code Signing Working Group Discussions

The Code Signing Working Group reviewed and discussed comments received thus far. Comments included: removing the Subscriber as a beneficiary, validity and archival periods for timestamping and revocation information, section renumbering, verification of private key possession, prohibition of using the same key for other purposes, and use of a persistent ID and EU law prohibiting use of Electronic ID data (use of personal information must be for an official purpose), .

Li-Chun Chen of Chungwa Telecom raised questions about compliance with RFC 5280 and the extended key usage with id-kp-clientAuth and technical constraints to limit the scope of issuance and gave a presentation titled Possible conflict between Microsoft Root Certification Technical Requirement V 2.0 and CABF Baseline Requirement about extendedKeyUsage.

Certificate Policy Review Working Group Discussions

The group discussed how to best align the numbering among RFC 3647, the Baseline Requirements, WebTrust and ETSI. Atilla said that alignment may not work in the end because there is not a one-to-one correspondence. Jeremy said he thinking it can be done because he already has converted the Baseline Requirements over to the RFC 3647 format. There was a question about how soon NIST IR 7924 would be available. Jeremy said he would circulate the reformatted version and that we can prioritize work on where there are gaps or holes that Iñigo’s chart identifies. Ben said that because Iñigo’s chart only covers the upper level of an outline, such as “6.5,” one might infer that there isn’t a gap, but when you go down one level (6.5.1) or two levels (6.5.1.1), it might reveal very clear gaps, so we’ll have to be careful in our initial review.

Day 2 – Wednesday, 17 September 2014

Recap of Working Group Discussions

(Prepared by Gerv)

EV

Jeremy: a short meeting yesterday.

• Finished the ballot on Verified Method of Communication: passed.
• Proposing a ballot next week on Reuse of Information (section 11.3). This section is currently very confusing.
• Discussed Kirk’s proposal to clarify the scope of attorney opinion letters.
• Also the use of such letters to verify legal existence in relation to international business entities (categories 3 and 4).
• Using the letter for domain verification – there were concerns with that. People want to see technical verification.
• Discussed possible additional work product.

Code Signing

Dean:

• Comment period closes middle/end October. Then a redlined version will go out.
• Expecting additional comments from the public and targeted software companies (e.g. Apache).

Cert Policy/Security Review

Jeremy:

• Discussed 3647 format a lot, but no clear consensus.
• Still want to assess how much work it would be.
• Jeremy and Iñigo have put together translation tables.
• NIST IR document – using it to identify areas where the Forum could discuss relevant topics. Operational guidelines, physical controls…

Dean: we made a lot of progress in all three groups.

Ben: the certificate policy group needs more involvement.

Browser Updates

Mozilla

(Prepared by Doug)

Mozilla 0. mozilla::pkix

Shipped in Firefox 31 in July. We continue to maintain a wiki page with behavioral changes, and things for CAs to fix: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes

• All CAs in the room have fixed these, good news.
• In May CA communication, asked us to test, items found and then resolved. Process is mostly done. We hope this will be a good foundation for other changes we want to make in future.
• mozilla::pkix is a bit stricter about parsing, and so we found a list of non-standard things CAs were doing that we’d like them to stop doing:

https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix

• This was mentioned in the May CA Communication. Thank you for all taking action to eliminate those practices. We don’t believe any CA present has outstanding issues in this area.

Mozilla 1. Revocation

We now have an agreed plan of record for our revocation strategy: https://wiki.mozilla.org/CA:RevocationPlan

This should not be a massive surprise to those who have attended previous CAB Forum meetings. To summarize, quoting from that document: “For CA certificates (that is, roots and subCA certificates), only, check a centralized list. For EE certificates, provide a collection of “fast path” options.

• Mozilla maintains central list of revocation information (called OneCRL), covering all intermediate certificates and a (initially small) subset of EE certificates. Comprehensive list of all CAs, and maybe some other individual SSL certs if needed.
• Ben: CAs required to disclose the list.
• In a May communications they were asked for intermediates. Asked for URLs to CRLs associated with all intermediates which will then be crawled. Will track and know which intermediates are revoked. Focused on invalid intermediates, not on inserting the known intermediates.
• OneCRL is pushed out to Firefox instances regularly
• For CA certificates, the only revocation checking done is to check the OneCRL
• For EE certificates, Firefox checks several revocation paths:
• OneCRL (if applicable) (just in case there are some EE certs on this list)

Short-lived certificates are exempted from revocation checking

• Stapled OCSP response (if present)
• OCSP must-staple (if present)

Live OCSP with hard-fail

Enabling hard-fail on live OCSP by default may not be achievable, and is a long-term goal in any case. We will proceed by implementing the fast-path options first, and measuring (1) how much they reduce live OCSP usage and (2) OCSP failure rates.”

The first version of OneCRL will require entire certificates; later versions will require only that information which is present in a CRL.

Questions for CAs:

• If we asked you to provide a set of URLs which together provided revocation information for all your non-EE certificates, could you do that? Basically the URL to Roots (unless there are 4 level hierarchies). Want the set of CAs that issue SSL certificates (not necessarily code signing or email):

• Chris: initial list is one thing, but CAs need to provide updates to that list as new CAs are created.

• Also need any cross-signed certs that fall into this category (Cross CAs that issue CA certs)

• Would all those URLs be URLs to CRLs, or would some of them be OCSP-based? (I.e. are there any intermediate certs for which you ‘’only’’ provide revocation info via OCSP?)

• Would you need some of that set of URLs to be secret (not public)? If so, why?

• Mozilla 2. Short-Lived Certs*

The option of using short-lived certs is part of our plans for the future of revocation. We want to write a ballot which updates the BRs to permit them, without revocation information.

We had a discussion in m.d.s. policy about what approach we should take to short-lived certs. Some points which came out of it:

• Expired short-lived certs should be treated with a stronger treatment (more like “revoked”) than normal expired certs. That is Mozilla’s basic approach – change the behavior.
• There may be an issue with clock skew; however, it’s not an issue for everyone and so we should not let it be a gating factor on permitting this.

Our research shows about 0.5% of users have clocks skewed by at least 1 day, although that population is of people needing a Firefox hotfix, so this probably skews towards older machines and less clued-in users. If we implemented short-lived certs, we might also implement some mechanism to keep Firefox aware of the real time even if the system clock was wrong, although of course that doesn’t solve all problems. This is just a possibility.

So, the big question is: what should we implement as the maximum lifetime of such short-lived certs? And should we tie it to maximum OCSP lifetimes, or have it float independently?

• We think the current max OCSP lifetime is too long anyway (10 days). We are thinking about something of the order of 3 days 1 hour – so CAs can issue with one day margin either side, and the site can use the cert for 24 hours. Issue a cert every 24 hours (and use it the 2nd 24 hour period and use it for one day, so you have a day before and a day after to support clock skew)

• There is work to be done to automate the protocol between the server and the CA.

• Should these have a special OID?

• How do you audit these? You will find certs that are not compliant (no revocation information) and the only hint they are short validity period certs is by computing the validity period. This implies that these certificates are subject to different audit rules.

• Mozilla 3. Key Pinning*

As noted in the last meeting, key pinning shipped in Firefox 32 for Mozilla and Twitter. https://blog.mozilla.org/security/2014/09/02/public-key-pinning/ It will ship in Firefox 33 for Google.

HPKP is targeted for implementation by the end of this month (September): https://bugzilla.mozilla.org/show_bug.cgi?id=787133 If it stays on track, it would ship in Firefox 35 in January 2015.

https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning/Implementation_Details has details of how our implementation works.

• Mozilla 4. Scope of SSL Cert*

mozilla::pkix now defines it as “id-kpServerAuth or no EKU” and we don’t seem to be having too many problems.

We hope to remove the “or no EKU” part for end-entity certs (some people are skeptical of this) – https://bugzilla.mozilla.org/show_bug.cgi?id=968817.

• The hope is that then other browsers will follow us, and that the scope of the CAB Forum’s work can be updated to make it clear what certs we are talking about.

• Ben: maybe CABF could put in a requirement and make this the rule for EE. And it would be good for this to also for intermediates.

• AnyEKU: is not implemented in Mozilla PKIX

• Gerv’s recommendation: For future CA generation: Suggest we start to require serverauth EKU and then eventually all CAs will have this and all others will have expired.

• Ryan: Recommended this at Mt. View meeting

• At the moment the rule is the same for CA and EE.

• Gerv: This may need more of a write-up to make things more clear.

• Mozilla 5. Baseline Requirements and Audits*

Kathleen has written a new document which makes clear some of our expectations regarding Baseline Requirements audits, and the disclosure of the results of the same: https://wiki.mozilla.org/CA:BaselineRequirements

A summary of the major points:

• BR audit results, including lists of any BR items with which the CA is not yet in compliance, must be public documents. If some matters are confidential, the CA needs to work with their auditor to produce a publishable document which meets our requirements but excludes the confidential information.
• All intermediate certs (not just a sample) need to be audited for RFC 5280 conformance. (for EE a sample is still acceptable)
• If you list all of the methods and you are using them, OK, even if some are “conditional”
• 11.1.7 want specificity on “any other method” so they can evaluate that.

Pass and “pass with items out of compliance”, they want enough info on the items which can be published and all to know, so it needs to be sanitized (by the WebTrust auditor).

• Robyn: We can’t necessarily ask for this.
• CAs might need to get a more sanitized report so that internal network topologies are not exposed from their auditors.
• Don said:
• Given a clean audit report, but Mozilla found a number of issues.
• Some of the issues found should have been caught.
• More info will be discussed later.
• What Mozilla is doing is good, a way to test the strength of the audit.
• Many of the things can’t be checked externally, so if some checks on externally verifiable info fail, there is concern about the things that the auditor did for the internal checks.

Do we need to audit 100% in WebTrust? Mozilla is asking for this, but it’s not currently in the audit criteria. Ryan also agrees that this should be the case.

• Clarify when a BR Publicly Trusted Internal RA is allowed or not allowed.
• Explains our policy about discovered audit mistakes and re-auditing. (If the auditor did not catch something, but the CA did later, they should fix the issue and then see if they should get a new auditor)
• CPs/CPSs must describe in detail how a CA verifies domain control; referencing BR section 11 is not enough.
• ’’’Action Item Gerv’’’: Reconcile the Mozilla requirement that CAs must not issue certificates with duplicate serial numbers with RFC 6961 for CT which requires duplicate serial numbers to be used.

CAs should review this document (and perhaps have their auditors do so also) in order to provide feedback to Kathleen. They need to be ready to make sure that their next BR audit matches our expectations.

If CAs feel that it would be good for the BRs and/or the ETSI and/or WebTrust audit criteria to be clarified in any of these areas, we would be happy to collaborate on that.

Mozilla 6. Baseline Requirements in Practice

Due to some excellent work by Mozilla volunteer Kurt Roeckx, we have been contacting CAs when scans of the Internet have revealed BR violations.

https://bugzilla.mozilla.org/show_bug.cgi?id=1029147 is our tracking bug for BR issues; its dependency list is a list of instances where CAs have issued certs which are not compliant with the BRs. Mozilla is in direct contact with those that have violations.

• Mozilla 7. SHA-1 Deprecation*

Issuing SHA-1 certs is now a Problematic Practice: https://wiki.mozilla.org/CA:Problematic_Practices#SHA-1_Certificates.

We observe Microsoft’s and Google’s strategies with interest, but are not planning any UI changes of our own at the moment. We may well implement code which refuses to accept SHA-1 certs which fall outside Microsoft’s parameters: https://bugzilla.mozilla.org/show_bug.cgi?id=942515

• You should certainly not expect any support in Firefox for SHA-1 beyond Microsoft’s deadline dates.

• Have not thought about private roots and if these rules apply to them

• If you have an enterprise use case you can see the environment variable so that they will be disable in NSS – code is not removed so you can enable useless algorithms. So, you can enable these (useless/insecure) algorithms

• We are currently lined up with Microsoft’s dates for the end of SHA-1 issuance and usage. Kathleen has said she currently doesn’t expect to do UI indicators before January 2016.

• Kathleen plans to do a security blog about this in the next few weeks.

• Mozilla 8. 1024-bit Root Removals*

https://blog.mozilla.org/security/2014/09/08/phasing-out-certificates-with-1024-bit-rsa-keys/ is our recent blog post on this topic.

We always planned 3 phases, although the first phase was delayed due to compatibility issues, which caused a delay in the remaining two phases. However, the first phase of removals is complete. There are two remaining phases:

Phase 1: Due for removal in Firefox 35, due for release on 6th January 2015.

Thawte (2), Verisign (1) and Equifax(1) – Symantec: https://bugzilla.mozilla.org/show_bug.cgi?id=986014

(we are embedding a cross-signed intermediate to help with transition)

GTE CyberTrust – Verizon: https://bugzilla.mozilla.org/show_bug.cgi?id=1047011

Phase 2: Due for removal in Firefox 37, due for release on 31st March 2015.

Equifax (2) – Symantec: https://bugzilla.mozilla.org/show_bug.cgi?id=986019

Thank you to the CAs who have been working hard to move their customers off 1024-bit roots.

These root changes are being noticed by folks using OpenSSL’s chain building, because OpenSSL does not check all certificate validation paths. For instance, a site that has two intermediates, one chaining to an older 1024-bit root, and one chaining to the newer root will cause OpenSSL problems when the 1024-bit root is no longer trusted, because OpenSSL will just try one intermediate, and fail if it’s the one that chained up to the 1024-bit root that is no longer trusted.

So, there is lots of secondary/tertiary fallout from applications that use the NSS root store but don’t build chains properly. Android apparently has this problem.

Mozilla and Google agree that it’s incumbent upon OpenSSL (and its users) to fix this, not Mozilla. It’s OpenSSL’s fault for not considering chains, and we will not let third-party uses of the Mozilla trust list hold back progress or security. In the mean time, people reliant on this software may have to use a trust list which diverges from ours.

We are also moving towards marking any chain which has anything less than 2048 in it as untrusted in the UI: https://bugzilla.mozilla.org/show_bug.cgi?id=1049740 This is on our list of future projects, but is not currently resourced, which means we have no solid timeline for implementation yet.

• Mozilla 9. salesforce.com*

We have a consultant working to move management of our CA data onto the salesforce.com platform. https://etherpad.mozilla.org/CA-Program-Automation has the gory details for those interested.

Goals for first phase of the project:

• Manage data about pending and included roots in one place (to avoid having to copy-paste between spreadsheets, word documents, wiki pages, etc.)

• Make CA program more transparent, exposing the data we have more clearly

• Automate the process of keeping audit statements current and possibly maintaining CRL URLs as discussed earlier.

• Mozilla 10. Next CA Communication*

We are hoping not to have to do another CA Communication until 2015, when salesforce.com will be ready to use to deal with the responses.

Some possible topics:

https://wiki.mozilla.org/CA:BaselineRequirements – request for feedback from CAs and auditors.

• 1024-bit certs – more info about when Untrusted Connection errors will start to be displayed for 1024-bit SSL certs.
• Additional information needed for OneCRL, whatever it is

For CAs who haven’t completed the action items for the May CA Communication, then we will aim to get updated status on those (with only a couple of exceptions, that does not refer to CAs who are at this meeting). See https://wiki.mozilla.org/CA:Communications#May_2014_Responses .

• More details on our plans and dates for phasing out SHA-1

• Use of salesforce.com for updating audit statements

• Mozilla: URLs from the Above*

• mozilla::pkix page: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing

• Revocation plan: https://wiki.mozilla.org/CA:RevocationPlan

• HPKP bug: https://bugzilla.mozilla.org/show_bug.cgi?id=787133

• Pinning implementation: https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning/Implementation_Details

• BR audit expectations: https://wiki.mozilla.org/CA:BaselineRequirements

• BR issues tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1029147

• SHA-1 cutoff bug: https://bugzilla.mozilla.org/show_bug.cgi?id=942515

• Security blog on 1024-bit roots: https://blog.mozilla.org/security/2014/09/08/phasing-out-certificates-with-1024-bit-rsa-keys/

• Remaining root removals:

Thawte (2), Verisign (1) and Equifax(1) – Symantec: https://bugzilla.mozilla.org/show_bug.cgi?id=986014

GTE CyberTrust – Verizon: https://bugzilla.mozilla.org/show_bug.cgi?id=1047011

Equifax (2) – Symantec: https://bugzilla.mozilla.org/show_bug.cgi?id=986019

• Bug on not trusting anything [ 2048 bits: <https://bugzilla.mozilla.org/show_bug.cgi?id=1049740]( 2048 bits: <https://bugzilla.mozilla.org/show_bug.cgi?id=1049740)

• CA program administration automation plan: https://etherpad.mozilla.org/CA-Program-Automation

• Mozilla: Questions:*

• Dean: Please describe the behavior of Firefox: Site that has an OV cert, shows run by “unknown”. What does “Run By” mean?

• Mozilla does not recognize the category of the OV cert (treat them as DV). EV gets one treatment and DV/OV get another. Some have argued “don’t say ‘run by’”, but in no case will we display the O field from OV certificates.

• Wording should be improved (or eliminated). Gerv said there were plans to improve the wording

Microsoft

(Prepared by Wayne)

Tom Albertson provided the following updates:

• Microsoft has suspended RSA 1024-bit root removals until they can implement ‘rapid removals’ that allow Microsoft to quickly roll back the change. Expect the ‘rapid removal’ fix to be released in Dec and work to remove 1024-bit roots to accelerate after that.
• Microsoft is not seeing any significant issues with SHA-2 support except for “legacy” clients (XP). Windows Server 2003 requires a documented update to support SHA-2.
• Microsoft will start requiring EV code signing criteria to issue Kernel Mode code signing certificates that work in the next version of Windows (“Windows 9”). Will begin transitioning CAs in March 2015 with target for go-live May 15, 2015.
• Dean – asked if this new policy has been documented. Tom – not yet.
• Iñigo asked if the Kernel Mode program will be open to more CAs. Tom said yes but he can’t guarantee it will accept all that apply.

Don – there exists WebTrust audit criteria for EV code signing.

• Tom – I don’t expect everyone will complete an EV code signing audit to before they start issuing EV code signing certificates based on the dates above.
• Wayne – will EV code signing be SHA-2 only, meaning that Microsoft will only enable SHA-2 roots? Tom – the new EV code signing program will be SHA-2 only. The patch to enable SHA-2 Kernel Mode support in Windows Vista and 7 is still planned but there is no further information on timing.
• Jeremy – what about User Mode code signing certificates? Tom – User Mode will continue to operate as it currently does
• Dean – are the baseline requirements for code singing still applicable? Tom – Yes, and we need to add new requirements in the baseline draft to the EV code signing requirements.
• Li-chun – Can ‘Digital Signature’ key usage still be used to sign code? Tom – Yes. Nothing already in place for User Mode code signing is being changed.

Google

1 – Certificate Transparency launches in January 2015. 2 logs are operational. 1 log is undergoing approval.

2 – SHA1 deprecation is moving forward

3 – Looking at entire certificate chain and eliminating less than RSA 2048-bit certificates. We do expect there will be problems for servers as this happens–so CAs should get ahead of the curve on this. Make sure your chains are end-to-end secure because they won’t be able to build chains. You cannot expect to rely on a new cross-certificate to solve the problem. Avoid the long tail.

4- Opera has been given the charge to look at technical means of enforcing compliance with the Baseline Requirements. They are programming checks for such things like serial numbers, validity periods, and Chrome will adopt these measures in the future.

5 – We are looking at data for Baseline Requirement violations, and audits that didn’t catch these. CAs should self-monitor to catch these problems before we do. Examples, negative serial numbers, failure to respond to OCSP requests. Acting upon information from Mozilla community.

6 – We are re-evaluating our CA review practices. Problems identified with a handful of nationally accredited auditors. The process controls and technical ability of some CAs to operate in compliance with Baseline Requirements is in question. Biggest concern is that auditors be able to identify potential problems with, and get CAs to fix them.

7 – Google migrating from NSS to Boring SSL as a fork of !OpenSSL. We will do something for certificate verification like Mozilla has done with Mozilla pkix.

8 – The UI team is exploring how URLs and information are provided to users- HTTP, HTTPS, SSL, and EV in the future. Our goal is to communicate meaningful security information to users–we want to help improve user awareness of danger.

9 – Chrome New General Principle – APIs with new and powerful capabilities must be done over TLS. The Web Apps Group of W3C WebCrypto API, HTTP2 (IETF), we’re involved with the security of web applications. JavaScript API (WebApps service worker API is a prime example of this movement. It controls network refresh, but it must have HTTP2 TLS 1.2, so more people will want certificates, and people do not want to have trouble getting certificates. You, as CAs, could help the public obtain and use TLS certificates.

10 – SHA1 – gradual measures vs. more immediate – we will degrade the UI for other similar problems, like the grades given out by SSL Labs

As part of move to Boring SSL we’re removing DSS and DSA–low use and additional security problems and untested public code base.

Android – Con-script provider will be auto-updated outside of the carrier’s control (but not roots), but the TLS stack, updating of crypto-services, protocols, ciphersuites, etc., will be easier for all modern phones (but not for Gingerbread, etc).

Google would like to see the overall security of TLS communications improve, so CAs only provide a minor part of that solution (there are other issues that need to be addressed as well).

Updates from CAs on Efforts to Reduce Prevalence of SHA1 Certificates

(Prepared by Rick)

Atilla first asked if the decision had been made to deprecate SHA-1 even for intermediate certificates. Gerv said that Mozilla hasn’t written any code yet to downgrade SHA-1, but he expects it would complain if an intermediate was signed with SHA-1. Ryan confirmed that as far as he knows, that’s the way mozilla::pkix (used in Firefox) works. What about if a cross-signed certificate is part of the chain? Even if it built a path with a cross-signed cert, mozilla:pkix won’t trust that path and will look for others.

Richard said that SHA-1 deprecation is a big problem in China, as there are still 3 million Chinese XP SP2 users that don’t have support for SHA-2. He doesn’t know how to deal with this. He said that all top websites and online banking sites in China use Symantec SHA-1 certs. Gerv suggested that XP SP2 users will have to install SP3, and he thinks that that can be done even if it’s an unlicensed version. Richard asked if he had to tell all 3 million users to upgrade; the consensus answer was yes. There seemed to be little sympathy for XP users, since Microsoft has removed support for it. Doug said that CAs can still issue SHA-1 certs for a little over a year. Gerv said that CAs could help by suggesting that their customers’ web sites could warn users if they are using old browsers on XP. He forwarded a link to some javascript (http://bytes.com/topic/javascript/answers/148245-detect-sp2-xp) that could be used. He said he didn’t want to hold Internet security hostage over these unsupported operating systems. Richard said we’re throwing these users away; Gerv countered that there are several paths forward, many of which cost nothing.

What about Taiwanese Internet users? Chungwa Telecom said that the government section had already changed to SHA-2, but elsewhere, SHA-2 adoption is ongoing. There are problems with old IIS servers. Li-Chun said that he would have to send customers both a SHA-1 and a SHA-2 cert. TWCA said they’re planning to migrate to SHA-2, but wanted to know if the UI decision was final. They said that they need this info to come up with migration plan. Atilla said that we know Google’s plan but what about Mozilla and Microsoft? Gerv said at the moment, they’re not planning UI changes before Jan 2016. Tom said he suggested UI changes 4 months ago before he left on personal leave; then Google announced their plans. Microsoft hasn’t decided on any UI changes yet, but they may put up an interstitial warning. If they see that the end-entity SSL certificate was issued after 2016/1/1, that will be blocked. Microsoft has no firm plan yet on other UI changes.

Ben said there are two sides to the story: what CAs can do about issuing, and getting the word out to clients. Is there a way to push this info to the customers of our customers? Gerv again suggested that CAs could develop some Javascript code to detect an XP SP2 client, and write up a document to show users how to use that code. It would have to be done by examining the useragent HTTP header value.

Atilla asked if it is possible for CAs to create a new SHA-2 intermediate CA signed by an existing trusted SHA-1 root? Tom said yes, absolutely. OK for Google and Mozilla? Yes. Atilla seemed to think that the new intermediate had to be added to browsers’ root stores, but Ryan and Gerv said no, their browsers don’t ship intermediate certificates. Root signatures aren’t checked. All that matters is that end-entity and intermediates are signed with SHA-2.

Bruce asked if those SHA-1 roots can still sign OCSP responses and CRLs with SHA-1? Microsoft doesn’t use CRLs anymore, but Tom said that SHA-1 roots would have to switch to signing OCSP Responses with SHA-2. When that happens, though, the OCSP responses won’t be usable by clients who don’t support SHA-2. That could cause problems in 2017.

Guideline review for CT implementation

Kirk explained the proposed ballot for revising the Baseline Requirements in order to avoid compliance issues related to implementation of Certificate Transparency. Proposed-BR-amendment-RFC5280 (pdf)

Discussion of CAA Records

(Prepared by Doug)

Rick Andrews gave his presentation on Current-State-of-CAA-Sep2014(pdf).

New Developments:

• Gerv found out that Akami CCARE does not support CAA records.
• Rick managed to convince ISC to add CAA support to their upcoming version of BIND: version 9.9.6

Rick presented the proposed text for Definition of CAA record and draft content of a ballot requiring all CAs to update their CPS to state how they process CAA records in the next 6 months.

Rick then reviewed the concerns from Google, Trend, Apple, Mozilla and others that he has collected. One of the general themes was the concern (or not) of how and what CAs communicate to their customers about updating their CAA records, or in doing it on behalf of their customers.

Next Steps:

• If CAA is being abused, it should come to the attention of the forum.
• If you don’t want to process CAA, say why in your CPS:
• We will disregard the values if we believe that this was updated for other CAs without full understanding of that customer, or if we believe the CAA record was added in bad faith
• It might take 3-8 days until the updated DNS record is propagated.
• Ben says we’re ready to go to ballot!
• Include Ryan’s change.
• And some other minor edits as recorded during the meeting.

Final observations:

• CAs can build it on their own (no browser support needed)
• It’s relatively simple for the customer and the CA
• Customers have to opt-in, so deployment is likely to be minimal for the next few years
• It’s not for everyone, but it gives some customers a useful tool
• It demonstrates our willingness to act to prevent mis-issuance

Review of draft Ballot 133 – Insurance for EV Issuers

(Prepared by Atilla)

Ben started to give a general info about insurance for SSL. For financial coverage, insurance has been used for centuries. It’s a way of risk management. If you can’t avoid the risks totally, then insurance becomes an option for transferring those risks.

The current language of the insurance provisions in the EV guidelines has been changed for making the insurance more applicable and meaningful. The draft ballot text is also improved according to the suggestions from Forum members.

An alternative method is introduced and a mitigation plan is given in the ballot text.

1. “Commercial General Liability” of 2 million USD will be changed to “Casualty Insurance” sufficient for the CA.

2. “Professional Liability/Errors and Omissions insurance”, with policy limits of at least five million US dollars in coverage will be changed to a “non-contractual liability coverage” of at least two million Euros (€2,000,000 per claim and in the aggregate) for financial loss to third parties arising out of a negligent act, error, or omission by the CA in issuing or maintaining EV certificates,

Don asked, what in the item (A) (1) the word “sufficient” means. Ben agreed about this ambiguity.

Chris said, the meaning of insurance is to normalize a CAs operations if any customer has big losses for the CA to cover.

Annabel said that a casualty insurance may be necessary for covering CAs liabilities.

Gerv said that if the beneficiary in the policy is the CA then it is the CA who will decide the scope of the insurance.

Moudrick said that in some countries there is a minimum requirement for insurance, under which a CA will fail to operate. If a CA ceases its operations, it cannot provide revocation info plus verification archives. That insurance should somehow cover these kinds of costs for continuing these critical operations.

Gerv and Ben commented on the Diginotar case. Insurance sometimes may not cover everything. So Diginotar case wasn’t solved by the insurance coverage. The subject of “gross ignorance” is not under insurance scope (?)

Atilla gave additional information about the starting point of insurance discussions within the CAB Forum. The primary target is reaching a meaningful and appropriate insurance requirement for the EV Guidelines that will be affordable and viable throughout the world.

It is said in China, SSL insurance is very expensive and normally insurance companies cannot offer insurance to the CAs.

Another question is the scope of the insurance, whether its coverage is global or not. Typically, the insurance companies out of Northern America (including European ones) offer insurances excluding USA and Canada.

Ben said, what can be a solution is, if you issue an SSL in a restricted territory, the scope of the insurance may be limited to that territory.

Gerv said that, on the other hand, the relying parties may be everywhere, not necessarily in the territory where the SSL is issued and used.

There was a discussion on the proper wording of the ballot for new insurance requirements. Ben gave a brief on insurance subject and why it is used. He also gave information about a new ISO standard about cyber-insurance.

Arno mentioned about the EU legislation and the national legislations where a CA mandatorily keeps sufficient financial resources or obtain appropriate liability insurance.

Atilla thanked Ben for drafting the insurance ballot and said that the current wording in the ballot text may be finalized according to this discussion, and concerning the scope in terms of territory, instead of global coverage, a limited territory covering the regions where the CA does business may be chosen in the insurance requirement as an agreeable cut of point.

Report from WebTrust and ETSI

(Reported by Kirk)

Don Sheeny presented an update on WebTrust issues. He said the WebTrust standards drafting committee had met and worked on responses to Mozilla’s questions on audit standards, how to deal with qualified audits and audit errors, etc., and had provided feedback that helped Mozilla develop its updated audit policy.

Don stated that WebTrust had completed audit guidelines for extended validation code signing certificates and the guidelines are available on the WebTrust website.

Don then noted that the Forum guidelines and requirements (EV Guidelines, Baseline Requirements, network security standards, etc.) leading to audit documents had started with “big” issues relevant to major security issues relating to Certification Authorities, but with the addition of more and more requirements, such as the recent CAA policy disclosure requirements, the potential scope of audit requirements was expanding to less major issues. He was concerned that audit requirements could be expanding to issues that perhaps would be handled better outside of the CA audit regime. There were no follow-up question from the Members..

Iñigo Barreira then presented an update on recent changes to ETSI standards and practices. He noted that at the last face to face meeting in Eilat the browsers asked a number of questions about ETSI policies, and he distributed a list of responses. See below.

CABF Questions & Answers – ETSI report from Iñigo Barreira

Answers to ETSI questions

The following answers provide best understanding of individual experts from ETSI but do not represent any definitive position of ETSI.

CABF-Questions-Answers-EU-regulations

Q1: When is ETSI ESI publishing the new ENs regarding policies? A plan for the publication and migration to the ETSI standards for the EU Regulation are given in draft document “ETSI / EA Recommendations regarding Preparation for Audit under EU Regulation (EU) No 910/2014 Article 20.1.” Draft versions of the ETSI policy requirements documents will be available for review and comment at the beginning of 2015.

Q2: When the schema of the auditing process is going to be ready in all countries? What about the new conformity assessment? How to change from a TS to a new EN? How the browsers should treat all these options? Where to get a list of the accredited auditors? How´s the maintenance of that list? It is aimed to have a conformity assessment scheme in place by Jul 2016 as outline in the migration document mentioned above. Until that date TS 102 042 may be used to assess conformance to the CAB Forum requirements under the rules proposed in the recent motion:

“The resulting section 17.6, bullet 4, would read as follows: 4. (For audits conducted in accordance with any one of the ETSI standards) accredited in accordance with what stated in Annex E of the ETSI TS 102 042 to provide proof of accreditation from, an accreditation body that is a members of EA or IAF, against the requirements of ISO/IEC 17021 or EN 45011 or ISO 17065 (ISO equivalent to EN 45011) or ISO 27006 / 27001.”

Guidance information is available on accredited auditors is available at:

http://portal.etsi.org/TBSiteMap/ESI/TrustServiceProviders.aspx

Q3: Up to now, and being 2 ENs currently published, should the browsers admit them? In which conditions? The 2 ENs published now, EN 319 411-2 and EN 319 411-3, are for CAs issuing qualified certificates and public key certificates, but none of those, mainly the second one, adopt the CABF documents, so are not of interest of the CABF at the moment.

Q4: What about the network security requirements? Are the CAs to be audited against the 319 401 plus the others? The requirements of EN 319 401 (which also include the CABF network security requirements) are incorporated by reference into EN 319 411-x. So CABF audits should be against EN 319 411-x, other requirements from CABF & 319 401 are incorporated in 319 411 audit. The network security requirements are also incorporated in ETSI TS 102 042 v 2.4.1 by reference.

Q5: About the ISO 27002 controls, does it mean that you don´t have to do an ISO audit? Can this be considered as a substitution? ISO 27002 controls are used only for guidance on how to meet the ETSI requirements for security management. There is no requirement to carry out any separate audits under the ETSI based audit scheme.

Q6: Regarding the TLs, if you´re a TSP which don´t have your CAs or your services in the TL in the country you operate for whatever reason, does it mean that you´re not qualified? If being in the TL means that you´re qualified? Which are the requirements to be included in a TL? It depends on the country you operate? Can you “change” the country if does not offer what you expect? How? Can you be in more than one TL? How to check the list of list? I would say that from a pan_EU (and global) viewpoint on qualified TSP are in the TL. Any others are against specific national requirements which are not aimed at use outside the country. The TL includes information about the type service provided, so those providing say “qualified web site certificates” should be easily identifiable.

For specific requirements under eIDAS regulation regarding qualified trust services and approval and use of TL, CABF members should read the regulation and the specific requirements of a particular country of their interest.

Answers to EU Regulation questions

It is recommended that if the CAB Forum has any specific questions regarding the regulation then this is addressed to the EU Commission. Some informal suggestions are provide below but no guarantees are provided regarding whether these are correct. Legal advice should be sought to obtain a more definitive answer.

Q1: Why WebTrust is not included? Where and how to find an ETSI auditor? Attention is drawn to Article 20.1 and Article 3(18) regarding the legal requirements for audit. See above regarding requirements and information on ETSI audits.

Q2: What about insurances in the EU for CAs? Attention is drawn to Article 13 regarding liability, and Article 24.2 c).

Q3: How to apply according to article 14 on international aspects? It is recommended that the CAB Forum raise this question to the EU commission for guidance.

Q4: Why the change from 3 years to 2 in the audit processes? For qualified TSPs it is required that the TSP be audited under the Article 20 requirements by July 2017, thereafter the 2 year requirement applies.

Q5: Requirements for QTSPs if none of the certificates the CABF is dealing with are not considered qualified, does this article 24 apply to them? No, but some of the requirements expressed in the regulation does affect to all kind of CAs.

Q6: What´s the difference between a qualified web site certificate of those managed by the CABF? Do you need to be a QTSP to issue these certificates? Are they going to be the EVs? The requirements for qualified web sites are specific to the regulation. However, ETSI standards (including those for qualified certificates for web sites) are based around the CAB Forum Baseline and EV requirements, thus making it easier for a TSP to meet the requirements of both the CAB Forum and the EU Regulation.

Q7: when do browsers have to “apply” the regulation? The regulation makes no direct regulatory requirements on web browsers. Most of the requirements of the regulation apply from July 2016. All TSPs, other than those “used exclusively within closed systems resulting from national law or from agreements between a defined set of participants” (Article 2.2) will be required to comply with the general requirements of the regulation It is up to the TSP whether it decides to offer qualified trust services.

Q8: when the new ENs entry in force and when the “old” TS have to be removed to be applied in the browsers root programs? Currently the EU Regulation makes no regulatory requirements on use of specific standards. See separate document on planned migration on how ETSI standards may be used to meet the requirements of the regulation.

Q9: from the browsers perspective and the CABF as an organization as well, how to know if an auditor and an audit are accredited? The national accreditation body should be contacted to identify “conformity assessment bodies” that have been accredited by that national body. Some further guidance is provided at: http://portal.etsi.org/TBSiteMap/ESI/TrustServiceProviders.aspx

Q10: If an auditing body ceases its activity or is no longer accredited, are there audits still valid? Contact your national accreditation body for guidance.

Q11: How to distinguish and treat the so called qualified certificates for web site authentication? No answer. Will see how the implementing act indicates.

Q12: Will they follow the CABF Baseline requirements?

• ETSI standards in this area are based around the CAB Forum baseline. Conformance to specific CAB Forum requirements (OV, DV, EV) will depend on the particular “certificate policy” options selected.

Q13: What is going to happen with the code signing certificates? I would see TSPs issuing code signing certificates may well come under the provisions of the regulation.

Q14: Will these follow the same rules the CABF specifies? It is aimed by ETSI to maintain alignment with the CAB Forum requirements, but compliance to future CAB Forum requirements, e.g. for code signing, will depend the impact of these new requirements on the objectives of ETSI members which includes alignment with EU regulations.

Iñigo discussed his responses, as well as additional questions that arose after the last meeting, and responded to additional questions from the group.

Iñigo then presented the following draft ballot to amend the Baseline requirements to establish a procedure on how to identify qualified auditors. The motion was endorsed by Moudrick Dadashov of SSC.

Reasons for proposed ballot

The CABF has asked ETSI a procedure on identifying qualified accredited auditors to perform ETSI audits in a way the members of the CABF can check easily if those audits are properly managed.

The proponents of this ballot believe that the proposed modification to this section is sufficiently trustworthy.

Confirmation of accreditation can be obtained through the relevant national accreditation body. ETSI will include on its web site information on what it believes are Audit bodies with the appropriate accreditations, however, this is not a formal statement and the relevant national accreditation body should be contact for formal confirmation. Information on accreditations is generally available of the web site of the national accreditation body. Also, it can be checked against the proper auditing body web site if they´re properly accredited.

• MOTION BEGINS-

Bullet 4 of section 17.6 of the Baseline Requirements document (Auditors qualifications) would be amended as follows:

Audit against TS 102 042:

The auditor must meet Annex E of the TS 102 042 to provide proof of accreditation from, an accreditation body that is a members of EA or IAF, against the requirements of ISO/IEC 17021 or EN 45011 or ISO 17065 (ISO equivalent to EN 45011) or ISO 27006 / 27001. . . . The resulting section 17.6, bullet 4, would read as follows:

4. (For audits conducted in accordance with any one of the ETSI standards) accredited in accordance with what stated in Annex E of the ETSI TS 102 042 to provide proof of accreditation from, an accreditation body that is a members of EA or IAF, against the requirements of ISO/IEC 17021 or EN 45011 or ISO 17065 (ISO equivalent to EN 45011) or ISO 27006 / 27001.

• MOTION ENDS-

Iñigo will continue to work on the draft ballot and will submit it for action by the Forum at a later date.

Status of the EIDAS Regulation

CAB_Forum-eIDAS-Fiedler-09-2014

Regulation 910/2014

• The purpose of this presentation is to show the basis behind the new eIDAS regulation.

• It´s been a long process and still years to complete.

• The concept behind eIDAS is to establish a whole framework for European single market. The main strategic goal is not to close the European market but open to the whole world and have a world market.

• A presentation on the complete workflow not only for web site authentication but about the complex eID schemes in all European countries, focused on e-transactions.

• For the last several years every country has had its own process for eIDs and the idea of the regulation is to create one regulation for all countries and not having every country with their own law on this, and to get the mutual recognition of all national eIDs.

eIDAS legal aspects

• – Art 114
• – Giving power to the EU commission à implementing acts

Mutual recognition

• – Countries are not forced to “join” but are forced to indicate how they have to “integrate” the eID system. Of course, all countries will do so
• – There are different levels of assurance: high, substantial and low
• – Depending on the level chosen, the provider has to offer a validation service, for free, for that level
• – There are more details on different articles about these issues
• There´s an indication on liability for different eID schemes. What will happen, for example, if there´s wrong information in the identification record?
• Supervision is a closed system which takes into account the data protection laws and is managed by mainly national supervision bodies.
• Another interesting thing is the Trust List that can be an alternative to the browser root programs or the OS providers. Adobe is using this TL within his AATL program.

General principals for TSPs

• – General liability for all type of TSPs, qualified and non qualified, art.13
• – Recognition of 3rd countries TSPs, Art 14.
• – Accessibility alternatives for person with disabilities, art.15
• Arno reviewed a presentation slide that provided detailed text regarding liability. Important is about sufficient resources for this and not indicating a specific amount of money. See slide on article 14, international aspects on “how to” for 3rd countries to “work” in the EU.

Role of the supervisory body

• – Every country has a supervisory body that must supervise all TSPs the same way as in every other country
• – They supervise the TSPs
• – they do not audit the TSPs

Obligations for TSPs

• – All TSPs have to report security breaches, probably to ENISA (to be arranged)
• – Conformity assessment for TSPs
• – Trusted Lists for qualified services
• – Trust mark for qualified services

eIDAS-electronic signatures and seals

• – It´s intended that the electronic signatures are for natural persons and seals are intended for legal persons. Long-term preservation of the information for signatures and seals
• Time stamps with legal effect, and that can be qualified Electronic registered delivery services was developed by ETSI years ago, but has had no legal recognition, now with the new regulation, it has that legal support. Qualified Web site authentication will follow the CABF Baseline Requirements.
• Arno reviewed a slide with the TSP conformity assessment model and explained how the TSPs, the conformity assessment body (CAB) and the national supervisory body work.

Final slide on timing implementation

• – Entry into force in September 2014
• – In 2 years has to be implemented by TSPs
• – In 2 more years for eIDs

Day 3 – Thursday, 18 September 2014

Review of Ballots (Ben)

(Prepared by Rick) Ben gave an updated on updates he made to open ballots in the last 24 hours.

SHA-1 deprecation (Ballot 118)

The ballot proposes changes to BR 9.4.1, but still no effective date. The question was asked if this applies to root CAs or cross-certificates (Tom needs to check on intermediates first). The last paragraph says that CAs shouldn’t issue SHA-1 with dates greater than 2017/1/1 because browsers are in the process of removing algorithm support. Chris asked if we should have a MUST NOT date after which CA’s must not issue SHA-1 certs? Doug said it wouldn’t be auditable because it will take a year or two to get into the audit regime. Ben said it wouldn’t look good; Tom said Microsoft’s policy is MUST NOT issue SHA-1 certs after 2016/1/1, so even if the BR says SHOULD NOT, it won’t matter. Chris asked if we should put a placeholder there that Tom can take back to his policy group. Ben suggests 2015/1/1. Doug needs to check with his engineering team as to when he could really comply. Tom repeated that his team wants to know which CAs can’t deal with November 10, 2014. Rick will provide clarified language on not removing the entire algorithm; just use in certain places.

EV Insurance (Ballot 133)

Ben said he removed the complexity of before and after dates; taking current language and making it easier. If anything, it’s more flexible than what’s currently there. He made the type of insurance more clear (commercial general liability or casualty). He’s open to suggestions on the amount; he is also willing to entertain a specific dollar amount. He will add Eerrors and Omissions to the types of insurance possible. Ben lowered the amount from 5 to 3 million USD for claims, and instead of saying claims for damages (too broad), he changed it to “pure financial loss”, something that can be measured. But Ben wondered if “pure financial loss” is too general. Moudrick suggested “direct damages”, and Ben accepted that. He took out “neglect”, since itwas moved to the front of the ballot. He also took out “unintentional breach of contract” to make it simpler. The peril needs to be in issuing or maintaining EV certificates. Ben took out the proprietary trademark or patent language; he said it was not essential. Browsers might care if someone sued the browser because of something the CA has done. He added “such insurance must not exclude coverage for PKI services, and must be maintained for all periods in which an EV cert is issued by the CA is still valid.” Tom asked for confirmation if the cert is sold to a real company, that’s not negligance. Richard suggested that this would be good for non-EV as well; Ben said we’d consider it later. Ben added language to include coverage for those territories where the CA provides EV certificates. He added language “good or better than Standard & Poors, Fitch, Moody’s, others, to eliminate “bad” insurance companies. Ben is saying a cyber policy isn’t required, but it’s a good idea. Someone asked for 500 million USD for self-insurers.

RFC 5280 proposal (Ballot 134)

Nothing changed, just assigned a ballot number

CAA (Ballot 125)

Ben changed (2) and (3) to say that the CA must log actions consistent with its processing practices. Chris asked if cached CAA info can be used for a subsequent issuance; Ryan suggested that’s not a good idea and it needs to be checked each time because the customer could change the values (the RFC says the CA must check before each cert is issued). Dean asked about managed enterprise accounts? Would the CA have to check for CAA at each enrollment time? Ryan suggested yes. Or we could add in our CPS that CAA isn’t checked for such accounts. Jeremy said changes could be covered by contract or other means.

ETSI auditor qualifications (Ballot 135)

Nothing changed, just assigned a ballot number

Discussion of Critical Extension to Technically Constrain SSL for Non-Browsers and Status of OCSP Stapling

Li-Chun Chen presented Suggestions about correcting of Documents of CA/Browser Forum (pdf).

Discuss Scope of CA/Browser Forum Work, Purpose, Bylaws, Project Lifecycle Revisions, Working Group Charters, Changes

(Prepared by Atilla)

Ben stated that the major criticism about bylaws is if you don’t revise them frequently, then they become outdated. There should be a procedure for updating the bylaws. He mentioned about Moudrick and other people who had suggestions about bylaws. There is ongoing discussion about the formation and maintenance of working groups for instance.

Jeremy said, for bigger documents etc. there should be a working group but for smaller ones, working groups don’t seem necessary.

Ryan commented on the subject and mentioned how long it could take sometimes for working groups to end up with a solid result. Many of the browsers are also involved in other areas and studies. Regarding CABF activities, they are focused on SSL/TLS mainly, and they contributed in BRs and EV Guidelines. Bylaws and IPRs are agreed on. So, for a limited and defined scope, CABF studies can be performed more efficiently, from Google’s point of view.

Ben said that, Apple and Opera are almost out of CABF studies, and there are CAs who do not contribute to CABF activities, attend the meetings etc. So, there is the need for a new blood to keep moving.

Gerv said, browsers are freer to do what they decide to. However, CAs don’t have much choice.

Bruce commented that while each of the browsers may have a different systems and sets of policies–policies on SSL, and code signing, certificate transparency, and other subjects like S/MIME and so forth, he sees great value in having a forum where CAs and browsers can work on the explanations of the policies so that CAs understand them and subscribers understand them. So it makes sense that we work SSL, code signing, S/MIME, timestamping, so that everyone is on board for consistency, unless one browser has a system or policy that only it uses.

Ryan said they are also working on these issues. Also they are working on code signing. But they see these points not related to browser issues so out of scope of CABF.

Ben suggested that “abstention” may be a nice tool to use if they feel they are not interested.

Ryan said their legal team do not support this kind of a participation.

Gerv said that you cannot resign from the Forum on just one issue.

Ryan said for code signing issue, there would be the need for other parties like software platforms, application developers to participate in the work, but they don’t want to involve these parties and increase the scope of the Forum.

Ben and Ryan discussed that code signing issues may be dealt with totally separately and this may be done by an appropriate IPR change.

Chris asked if Google does not want to get into a working group study, what would be the appropriate means for that. Kirk also commented on the subject based on the current bylaws text. For the issues including code signing, the right place for seeking solutions would again be the CABF he thinks.

Ryan said, it still can be carried out separately, under other platforms such as IETF (instead of forming another organization for discussing these subjects).

Robin said it wasn’t the question of IPR. He said it is already difficult for people to gather together and find solutions for common problems. Some really are not interested in some subjects. But he said, most of the parties in the CABF are interested in discussing code signing issues so it should be discussed somehow.

A kind of umbrella organization is also discussed like “CA/Something Forum” where different subjects may be dealt with under different subdivisions.

The subject will be elaborated further…

Comparison of Trust Anchor Embedding Programs

Atilla presented the attached Comparison-of-Trust-Anchor-Embedding-Programs (pdf).

Bugzilla System

(Prepared by Bruce)

New online system where bugs or open items can be filed for the website, wiki or any of the documents. Bugs can be provided by anybody (i.e. the public); this will be monitored and may change id there is abuse. Will need to decide who will monitor the bug list. We may need to get a lead for each section. The new bugs could then be discussed at the bi-weekly meetings.

Gerv will get a change made to allow users to subscribe to the bug list a different levels.

Future Improvements to the Implementation of SSL/TLS

Working with Browsers on Initiatives such as SHA-1 Deprecation

• Ben – some CAs expressed concern that Google should have been working through the CABF on SHA-1 deprecation
• Gerv – has their plan changed a bit? Ben – yes
• Ben – Google felt going through the forum was futile

Gerv – lesson I’ve learned: wise CA invests time & energy into helping their customers be able to quickly and easily update certs. Seems like this will continue after Heartbleed and now SHA-1.

• Rick – Agree, but can’t make the process automatic because there are side effects. What would really help is if there was support in Web servers to deliver two certs simultaneously.
• Chris Bailey – great idea. We should bring this up with server vendors. Another idea would be to have a framework that we use for this with set timeframes. That way we don’t have as much wrangling over each item.
• Gerv – has Symantec ever pondered hiring an Apache developer to automate certificate update process?
• Rick – haven’t seriously considered this because you have to convince the community to accept your code.
• Robin – the basic process of installing a certificate first needs to be fixed
• Gerv – you’d have to develop an open protocol to enable this
• Wayne – there are patents on this type of process that need to be considered
• Robin – Comodo has some plug-ins for this
• Doug – just buy Venafi
• Wayne – even though it’s frustrating, there would have been value in more debate in the forum
• Kirk – was unhappy about the way CT was imposed as well. Would like to feel that our input had been solicited and heard
• Rick – a draft policy for CT was sent out and only Symantec responded

Jeremy – DigiCert responded privately

• Rick – no one responded to his comments until he asked and then every point was dismissed

Overview of Information Sharing to Combat Security Threats – Why and How do We Share Information?

Information Sharing Among CAs (prepared by Wayne)

• Ben – This is a continuing effort to improve how we share information

• One example of why we share information is that prior to revelation of the DigiNotar attack, messages had been sent between a few CAs about attacks from specific IPs. Attackers share information, and so should we.

• We should share because it’s a global environment and we have a common enemy.

• When we do share, we get the opportunity to compare and correlate data.

• This allows us to have a collective response to problems and threats.

• Gerv – isn’t this what the CA Security Council (CASC) is for?

• Dean – Not exactly. The CASC is only 7 CAs, and it is more about sharing information with the public

• Chris – isn’t there a liability issue we need to be concerned about?

• Kirk – probably okay if we just publish a list without specifying what it means

• Jeremy – it’s okay if you don’t require it (i.e. we make it voluntary)

• Annabel – Trustwave has this type of info sharing with law enforcement, especially on the payment card side. She can help to get us in touch with their group.

• Dean – do we need an information sharing working group?

• Chris – yes

• Ben – We could also allow members to post anonymously to some site that we authenticate to, to avoid potential libel issues, but then we would have a difficult time identifying the other CA if we wanted to follow up.

• Chris – could just be an anonymous list of IP addresses or FQDNs

• Annabel – Governments appreciate this type of collaborative information sharing

• Robin – Antivirus vendors don’t seem too worried about publishing lists of malware. Information needs to be really specific, or else it’s much less useful

• Ben – It also needs to be integrated into our approval systems through APIs

• Gerv – this would be a CA group, right? And you’ll need exactly the right people in your organizations to be plugged into this data.

• Dean – is there an appetite to form a working group? If so, we’ll need a ballot

• Chris volunteered Kirk to write up the ballot for the “CA Information Sharing” working group, Robin and Ben will provide any drafting or assistance in forming the working group.

Identity Vetting Remotely via Audio/Visual System, CABF Centre Database for Malware Signing Risk Database

Richard gave a presentation that covered a CABF Centre Blacklist Database for Malware Signing and EV Identity Vetting Remotely via Visual System: Remote-ID-Vetting-and-CABF-Malware-Database (pdf).

Presentation of Vice Chair Candidates

In lieu of presentations, the candidates for Vice Chair sent written statements about their positions and qualifications to the email list.

360 Browser Presentation

Hanrui gave a short presentation providing an overview of the 360 Browser.

Short-lived Certificates

(Prepared by Doug)

Gerv lead a discussion of short-lived certificates:

• Need to plan for revocation
• OCSP Stapling is more appropriate for sites that want to optimize user experience
• Should experiment with short-lived certificates.
• This is much less attractive to sites and CAs(infrastructure) unless there is a benefit to CAs.
• If we remove AIA then we remove the overhead and costs associated with that service.
• The only way they will gain attraction is to support no side-lookups (for cert status)
• Want BR to exempt AIA and CDP in SSL certs when the validity period of certificates has a validity period of less than X days/hours
• Discussed Clock skew, which is a driving factor in the recommended approach (3 days and 1 hour validity period)
• Mozilla might upgrade the UI for expired certificates for something worse if short-lived certificates are adopted
• Kirk said that this is not as good as OCSP as far as time to revoke.
• Are the risk profiles the same between these two approaches?
• Browses are driving speed and put revocation checking as a second priority (or even saying revocation is rubbish)
• Some CAs put certificate start dates as GMT with hour 0:00m which might impact proposed validity periods
• You cannot/should not, pre-generate a bunch of certificates and send them out ahead of time. They need to be generated at the time they are needed, or you will need AIA and revocation info.

Gerv will write this up and send out on the lists for further discussion.

Adjourned

The group then adjourned…