Home » All CA/Browser Forum Posts » Minutes of the F2F 45 Meeting in Shanghai, China, 17-18 October 2018

Minutes of the F2F 45 Meeting in Shanghai, China, 17-18 October 2018

Day One – 17 October 2018

Attendees on October 17, 2018: Iñigo Barreira, 360; Richard Wang, 360 Group; Billy Qin, 360 Group; Danny Wu, 360 Group; Clemens Wanko, ACAB’c; Phillipe Bouchet, ACAB’c; Trevoli Ponds-White, Amazon Trust Services; Xiaosi Li, Amazon Trust Services; Geoff Keating, Apple; Paul Yang, BaishanCloud / OpenSSL; Franck Leroy, Certinomis (Docapost); Aleksandra Kapinos, Certum; Wojciech Trapczyński, Certum; Yi Zhang, CFCA; Jonathan Sun, CFCA; Ivy Xu, CFCA; J.P. Hamilton, Cisco; Jos Purvis, Cisco; Robin Alden, Comodo CA; Tony K.F. Chan, Deloitte China (Beijing); Jesse Yun He Wang, Deloitte China (Beijing); Putzy De Wei Lu, Deloitte China (Beijing); Peter Koo, Deloitte China (Hong Kong); Ben Wilson, DigiCert; Tim Hollebeek, DigiCert; Arno Fiedler, D-TRUST; Enrico Entschew, D-TRUST; Vijayakumar (Vijay) Manjunatha, eMudhra Technologies Limited; Kirk Hall, Entrust Datacard; Bruce Morton, Entrust Datacard; Chris Bailey, Entrust Datacard; Ken Myers, Federal PKI; Wei Yicai, GDCA; Zhang Yongqiang, GDCA; Wang Chunlan, GDCA; Xiu Lei, GDCA; Atsushi Inaba, GlobalSign; Doug Beattie, GlobalSign; Daymion Reynolds, GoDaddy; Adam Sink, GoDaddy; Devon O’Brien, Google; Ryan Sleevi, Google; Ryan Hurst, Google; Dimitris Zacharopoulos, HARICA; Xu Jiang 徐江, Huace Network Security Cert. Auth.; Zhang Yong, Huace Network Security Cert. Auth.; Rachel Gao, Huace Network Security Cert. Auth.; Mike Reilly, Microsoft; Gordon Bock, Microsoft; Wayne Thayer, Mozilla; Tomasz Nowak, Opera; Albert L. Lam, PwC; Freeman Guo, PwC; Tadahiko Ito, SECOM; Cui Jiuqiang, SHECA; Dai Yeqi, SHECA; William Luo, ShenZhen Digital Certificate Authority Center Co., Ltd; Zheng Huitao, ShenZhen Digital Certificate Authority Center Co., Ltd; Fotis Loukos, SSL.com; Leo Grove, SSL.com; Matthias Bartholdi, SwissSign; Edwin Zhai, TrustAsia Technologies, Inc.; Jack Zhang, TrustAsia Technologies, Inc.; Frank Corday, Trustwave; Jeff Ward, WebTrust/BDO; Don Sheehy, WebTrust/CPA Canada.

Call to Order – CA/Browser Forum Plenary Meeting

Read Antitrust Statement

The Antitrust Statement was read.

1. Approval of CABF Minutes from Oct. 4 call (emailed Oct. 5)

Presenter: Kirk Hall, Entrust Datacard
Notetaker: Kirk.
The draft Minutes were approved, and will be posted to the Public list.

2. Report from Forum Infrastructure Working Group

Presenter: Jos Purvis, Cisco
Notetaker: Robin
The first item discussed by the Forum Infrastructure Working Group was website content management. The website is going to be reconfigured to add sections for each of the working groups. The chair of each working group is going to be responsible for maintaining their own content. The sections will be divided to indicate subcommittees of working groups. We will be adding minutes and ballots for each of the working groups. The second item discussed was the wiki. We have an offer from Microsoft to test out SharePoint. We also have a couple of open-source, self-hosted options we can test, so the idea was to test the options. When we have something set up, we’ll migrate over a little bit of data and test and then make a recommendation to the Forum as a whole. The third item was document management. We felt there were several different problems. One was identifying the canonical version of the Baseline Requirements. The EV Guidelines and the Network Security document already have defined GitHub as the canonical version. We discussed how to improve the document management workflow for ballots. Tim volunteered to put together a set of instructions on how to get a ballot from idea into GitHub and to the Forum vote. Hopefully in working on the process we’ll identify where we have problems, such as identifying the canonical version of the Baseline Requirements. We discussed whether to use GitHub or Word, but before deciding on a process, we felt that we needed to identify the canonical version first. We also decided that we need to identify the what – “I need a red-line version, I don’t care what format it’s in”, etc.

3. Report on Governance Change, Bylaws Issues: (1) Governance WG or Subcommittee, (2) Review Bylaws Change List

Presenter: Jos Purvis, Cisco
Notetaker: Bruce
Allow the formation of a Bylaws Subcommittee Ben pointed out that the work of the Forum was compartmentalized into working groups in order to section off IPR scope. In keeping with that, using a Working Group for Governance seems the only way to go. Others agreed after some discussion that IPR is bound at the Working Group level, so there’s minimal IPR coverage for work done purely at the Forum level. This is one objection to subcommittees at the Forum level: that there is minimal IPR coverage for their work, which could expose IP conflicts. The group then discussed whether a sub-committee or a Working Group was the right model for this. The concern with a Working Group was two-fold: the additional overhead from the establishment and operation of a Working Group, and the concern with pushing work on Forum-wide issues of the Forum-level Bylaws to a Working Group operating as a peer of the other WGs. There was some debate over whether the Bylaws permit for subcommittees at the Forum level; the result of the discussion was that work would begin on a ballot to clarify the Bylaws to permit subcommittees with specific requirements. Wayne pointed out that if people felt strongly that this work should be done at the Forum level, there wasn’t anything in the Bylaws to prevent the Forum itself from holding a Forum meeting specifically to work on the problem. After some discussion, there was agreement that it was permissible to hold a Forum meeting to tackle specific issues like Governance questions, so long as it was an official Forum meeting with all the usual trappings (agenda, schedule, minutes). This was the suggestion to tackle these problems immediately while working out the subcommittee issue with the Bylaws. Establishment of Subcommittees Discussion then turned to subcommittees themselves. Dimitris asked what to use as the model for subcommittees, and whether to enact these rules at the Forum or the Working Group level. The group agreed that it was important to spell out the rules for how Working Groups and Subcommittees were required to function, and that the charter of the SCWG had taken place without fully spelling out those rules, which led to the current conflict. The group agreed that it was important to spell out the minimum requirements for the establishment and operation of a subcommittee as a general requirement, with a focus on transparency and general rules rather than being overly prescriptive. Tim pointed out that we had a good working model for this with the previous model for what we used to call Working Groups (e.g. the Validation Working Group), we just didn’t enforce them properly which led to some WGs being better than others about producing things like minutes. The group agreed after some discussion that the minimum requirements for a subcommittee was the combination of a public mailing list for discussions and minutes for any meetings held, with those to be consistently and firmly enforced. A remaining concern was whether to institute those requirements at the Forum level or to make them at the SCWG level first. Ryan suggested that we focus our efforts on the work-output-producing groups first, which meant the subcommittees of the SCWG, and then consider propagating those requirements upwards into the Forum. Conflicts in Forum and WG Rules Finally, Dimitris raised the question of whether the Forum rules take precedence over conflicting rules from the WG charters. Ryan pointed out there are two questions here: one of conflicting rules, and one of lack of guidance. The group agreed that conflicts in WG charters should be avoided by more careful reviews of charters while establishing them; Ryan added that a more specific list of requirements would improve this (e.g. ‘must specify voting structure’, ‘must specify mailing list requirements’, etc.). Tim indicated that a major problem with the Bylaws was a lack of guidance over what rules applied only to the Forum, what rules also were required to apply to Working Groups or Subcommittees no matter what, and which rules were required to apply to WGs if they didn’t specify anything else. That is, which rules descended to WGs and which ones of those could the WG decide to override in their charter. The group agreed that the resolution to this was to review and revise the Bylaws to add statements like “Working Groups must do X” vs. “Working Groups must do X unless otherwise specified in the WG charter”. We know the SCWG has this issue with the Bylaws already, so everyone felt the group as a whole could begin tackling the Bylaws for review immediately, without needing to wait on the resolution of the Governance committee issue.

4. Potential Amendments to SCWG Charter

Presenter: Tim Hollebeek, DigiCert
Notetaker: Dimitris
This topic was covered by the previous (slot #3) discussion. There was consensus that the current SCWG Charter should be amended to reflect the changes that we would like to see in a CWG template. This review needs to take place along with the review of the Bylaws.

5. Creation of additional Working Groups – Code Signing

Presenter: Ben Wilson, DigiCert
Notetaker: Arno
Tim had sent the draft charter on 24.04.2018 to the Mailinglist. Previously there were a set of CS guidelines developed, but not adopted by the Forum. Governance reform gives the ability to create a new, chartered working group. Ryan S – Regarding scope, it would be good to identify the work in detail and then define the working group. Discussion followed on who should participate in a working group and what user agents would be involved.

6. Creation of additional Working Groups – Secure Mail; Other

Presenter: Ben Wilson, DigiCert
Notetaker: Kenneth Myers, Protiviti supporting the US Federal PKI
A Secure Email Working Group was first brought up at the London meeting. We understand the multiple types of email clients and the differing types of certificates. It might be a good idea to have it scoped toward a specific application such as a desktop mail client vs a web-based mail client.

Ryan Sleevi, Google – This has the same pitfalls as the code signing discussion. Secure Mail can also be regionally specific such as a Euro profile based on specific crypto algorithms and extensions. There could be multiple owners of a Secure Email certificate private key such as a person, an organization, or even an application. What is the most pressing issue with Secure Email and I would suggest focus on that. Maybe start with a certificate profile as a first work product and then work on a baseline requirement after that. In addition to specific EKUs and key sizes, what should be the identity validation properties?. In an enterprise RA model, maybe the user doesn’t manage or protect their private key and they are stored in a cloud or a multi-tenant environment.
Ben – Let’s hear from some of the Euro CAs and browsers who have email trust bit enabled for their perspective.
Tim Hollebeek, DigiCert – One item of clean-up could be to look at certificates that currently assert email and then create a BR based on those.
Wayne Thayer, Mozilla – We are interested in email validation requirements.
– We suggest maybe an approach similar to Adobe with integration and recognition of QC signing certificates.
Ben – Do we want to carve out desktop from web email to narrow the scope?
Ryan – The initial scope is the minimum set of requirements to meet the current challenge. If the current challenge is standardization of email certificates, start with that. Then you can move onto identity validation, private key protection, secure email validation, etc. We can get to an end state with all these pieces, but I suggest a solid foundation based on a profile to start.
Ben – It sounds like the initial charter should focus on three aspects: profile, identity validation of email and identity (host and local part), and private key protection.
Kirk Hall, Entrust – Is that enough to start drafting a charter?
Ben – Yes, I can start a charter based on those three principles.
Geoff Keating, Apple – Maybe start a CA Certificate working group?
Ryan – We talked about this at London also. Start with a limited number of working groups, find the commonality between the groups and then work on common certificate profiles. Instead of focusing on different CA conditions such as CA = True and EKU = SMIME which may lead to having separate roots which I think no one is interested in doing.
Wayne – Is your interest in a CA Cert working group, based on a problem or a notion from the governance reform?
Geoff – It is based on governance reform. For example, if we find OCSP may be a requirement of one CA type and not another it may have to go through multiple working groups and what if it fails in one and not another.
Dimitris Zacharopoulos, HARICA – This came up during the Network Security Subcommittee discussion and we anticipate this happening as more working groups are established. It is better to approach the issue when it comes up rather in theoretical.
Tim – A working group could simply be a mailing list and a charter with no document management.
Ryan – IETF ran into this problem where they had multiple groups with no products and caused confusion when trying to update or create a new document because of the overlapping scopes.
Kirk – Geoff, if you are interested in a CA Certificate Working group, please draft a charter for the group to discuss.

Call to Order – Server Certificate Working Group Plenary Meeting

Read Antitrust Statement

The Antitrust Statement was read.

7. Approval of SCWG Minutes from Oct. 4 call (emailed Oct. 5)

Presenter: Kirk Hall, Entrust Datacard
Notetaker: Kirk.
The draft Minutes were approved, and will be posted to the Public list.

8. Opera Root Program Update

Presenter: Tomasz Nowak, Opera
Notetaker: Doug

CAB Forum 2018-10-17 Opera Root Program Update Download

9. Mozilla Root Program Update

Presenter: Wayne Thayer, Mozilla
Notetaker: Jos Purvis, Cisco
The following is the update from Mozilla provided by Wayne Thayer; annotations based on the discussion at the Forum are indicated in italics here.

CA Communication We have received the responses to our September 2018 CA Communications. Thank you!

I am concerned with the response we’ve received from a number of CAs on question #2 regarding CP/CPS compliance with our policies. A few CAs stated that their CPS would not comply until Q1 of 2019, and many more gave dates in Q4 of this year. This is in spite of my statement at the London meeting that 6 months is not a “reasonable amount of time” to require to make changes to a CP/CPS. Should we really wait up to a year for CP/CPS updates to reflect policy changes?
Shortly after the deadline for the survey, it was pointed out that a number of CAs had stated that they comply with Mozilla’s intermediate disclosure policy when in fact they had current disclosure violations. This obviously affects the confidence we have in those CAs, but it also has led us to consider a policy of immediately adding undisclosed unconstrained intermediate CA certificates to OneCRL and/or enforcing disclosure via Intermediate Preloading.

CCADB News Note from Kathleen: I am 2 months behind on reviewing CA comments/additions to their root inclusion/update request bugs. If you updated your CA’s bug prior to August 15, and no one has responded to your update, then please send email to Kathleen. Otherwise, please be patient. Current Root Store Members of CCADB: Mozilla, Microsoft, Google, Cisco, Apple.The current Audit Case workflow is described here: https://ccadb.org/cas/updates#audit-case-workflow The most significant changes is that the CA should click on the ‘Audit Letter Validation (ALV)’ button, and work with their auditor to resolve all problems. After ALV is run, the Audit Case gets automatically assigned to a Root Store Operator for review and final processing.

For Audit Cases with roots in Mozilla’s program, it gets assigned to Kathleen.
Otherwise it gets assigned to Karina (Microsoft).
If Kathleen has an Audit Case with unresolved problems that only impact Microsoft, then she assigns it to Karina. (e.g. Code Signing audit problems, or if there are problems with the audits for roots that are not in Mozilla’s program)

Kathleen is redesigning Root Inclusion Case objects, so that Root Inclusion Cases will look and function as much like Audit Cases as possible. This will enable CAs to directly input/update their own root inclusion request data, and the Root Store Members will be able to independently make decisions on common data.

The Salesforce customizations are being migrated to Production this week.
Kathleen will use the new Root Inclusion Case functionality for a while before opening it up to CAs.
Send email to Kathleen if you have an upcoming root inclusion request, and would be willing and able to try out the new tools.
Everyone else should continue to use Bugzilla for now.
We plan to continue sharing information about root inclusion requests via Bugzilla, even after we’ve switched to the new tools, because we do not want to limit the manner in which the community at large contributes to the root inclusion process. We plan to create tools/integration to help share the info in Bugzilla.

CRLite and CT Policy As described in London, Mozilla is implementing an alternative revocation checking mechanism called CRLite. CRLite will speed up revocation checking and reduce CA cost by replacing most OCSP queries. Implementation has gone a bit slower than anticipated, but we are now making good progress and we anticipate beginning to test CRLite for a subset of CAs in our root program before the end of the year. CRLite requires that Firefox know about all certificates that may be encountered. We know that some CAs allow Subscribers to choose not to log specific certificates, so we are making plans to account for unlogged certificates. A final decision has not been made, but it now appears likely that Mozilla will implement a CT logging policy and require SCTs to be delivered with certificates. If no valid SCTs are presented during the TLS handshake, then Firefox may reject the certificate or fall back to OCSP checking. Wayne was asked how nondisclosures will work; he responded that the expectation is that if a cert is not logged, it will violate CT policy and fail closed; certs that are logged will work fine. A second question asked how will this work with the logging policy if both CA and user decided not to log. Wayne responded that if there is no SCT presented with the cert, Mozilla will fall to OCSP instead of CRLite; Mozilla would continue soft-fail on OCSP that it has today. When asked if this was a stepping stone to hard-fail, Wayne replied that Mozilla hasn’t gotten that far, and that generally Mozilla won’t fall back to OCSP except in the case of a technically-constrained ICA or enterprise policy. Intermediate Preloading As we announced in London, Mozilla is doing work to cache disclosed intermediate CA certificates on the client. Initially, this will simply serve as an alternative to AIA fetching for misconfigured websites. Eventually, it may be used to enforce the disclosure of unconstrained intermediate CA certificates. We’re currently targeting this work for Firefox 65, due for release at the end of January 2019. In our September survey, a CA asked about technically constrained intermediates that are not required to be disclosed. If Firefox encounters a misconfigured website that does not send an undisclosed technically constrained intermediate certificate during the handshake, then the connection will fail just as it does today. In the future, if we enforce disclosure using this mechanism, we will exclude technically constrained intermediates. Separate Intermediate Usages Section 5.3 of the Mozilla Root Store Policy now requires all new intermediate CA certificates created after 1-January 2019 to contain an EKU extension that does not contain anyPolicy or both serverAuth and emailProtection. This means that CAs will need to create separate intermediate certificates for signing S/MIME and TLS certificates. This policy is not retroactive to existing intermediate CA certificates. EV OIDs Mozilla has been encouraging CAs to use the CAB Forum EV OID for any newly EV-enabled roots. Unfortunately, this can cause problems in Firefox when other roots use a CA-specific OID and that OID is included in certificates issued under the newly EV-enabled roots. This issue is way too complicated to describe here, so please keep an eye out for more information on the mozilla.dev.security.policy list, or if you are concerned, ask me about it. Wayne was asked if the Forum could discuss this issue more at a later date within the Server Certificate Working Group: he replied that he’d be happy to. One CA asked if there was a problem with including both a CA-specific OID and the CABF EV OID; Wayne responded that there’s not a problem with that, but that it can have unintended consequences, and CAs that do so should check with him directly about it for more details. Enforcing commonName Deprecation Firefox Night has for some time been configured to ignore the commonName field in TLS certificates. In London I said that this would likely ship in Firefox 62 or 63. However, we’re currently targeting Firefox 65, scheduled to release in January, for the final deprecation of the commonName field via Bug 1432181. I don’t expect to see any breakage from this change. Symantec Update Mozilla has enabled the “full” Symantec distrust in Firefox 63 Nightly. Due to the significant impact we’ve measured, we delayed the uplift to Beta until Firefox 64 which ships on 23-October. We plan to enable the distrust for all Firefox users no later (and possibly sooner) than 12-December when Firefox 64 is expected to be released. A member asked what was meant by “significant impact”. Wayne pulled up the summary statistics chart of Symantec certificate use observed by Mozilla, which shows that Symantec cert usage is down to 1% and mostly in systems not used for browser use cases. No Stipulation in CPS Kathleen recently began a discussion on the mozilla.dev.security.policy list about the use of “No stipulation” in sections of a CP or CPS. It appears that the term is sometimes being used to mean that the CA does not do whatever is covered by that section of the document, but that is not what the term means. Mozilla interprets the term to mean “the CA has placed no limits on what it can do”, so we are concerned by its use, especially in sections where we want to know exactly what a CA’s policies are. Kathleen has added a section to our Required Practices that requires CAs to include all sections defined in RFC 3647 in their CP/CPS and forbids the use of the term “no stipulation” in any section other than those BR sections that state “no stipulation”, “not applicable”, or are blank. If you have any concerns, please join in the discussion on the mailing list. A member pointed out that RFC3647 contains guidance on the use of the term ‘No Stipulation’ that matches Wayne’s request here.

10. Microsoft Root Program Update

Presenter: Mike Reilly, Microsoft
Notetaker: Tim

Microsoft_CABF_45_Update Download

11. International Adoption of Chinese Cryptography Algorithms – Implementation and Standardization Progress

Presenter: Paul Yang, BaishanCloud / Open SSL

CABTalks Download

12. Introduction and Expectations for Standards and Restrictions for Browsers and Government Websites in China

Presenter: Quan Liu, China Electronic Authorization Industry Alliance

Browser-Support-for-SM2 Download

13. Google Root Program Update

Presenter: Devon O’Brien, Google
Notetaker: Trevoli Ponds-White, Amazon Trust Services
Chrome Security UI – Chrome 70 – will add a Danger icon to HTTP pages Chrome 70 stable will roll out full Symantec distrust over the next few weeks Chrome will deprecate TLS 1.0 and 1.1 in early 2020 Google intentionally hasn’t made any changes to the policy immediately following the rollout. However, they are now looking at some potential upcoming changes such as:

Limiting the number of CT logs per operator
Enforce time sharding for CT logs
Improvements to clarity of Compliance Monitoring and CT logs inclusion process

14. Cisco Systems Root Program Update

Presenter: Jos Purvis, Cisco
Notetaker: JP Hamilton, Cisco
Jos gave an overview of Cisco’s Root Store Trust-bundles. The slides presented can be found in the attached presentation (Cisco CABF Trust Store Update – October 2019.pdf). In short, Cisco presented on the following updates:

They are continuing their work on converting their current Intersect and Union bundles to CCADB compatibility;
They are mulling over whether and how to differentiate validation levels for CAs and certificates (DV/OV/EV) within the bundle;
They are working on updates to support differentiated trust for CAs based on certificate use (e.g. TLS vs. device identity);
They are considering how to support additional bundle formats for devices, such as JKS.

Cisco-CABF-Trust-Store-Update-October-2018 Download

15. Apple Root Program Update

Presenter: Geoff Keating, Apple
Notetaker: Mike
CT

TLS certificates issued after Oct 15 must be CT qualified. Needs to have two or more SCTs included in the certificate – Applies to Safari and API endpoints used by Apps
shows all the details on Apple’s CT policy. If you already comply with the Chrome CT policy you should already be compliant with Apple’s policy.

Software Releases

iOS 12, macOS 14, watchOS 5, tvOS 12. – Updated root store – Updated CT list

Other Changes

Virginia has left Apple for other opportunities

16. 360 Root Program Update

Presenter: Iñigo Barreira, 360 Group
Notetaker: Ben
New Policy 1.2 modified the procedure for inclusion and more specific requirements for descriptions of validation methods in a CA’s CP/CPS. This is published by the end of October. There is a new CA applications form. New UIs – there is a green lock icon for CAs that are included in the 360 root store. An expired certificate or other error will show a greyed lock icon with a red X. For CAs not included, there is a yellow warning triangle. For poor security there is a red warning triangle. Accepted CAs are listed at caprogram.360.cn. A preliminary list is published in October. In November a definitive list will be published. Issues with CA Documentation. CAs should not copy-and-paste the Baseline Requirements. The CA company needs to assert that they perform the required validation tasks. CAs should not assert that they perform all validation methods if they are not using them, or they should assert what is their default validation procedure. Revocation procedures should be more specific about what the CA does, not just say that it follows the Baseline Requirements. CAs need to update and check their CP/CPS for outdated or unused terms. The CP/CPS needs describe in more detail that specific requirements are being met, like OCSP responses when responding to a request for an unissued serial number and that vulnerability scans and penetration tests are being performed, etc. CP/CPS must be updated on an annual basis. A discussion followed about whether a CP/CPS could be updated during an audit. The audit can cover changes to the CP/CPS during the audit period.

360_Browser_Updates_CABF_F2F_Shanghai_October_18 Download

17. ETSI Update

Presenter: Arno Fiedler, D-Trust; Phillipe Bouchet, ACAB’c
Notetaker: Enrico
Arno presented an Update on the ETSI Working Group ESI: (Electronic Signatures and Infrastructures) ISO 17065 is one of the foundations of the ETSI Certification Policies based audit scheme. Caused by the eIDAS Regulation an European accreditation system is incorporated into the audit scheme. There has been the need over the past few years for a better way to know who is accredited as an auditor for ETSI CP, because ETSI is an official standardization organization that does not oversee audits. The accreditation scheme is not person-based, it is accreditation of the auditing body – the Conformity Assessment Body (CAB). The CAB is responsible for the quality and skills of the auditor and the quality of their work. In Europe, at the top level, there is the European Accreditation Authority (http://www.european-accreditation.org). A CAB must conform to the ISO 17065 and must be accredited to audit pursuant to ETSI 319 403. To verify whether the CAB is accredited, you can request its accreditation certificate, and the certificate will need to reference the applicable standards for which the CAB is accredited. ETSI has created a detailed audit check list for auditors who audit CAs, the check list includes more than 300 specific controls. As already reported in London ETSI ESI has created TS 119 403-2 “CABs auditing TSPs that issue PTC, a document that provides additional requirements for CABs auditing TSPs that issue PTC, most of the requirements are based on recommendations by the Browsers. Standards are available for download at http://www.etsi.org/standards-search. The most important standard for this group is EN 319 411-1 . Phillipe reported about the actual tasks of ACAB’C , now an organization that cares about the quality of the auditor, please see the slides for details.

2018-10-17-ETSI-ACABc-CABFORUM_ShanghaiWednesday Download

18. WebTrust Update

Presenter: Jeff Ward and Don Sheehy, CPA Canada
Notetaker: Kirk
Jeff Ward and Don Sheehy presented an update on the WebTrust for CA’s program

Update covers” Reminder: History of WebTrust products and the standards / Current status of WebTrust products / reporting / New products – status / New “Lifecycle” reports under development / ISO 21188 analysis/impact / CPA Canada.
History Components. The professional attestation/assurance standards that allowed the engagements to be undertaken and impact reports / The measurement standards that are used for the engagement (principles and criteria). Development is not related to professional standards except that they need to be generally accepted to allow for public distribution.
Umbrella Professional Attestation/Assurance Standards Affecting WebTrust Program (Assurance and reporting): (a) AICPA (US): Statements on Standards for Attestation Engagements – Dec 15 1995 / CPA Canada (CICA): CICA Handbook Section 5025 – effective April 1997 / IFAC (International): ISAE 3000 –December 2003. (b) AICPA (US): AT 101 – effective June 1 2001 / CPA Canada (CICA): CSAE 3000 – effective July 1 2017/ IFAC (International): ISAE 3000 (rev) Dec 2013 effective Dec 15 2015. (c) AICPA (US): SSAE 18 – effective May 2017.
WebTrust for CA Vs 1.0 (from Mar 6, 2006 presentation to CAB): Released in 2000 / Developed by AICPA/CICA WebTrust Task force / Based on best practices and existing or proposed technical standards at the time of release. Internal control criteria based on the existing body of ANSI, ISO, IETF, and other existing standards Certification Authority Control Objectives against which Certification Authorities may be evaluated. International Organization for Standardization (ISO) work on standardizing X9.79. American Bar Association’s Information Security Committee (ABA-ISC) was developing the PKI Assessment Guidelines (PAG). Document developed and circulated to both Certification Authorities and users (due process)
WebTrust for CA Vs 2.0. Released March 2011 effective July 1 2011 / Developed using ISO 21188 “Public Key Policy and Practices Framework” and Version 1.0 of the AICPA/CICA WebTrust Program for Certification Authorities / Approval was also obtained from the Certification Authority Browser Forum (CA/Browser Forum – see www.cabforum.org) for the content and control activities contained in the framework.
WebTrust for CA Vs 2.1: Released Sept 1, 2017 effective audit periods commencing on or after November 1, 2017 / Updated introduction section, including clarifying definitions for Root CA, Intermediate/Issuing CA, and Subordinate CA, and adding explanation of a Bridge CA structure / Removed references to WebTrust v1 for Business Practices Disclosures. All CP and CPS documents must now be structured in accordance with RFC 3647 (recommended) or RFC 2527 / Updated various criteria – including Criterion 3.6 – Expanded scope to specifically address hypervisors and network devices. Criterion 3.7 – Expanded scope to specifically address system patching and change management activities. Criterion 3.8 – Clarified scope to include requirement for backups of CA information and data to be taken at regular intervals in accordance with the CA’s disclosed business practices. Criterion 4.6 – Clarified scope to include destruction of any copies of CA keys for any purpose, and added illustrative controls addressing formal key destruction ceremonies. Criterion 4.10 – New criterion added to address CA Key Transportation events. Criterion 4.11 – New criterion added to address CA Key Migration events. Criterion 6.1 – Streamlined criteria, minor updates to illustrative controls. Criterion 7.1 – Updated to address cross certificate requests.
Other WebTrust program components. Audit Scheme Versions / Scheme, Version, Release Date, Effective Date / WebTrust for CAs, 2.0, 1-Mar-2011, 1-July-11 / WebTrust for CAs, 2.1, 1-Sept-17, 1-Nov-17 / WebTrust for CAs – Extended Validation – SSL, 1.6.0, 31-Jan-17, 01-Jan-17 / WebTrust for CAs – Extended Validation – SSL, 1.6.2, 01-Oct-17, 01-Nov-17 / WebTrust for CAs – Extended Validation – Code Signing, 1.4, 31-Jan-17, 01-Jan-17 / WebTrust for CAs – Extended Validation – Code Signing, 1.4.1, 17-Oct-17, 01-Nov-17 / WebTrust for CAs – SSL Baseline with Network Security, 2.0, 03-Apr-14, 01-Jul-14 / WebTrust for CAs – SSL Baseline with Network Security, 2.2, 31-Jan-17, 01-Dec-16 / WebTrust for CAs – Publicly Trusted Code Signing Certificates, 1.0, 01-Feb-17, 01-Feb-17 / WebTrust for CAs – Publicly Trusted Code Signing Certificates, 1.01, 1-Oct-17, 1-Oct-17
Reporting: Reporting requirements are illustrated on matrix at https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-WebTrust-services/principles-and-criteria / Sample reports have been developed under each standard since W4CA program began – current ones are at https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-WebTrust-services/practitioner-qualification-and-guidance / One other historical note – Microsoft qualification program guidance was initially developed for trusted root program beginning March 2001 /
Current Status: WebTrust for RA: Final draft prepared / Has main principles similar to WebTrust and additional principles (appendices) for Baseline+NS, EV / Only one person from CAB commented – Anyone else interested? / Working on reporting alternatives / Targeting effective date April 1 2019. Practitioner guidance for auditors: Under development covering public and private CAs / Will provide examples of tools and approaches as best practices – please share if you have any in mind / Latest draft reviewed September 2018 meeting – expected release 2019
WebTrust Reports Available – Full Lifecycle. Rootkey Generation Ceremony Report (Birth Certificate) / New – Key Protection (provides assurance that once a key is created and up to the point it is moved into production, it was properly safeguarded) / Point In Time (As of date for testing the design and implementation of controls) / Period of Time (Same as Point in Time, but also tests transactions over a period between 2-12 months to ensure they are operating effectively) / New – Key Transportation, Migration & Destruction (under development)
Report Terminology. Point In Time (aka Type 1, or Design Only): As of a given date / Focused on the design and implementation of controls / Effectiveness of controls not tested. Period Of Time (aka Type 2): Minimum 2 months, max of 12 / Includes testing effectiveness of controls over the period, not just when auditors were there / Readiness Assessment / Consulting report – not an audit / Report is for management and internal users only \ Can’t be shared with any external users.
ISO 21188 analysis. Draws distinction between PKI systems used in closed, open and contractual environments. It further defines operational practices relative to financial-services-industry-accepted information systems control objectives / Intended to help implementers define PKI practices that can support multiple certificate policies that include the use of digital signature, remote authentication, key exchange and data encryption / Minor changes needed, nothing significant / Does not address authentication methods, non-repudiation requirements or key management protocols.
Impact of revised ISO 21188 on WebTrust. No changes required to WebTrust criteria – no expected audit impact / Updates to ISO standards for cryptographic hardware in illustrative controls (i.e. 15872-1 to 19790/13491-1) / 4 additional non-significant illustrative controls (security management, system access management, CA key generation, CA key compromise) / CPA Canada will incorporate these changes into a future substantive update to WT4CA, but does not plan on issuing a separate update to cover these changes only
Formalization of Processes at CPA Canada. Additional formalization of CPA Canada processes being undertaken based on perceived risk of service: Replacement of WebTrust.org with CPA Canada – https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/standards-other-than-cas/publications/overview-of-WebTrust-services / More detailed license and process considerations for auditors, including international
Personnel. CPA Canada / CPA Canada: Gord Beal, Kaylynn Pippo, Janet Treasue, Bryan Walker, Annette DaRocha, Taryn Abate. Consultant to CPA Canada: Don Sheehy (Vice Chair). Task Force Members and Technical Support Volunteers: Jeff Ward (Chair), BDO; Chris Czajczyc, Deloitte, Reema Anand, KPMG, David Roque, EY; Eric Lin, EY; Daniel Adam, Deloitte; Tim Crawford, BDO; Zain Shabbir, KPMG; Donoghue Clarke, EY; Santhan Raj, KPMG.
Reporting Structure/Roles. Gord Beal – WebTrust falls into Guidance and Support activities of CPA Canada / Janet Treasure – Seal system and licensing responsibility / Bryan Walker – Licensing advisor. Don Sheehy – Task Force and CABF liaison. Jeff Ward – Chair of the WebTrust Task Force and primary contact. All Task Force members provide WebTrust services to clients. Volunteers are supported by additional technical associates and CPA Canada liaison but report to CPA Canada

19. Report from SCWG Validation Subcommittee

Presenter: Tim Hollebeek, DigiCert
Notetaker: Leo

Interest has cooled
Wait until more concrete interest
Attacks on validation methods like DNSSEC not easy to solve
Next topic CAA records
There has been lengthy discussion in underscores in domain names
Expires within 30 days, notifying customers, Wayne will write the proposal
TLS ALPN validation method
Will allow remove methods 9 and 10
Ryan will write up the ballot
No CA voluntarily acknowledges using those methods
HTTP validation – write a ballot to tighten up some of the text

20. Improving validation for identity certificates

Presenter: Tim Hollebeek, DigiCert
Notetaker: Daymion

Some of the current information sources used for validation are understood to not be reliable.
Proposed First Ballot: What can we do to make the CA procedures more transparent?
Proposed Second Ballot: What can we do about poor data sources? We have found the data validity is relative to the source, Government vs Third Party DB. How do we figure out a way the data sources are appropriate and valid? Government source tend to be more reliable.
Robin: What would the process look like? Would we build a white list of what sources are good or would we build a bad list?
Tim H: Maybe the first step would be for CAs to reveal what data sources they are using.
Ryan S: More detailed disclosure of what data sources are being used. This should be an auditable disclosure. Maybe a modification to the baseline requirements, add to the CP/CPS.
Check commonality within the ecosystem
Building the source list would be a good first step.
Tim H: Off of this list we could build a white list.

Day 2 – 18 October 2019

Attendees on October 18, 2018: Richard Wang, 360 Group; Clemens Wanko, ACAB’c; Phillipe Bouchet, ACAB’c; Trevoli Ponds-White, Amazon Trust Services; Xiaosi Li, Amazon Trust Services; Geoff Keating, Apple; Franck Leroy, Certinomis (Docapost); Aleksandra Kapinos, Certum; Wojciech Trapczyński, Certum; Yi Zhang, CFCA; Jonathan Sun, CFCA; J.P. Hamilton, Cisco; Jos Purvis, Cisco; Robin Alden, Comodo CA; Tony K.F. Chan, Deloitte China (Beijing); Jesse Yun He Wang, Deloitte China (Beijing); Putzy De Wei Lu, Deloitte China (Beijing); Peter Koo, Deloitte China (Hong Kong); Ben Wilson, DigiCert; Tim Hollebeek, DigiCert; Arno Fiedler, D-TRUST; Enrico Entschew, D-TRUST; Vijay Manjunatha, eMudhra Technologies Limited; Kirk Hall, Entrust Datacard; Bruce Morton, Entrust Datacard; Chris Bailey, Entrust Datacard; Wei Yicai, GDCA; Zhang Yongqiang, GDCA; Wang Chunlan, GDCA; Atsushi Inaba, GlobalSign; Doug Beattie, GlobalSign; Daymion Reynolds, GoDaddy; Devon O’Brien, Google; Ryan Sleevi, Google; Ryan Hurst, Google; Dimitris Zacharopoulos, HARICA; Mike Reilly, Microsoft; Gordon Bock, Microsoft; Wayne Thayer, Mozilla; Tomasz Nowak, Opera; Tadahiko Ito, SECOM; Cui Jiuqiang, SHECA; Chen Xiaotong, SHECA; Dai Yeqi, SHECA; William Luo, ShenZhen Digital Certificate Authority Center Co., Ltd; Zheng Huitao, ShenZhen Digital Certificate Authority Center Co., Ltd; Fotis Loukos, SSL.com; Leo Grove, SSL.com; Edwin Zhai, TrustAsia Technologies, Inc.; Ralph Zeng, TrustAsia Technologies, Inc.; Frank Corday, Trustwave; Jeff Ward, WebTrust/BDO; Don Sheehy, WebTrust/CPA Canada.

21. Report from SCWG Network Security Subcommittee

Presenter: Ben Wilson, DigiCert
Notetaker: Robin Alden, Comodo CA
We’ve created a web page for the group on which may be found the charter, and the listserv is the same one we had for the netsec requirements. There are about 9 people on the list and we have marked as moderated anyone who has not signed an IPR agreement. Subscribe on the listserv if you got unsubscribed. I sent an email to the SCWG and to the NetSec email list asking them to express their interest if they wanted to participate. Also sent instructions on how to subscribe themselves. The charter says one thing is to work on minimum requirements and mentions best practices. Discussion on which we aimed at: Aiming for minimum requirements, so SHALL, not SHOULD, in general. Focus on the things that will be auditable. Thoughts include:

Improving what the document says, with minor changes if needed, as we preserve the doc and work on #2 which will be more comprehensive in analysis of risk assessments on what the CA system is trying to protect.
Improving ways that CAs offer services through the cloud, virtualization, etc.
A need to re-evaluate everything, but not start from scratch. Not be narrowly focused on what is in doc today.

We will have a doodle pool to have the best meeting time, every two weeks. Have F2F meet or an all-day summit, either before the next CABF F2F, or the day before – on a Monday – in Cupertino. Contact Ben offline to say whether good idea or not. What is the best way to get a jump start on the work tasks. Maybe better not to have summit first, lets talk on the call.

22. Update on London Protocol

Presenter: Chris Bailey, Entrust Datacard
Notetaker: Bruce
Objective of London Protocol is to improve assurance on websites with identity certificates. It is a framework to test new ideas to improve identity and share results with the larger community. Today we are working on 1) Anti-phishing system and 2) Identity collision system. Reinforces the distinction between identity websites (OV and EV) and by making them more secure for users than websites encrypted DV certificates. Reviewed growth in sites which are deemed dangerous by Google Safe Browsing. Created a table of phishing sites per certificate type based on a total number of certificates (based on Netcraft dataset) of 43 million. Methodology for phishing detection uses many sources; data is gathered and confirmed with Google safe Browsing; attempt to collect screenshots, certificate data, etc. What happens after a phishing site is detected:

Contact owner of the site
If false positive, then owner to contact Google safe Browsing,
Maintain contact with owner
Continue to monitor wbsite for 30 days and
Maintain records and share information.

Summary – We think this is quite positive as customers are thankful to be proactively notified. Members were listed are: Comodo, GlobalSign, Entrust Datacard, GoDaddy, D-Trust, Trustwave, and Buypass. Ryan asked why there was focus on OV and EV certificates? Specifically, the slides discussing it being about improving OV and EV, but seemingly DV could also benefit if this was useful. Chris responded that Entrust only does OV and EV, so it’s naturally where they start, but other participants in the protocol could discuss their motivations. There was a suggestion that one reason is because contact information exists for OV and EV, but Ryan pointed out that DV has contact information as well by virtue of needing to execute the Subscriber agreement. Chris and Daymion clarified that they thing it’s a lot of work, so they’re testing the waters with OV and EV, because it’s not as large as DV.

23. Report on Name Clash Service

Presenter: Daymion Reynolds, GoDaddy
Notetaker: Jos
In London, Daymion and others had announced a project to analyze CT log data to look for naming collisions in certificates. In this presentation, Daymion described his process for analysis and the conclusions from his research. A collision, for the purpose of his research, was primarily defined as a case where two or more certificates were issued for two completely different identities (that is, two separate organizations) but with matching or confusing certificate values. Since the concern in name collisions is particularly significant in EV certificates due to UI issues, he started with EV certificates and focused on the Organization (O), Country (C), State/Region (ST), and serialNumber (SN) fields, initially using data purely from CT logs. To begin, he gathered the entire raw CT log dataset from ten different CT logs, and then parsed the O/C/ST/SN and also the Subject Alternative Name (SAN) fields from each certificate in the log. For the O field, he found a great deal of inconsistent formatting such as quotation-mark differences (Deutsche Bank vs “Deutsche Bank”, e.g.) and case differences (INC vs Inc vs inc, e.g.) that required some data normalization to parse. The C and ST field, similarly, were very inconsistent in casing, but were also different in standard abbreviations-for example, the use of gb, GB, and UK all to represent the United Kingdom, or the use of Zurich vs Zürich to represent the same city. A member asked whether Daymion reported errors he found; he replied that the dataset naturally includes both misissuances and revoked certificates, which contained the oddest errors in formatting and content. The serialNumber field has no guidance on content in the EV guidelines, so there were a wide variety of different formats for content. He did find a number of certificates (largely revoked or expired) that showed wide inconsistency in value strings even for the same country’s serialNumber values. To condense the data, he considered three collision cases:

Same O field but different C, ST, or SN;
Same O field but different C or ST ignoring SN;
Same O/C/ST/SN fields but different root domains (with some expectation of false positives here).

A member asked about what formatting and matching methods Daymion used; he reported that he’d used binary matching and used the same string-print method (UTF) to format the representations of all fields. In addition, for C and ST he lower-cased the whole field contents, trimmed whitespace at the beginning and end of the value, and mapped long-form values to short-form values (e.g. “Great Britain” to “GB”) especially in the SAN field. He also lower-cased all SAN field contents to avoid casing mis-matches (e.g. “www.Symantec.com” vs “www.symantec.com”). Examining his results, he found the following in each of the three cases:

4830 collisions for same-O/different-C,ST,SN, but there were lots of false positives here and many old certificates with poor SN field values in the majority of the remainder. The majority of issues found here were with the serialNumber field, and manual spot checking quickly revealed false positives. He acknowledged that it is difficult or impossible to identify these false positives purely from the raw CT log data, however: they required checking with another qualified source. He concluded that there is no guidance on differences in serialNumber formatting between CAs.
50 collisions for same-O/different-C,ST/ignore-SN, but all of these were considered false positives. Here again, quick spot checks identified the false positives, but these were difficult or impossible to sort out using only the raw CT log data. The majority of these found were either differences in letter choice (Zurich vs. Zürich, e.g.) or the same company with registrations in multiple places (e.g. registration as a Delaware company vs. registration as a Swiss company).
For same-O,C,ST,SN/different-domains, he was forced to abandon his analysis due to the overwhelming number of false positives. Much of this he attributed to companies adding new SAN domains to existing certificates, making it difficult or impossible to filter out genuine collisions.

Daymion then examined how these collisions, particularly in O-field values, occurred. He observed that we are trying, as an industry, to apply something that is pre-Internet (corporate registrations with a government authority, formerly a local problem) to the Internet, which has a much more global scope. Company registration numbers were fine at a local scale, but the overlap in values and company footprint prevents things from being globally unique. With this in mind, he felt collisions are inevitable: companies with the exact same organization name trying to do business on the Internet will happen. This is, he felt, a solvable problem but will require the industry sharing some data and agreeing on a common and consistent process for doing so. In all cases, he pointed out, the raw CT log data is very useful but not enough to sort real collisions from false positives-necessary, in other words, but not sufficient. Standards bodies should provide guidance on field-value formatting (case, spacing, use of ISO values), and these should be built into the logic of any services used to sort out or detect collisions. In addition, he advocated for transparency in value vetting for certificates: supporting artifacts for validation of certificate values by the CA should-where possible-be made publicly available for end-user audits. Finally, O-field collisions could be eliminated through the use of a single central repository for organization field values, with precedence rules for handling collisions. Finally, he felt the EV Guidelines for certificates should be adjusted to reflect all of the above and enforce it consistently across the CA ecosystem. Ryan asked whether, given the cases of abuse or problems in the DNS uniform name resolution process, whether he thought an organizational registry could genuinely eliminate collisions without also enabling such abuses in the certificate ecosystem. Daymion responded that he was not introducing a proposal around such a registry for similar reasons, but instead pointing out the issue and asking for an open discussion of it within the CABF community. He felt that the CABF was the correct place to solve the problem, as the problem space is the contents of certificates, something directly governed by the Forum’s Guidelines. Another member pointed out that, looking at the numbers, the large number of false positives would seem to indicate that collisions in this space weren’t an issue. Daymion responded that it appears that way: what he didn’t find were many certificates that identified two different organizations the same way. What he did find, however, were many certificates that represented the same organization two different ways, which is also a significant problem. A member asked whether one company in one jurisdiction being replaced by another with the same name would count as a collision-e.g., if “Bob Co” went bankrupt and then a year later someone else started a different company also called “Bob Co”. Daymion responded that he did not consider that a collision, but that he did find a few cases where the same company name represented two different organizations in two different localities. Another member suggested that perhaps prior to issuance, CAs could do what Daymion did and consult the CT records for potential collisions. Another member asked whether Daymion had examined or included “XX” country certificates for certs issued in countries that do not exist-he responded that he hadn’t included those in his data sets. At this point, Daymion introduced three proposals from his research:

Create a community API to evaluate organizational collisions - A service or API could be established to key off the O/ST/C/SN values, with normalization logic, based on CT log records. This would let CAs check prior to issuance for potential collisions in certificate values. GoDaddy will be establishing the first pass at such an API, for testing purposes, based on available CT log data. Ryan asked about problems in specific values such as suffixes (“BBC Inc” vs “BBC Ltd”, e.g.) or the differences in Romanization of company name values (such as the Romanization of Chinese company names). Daymion responded that their test API is purely to ‘kick the tires’ on this work for testing purposes, and they welcomed all feedback on it.
Establish clear guidance on ‘red flag’ certificate values that require more research - Right now, every CA maintains (or should maintain) a set of red-flag values such as “VISA” in the certificate field values that triggers additional research and checking prior to issuance. He proposed that a central set of such values would be important and useful for the CA community and that it could be potentially maintained by the CABF with an API for CAs to use in their issuance process.
Open up validation to transparency - Right now, the validation process of CAs is, Daymion pointed out, a ‘secret sauce’. This creates problems in trying to audit what values were validated and how. He proposed creating a Validation Artifact Repository linked to certificates where an immutable record of the validation steps for a certificate could be viewed and audited by users. This, he acknowledged, could have issues with GDPR and contracts. A member asked about whether this would cover organizational validation or the validation of the whole certificate; Daymion wanted to cover the whole certificate, ideally. Asked about encoding into certificates the method of domain value validation, something under consideration by the Forum right now, Daymion felt that this was a good idea, but would need to be carefully handled.

Ryan asked about the core problem these proposals were trying to solve and whether the gradual elimination of organizational information in the UI by the browsers would affect needing to solve these problems. Daymion responded that the goal was to eliminate the periodic security issues raised around organization information, to get the ecosystem to a more trustable but also more transparent state. He felt that the recent plethora of questions around the contents of the O field had not been answered well by the CA community, and it was clear this piece of the puzzle was lacking in transparency. Wayne Thayer pointed out that improvements here could be done, but collisions would still occur, and the community needed proposals for handling collisions when they happen. Daymion agreed, but pointed out that the CA community is constrained by the dictates of the EV Guidelines, so if there are proposals to be made they have to be baked into the EV Guidelines; he felt it was clear that how CAs are handling the problem right now is insufficient. Another member pointed out CAs often handle collisions in their own issuances well, but don’t properly handle collisions when they cross CAs (i.e. two CAs issuing certificates for colliding values) because they aren’t sharing information sets, and that transparency would help CAs share validation information in order to prevent that.

24. Potential changes to server certificate issuance processes for increased transparency

Presenter: Daymion Reynolds, GoDaddy
Notetaker: Gordon

25. Types of audits/reports under WebTrust and their terminology

Presenter: Jeff Ward, Don Sheehy
Notetaker: Kirk
Jeff Ward presented a summary of the types of audits/reports under WebTrust and their terminology, starting with the reporting lifecycle and finishing with proposals for new detailed reporting.

1. WebTrust Reports Available – Full Lifecycle

Rootkey Generation Ceremony Report (Birth Certificate)
New – Key Protection (provides assurance that once a key is created and up to the point it is moved into production, it was properly safeguarded. US draft created)
Point In Time (As of date for testing the design and implementation of controls)
Period of Time (Same as Point in Time, but also tests transactions over a period between 2-12 months to ensure they are operating effectively)
New – Key Transportation, Migration & Destruction (under development). Some have been issued – not publicly

2. Proposal for More Detailed Reporting

Current status of reporting:

Current model in place since 2001
Users currently receive short form standardized general-use assurance/ examination reports that link to the CA’s CP/CPS, the relevant WebTrust criteria, managements assertion
Detailed listing of roots etc. under audit is referenced
Linked to seal where applicable
Browsers are trying to use software to electronically capture the audit report information so they do not have to read each report

Detailed CONTROLS Reporting (SOC 3 like)

A SOC 3 like report could be issued with a System description that sets out the CA’s controls as they relate to the criteria and principles
But, report size will grow significantly due to the inclusion of such

Pros and Cons of a Soc 3 like report Pros:

Includes Extensive data on policies and controls that were tested by auditor included in system description
Provides detailed information to users
Publicly available under current standards

Cons:

Cost of report will increase due to need to include full detailed system description
Does not provide detailed control testing and results of testing

4. Detailed Examination Report

Some browsers have stated that they want far more information made available to them including:
Overall audit results (opinion)
Details on the policies and controls tested
Detailed testing results
In essence, asking for reports that have detail similar to an AICPA SOC 2 report (SOC 2 are issued on restricted distribution bases by audit profession for service organizations)

Pros and cons for detailed examination reports: Pro:

Will provide level of information needed by browsers?
Only period of time report
Provides detailed testing information

Cons:

Cost of report for each CA will rise significantly due to increase in report details
Reports will likely be in range of 80 to 100 pages long as need to set out
The audit report – more detailed than current
The assertion by management
Roots etc. under audit
The description of the CA business that meets detailed description criteria
The WebTrust Criteria, the controls that CA exercises to meet the criteria and the individual testing results
Where applicable an unaudited Section 5
Some browsers share information publicly – standards may not allow this form of reporting
Significant potential for misunderstanding by uninformed public
Additional risks to auditors – they may not want to be involved in detailed reporting except on restricted basis
Wanted for all reports or just some as point in time reports do not have testing?
Due to size and non-standardization will not likely be able to analyze electronically – need to read

5. Potential Alternatives Analysis

(a) Status quo

Reports are generally understood by users, meet general distribution standards
Easily analyzed by electronic means
Least costly
Does not completely meet browser needs?

(b) SOC 3 like report

Similar to current status quo BUT add a detailed System Description that meets the description criteria of SOC 2
Gives users of report details on CA business operation and policies and controls in place that were subject to audit
No issue with current attestation/assurance standards
Size of report increases significantly
No individual testing results
Some potential for misinterpretation by uninformed users
Cost of report will increase
More difficult to analyze electronically
Works with period of time and point in time reporting

Similar to SOC 3 BUT
Detailed testing results included (period of time reports)
Normally restricted distribution
Potentially section 5 unaudited section added
Possible issue with current attestation/assurance standards (restricted distribution) – Uncertain that use as a general distribution report will be permitted by standards of AICPA. CPA Canada and IFAC
Size of report increases again but not significantly
Gives users of report details on CA business operation and policies and controls in place that were subject to audit as well as testing results
Potential for misinterpretation by uninformed users
Cost of report will increase again due to inclusion of testing and testing results
Risk to auditors will increase
More difficult to analyze electronically

The path forward We need to meet the attestation/assurance standards issued by the audit profession:

SSAE 18 ( US – ATC 105 and 205)
CSAE 3000/3001 Canada
IFAC ISAE 3000 revised – international reports

The path forward:

Obtain general agreement from the Forum as to the type of reporting that will satisfy CAs and Browsers
Meet with relevant personnel from AICPA, CPA Canada and IFAC to assess whether SOC 2 like report is permissible and what additional considerations might be needed
Meet with Risk leaders of firms to assess whether they would be willing to do non-restricted reporting that mirrors SOC 2
Develop a detailed report template that could be used under either SOC 2 or 3 (excluded testing) to demonstrate what would be needed to be disclosed to meet the description criteria. This will be extensive due to need to include discussion of/organization of company, company CA operations and details on controls and policies that are under audit
Depending on 1, 2, and possibly 3 – develop detailed SOC 3 or SOC 2 reporting template for approval by CPA Canada, AICPA and IFAC
Release report for use

26. Types of audits/reports under ETSI and their terminology

Presenter: Clemens Wanko, ACAB’c
Notetaker: Phillipe

Presentation of ETSI Life Cycle Coverage Download

Presentation of ETSI audit reporting Download

27. Discussion of current state of audits and membership requirements

Presenter: Ryan Sleevi, Google
Notetaker: Ben
Audit Requirements What’s wrong with audit requirements, the bylaws, etc. 28. Background We have terminology problems, illustrated by the following phrases: “performance audit” and “point in time readiness assessment”, “key ceremony report”, “currently valid audit report”, “full surveillance”, “publicly-trusted certificate”, and “fail to pass an audit”. Articles have been written and tools have been developed. It’s been 14 years since Mozilla’s 1st Root Store Policy and 18 years since WebTrust 1.0 and ETSI first published audit criteria. What are the issues and how do we move forward? Motivations In an ideal world, audits should streamline processes and reduce risk of removal from root programs. Auditors want to provide value and maintain acceptance of reports. History X9.79 group developed Annex B for PKI Practices and Policy Framework, evolved into WebTrust for CAs 1.0. IETF had the PKIX RFC 2527. The American Bar Association was involved with the PKI Assessment Guidelines (PAG). It espoused XML for CPs and CPSs for processing comparisons. Followed by ISO 21188. And in the EU, there was the Electronic Signatures Directive 1999/93/EC. This then brought about ETSI TS 101 456 and TS 102 042. WebTrust: The ABA’s PAG discussed “assessment” and led to WebTrust for CAs 1.0. This history informs us what an auditor/assessor is and what we can expect from an auditor/assessor. ETSI: TS group combined from CEN and created CWA 14172-2 and CWA 14167-1. Asked about criteria for auditors/assessors-independence, professional conduct, etc. And national rules adopted (ETSI TS 119 403). ISO 17065 is a certification scheme of a product or service. This is somewhat different than the WebTrust approach. ETSI vs. WebTrust Certification scheme (whether process implements what is expected) vs. an opinion – did management fairly state that a claim (e.g. regarding compliance, security controls, etc.) ETSI output is a certificate. WebTrust output is an opinion. ETSI specifies the procedural steps whereas WebTrust relies on professional standards (e.g. AICPA AT-C 105). ETSI defines “problems” as non-compliance. WebTrust defines “problems” as misstatements by management. ETSI non-compliance results in removal of certification whereas with WebTrust misstatements result in qualifications on the opinion. (WebTrust results can be unmodified, qualified, adverse, or disclaimed.) ETSI process is to examine design and processes, whereas WebTrust process is to gather evidence of performance over time. ETSI is focused on the present and the future whereas WebTrust is focused on the past-whether management did what they said they did. WebTrust approach for future was to provide a seal. ETSI scope focuses on organization and system heavily influenced with the ISO 27000 framework. WebTrust scope focuses on the CP and CPS, PKI hierarchy, etc. ETSI has notion of continuous compliance and disclosing whether there are changes with reporting to the supervisory body. Current Issues “Performance Audit” doesn’t work with certification scheme of ETSI. Concept is not scalable for future CABF working groups. We should replace the phrase “point in time readiness assessment”. We should require an initial performance. “Period of time” may not work, so ETSI and WebTrust may need to collaborate. The “key ceremony report” ought to be revisited. “Currently valid audit report” can be replaced with something else that evidences compliance. Expectations We want alignment between what we want and what we get. Liability model is U.S.-centric, but for browsers we want to reduce risk. Microsoft wanted to reduce legal liability, whereas Mozilla had concerns about security. And there were concerns about transparency, too. This risk reduction/transparency is to provide assurance among CAs, RAs, cross-certified CAs, users, etc. Reviews of CP/CPS and work by auditors, etc. are all efforts to reduce risk. It’s not so much about shifting liability as it is about addressing risks and increasing trust in the ecosystem. Potential Solutions Ryan: what are the potential solutions? What are the problems we’re trying to solve? Ben: I agree that we’re all in this to reduce risk to end users. The question is how we go forward, how do we change things? Maybe a combination of both audit schemes? I know that the browsers are interested in harmonizing the way things are done in the U.S. and in Europe. How do we make the process efficient for CAs because it seems we can spend a lot of time and money without doing it the right way? Ryan: There was an APAC group that looked at impact on relying parties. Relying parties are interested parties. For example, ETSI 119 403-2 is a voluntary accreditation scheme. Is it something that someone be certified to conduct. It would be good if it could include the testing procedures performed. Do we want a CABF certification scheme? Looking at the initial root program schemes, there were costs and such costs were passed on to the CAs. Browsers want to make it easier to comply. Jos: Two problems are that the language in all guideline sets do not match audits that exist today. And the other is that the audit ecosystem is not giving what the browsers want to get. Wayne: Browsers need to more clearly define what they want and ask audit schemes whether we can get we can get what we want. Do we need a working group to develop documentation of what we want? Ryan: Can we have a subcommittee of the Server Certificate WG work on it. The Bylaws are affected by the assumptions from the guideline documents. We should then be looking at the level of detail in audit reporting, and WebTrust and ETSI might need to go back to their professional standards bodies to see if they can prepare those kinds of documents. Don: Should we continue to explore SOC 2, because an overhaul would be quite an undertaking? Description criteria section of the SOC 2 report would be 30 pages long, and CABF could provide input into what browsers would like to see and that would help dictate the rest of the audit report. Ryan: do we have as a priority specificity or transparency? Which of the SOC-type reports would we prefer?

CABF45 – Sleevi – Whats Wrong With the Ecosystem Download

28. Audit requirements over the lifecycle of a root

Presenter: Wayne Thayer, Mozilla
Notetaker: Ryan
Wayne described the problem as one where both new and existing CAs are having trouble finding the right documentation to provide. Examples include preparing a new root certificate for an inclusion request or ‘retiring’ a root in which no new certificates are being issued, but the CA desires the existing roots to be remain functional. He then presented (Slide 3) a host of events that can occur during a CA’s operational cycle and which may have influence on the audits and reports in the BRs (slide 4), and different Root Programs requirements around those roots (Slide 5, 6). This led to various questions for the attendees (Slide 7). The discussion of “Publicly Trusted” circled around two options – one in which it was when it’s included in at least one root program member, the other by virtue of it being issued by that root. The CA has to provide the sample certificates for compatibility testing before they can be in any program, so do they count or not? Ryan suggested that they should count, since the other definition creates a post-dating issue. Anything issued under that root should be considered publicly trusted. The discussion of RKGC by WebTrust clarified some of the questions, but clarity was needed around whether it happened at key generation or signing of a root certificate. Wayne asked whether ETSI had an equivalent, and Ryan described the ETSI situation as similar to the WebTrust situation that Don had described prior to WebTrust working on the new reports – that some auditors could generate a dedicated report, but other auditors would simply see this as a natural part of the ETSI audit and it would be an internal-only report. Ryan suggested that the BRs should be clarified that these reports are expected to be public, which the new WebTrust reports would be. Wayne asked about whether raw keys can or are in the scope of audits; existing report templates prefer certificates. The consensus from the room was that the events that mattered were the moment of key creation to the moment of key destruction, and everything that happens in between. Ryan pointed out that this is an area where ETSI has more prescriptive guidance than WebTrust, in that ETSI covers secure key destruction as part of its activities. WebTrust TF had previously presented some discussion of that work in the past, but needed more guidance from the Forum on reporting. The discussion then turned to situations where no activity had been performed – whether it was early on in the CAs lifecycle, before its issuing certificates, or as the CA as winding down, when it hasn’t issued any certificates. Ryan and Don discussed that the newer WebTrust Illustrative Reports allow for reporting and explicitly calling activities as out of scope because they were not performed, with the example being the use of third-party RAs. It may be possible to use that to indicate that certain principles and criteria were not considered because the auditor verified their non-performance. For ETSI, because its based on a certification scheme, it doesn’t necessarily require the performance of the activities. One area that Wayne brought up was about EV audits – what happens when an existing root requests EV status? Ryan raised the example of European CAs that were issuing QWACs before they’d been audited against 319 411-2. They could be successfully audited after-the-fact. If root programs granted EV, that would retroactively grant EV, while for qualified status, it’d only be from the point of the audit – which is probably not what browsers expect. Clemens said they shouldn’t be issuing qualified certificates before then, but if they do, they just don’t have qualified status in terms of the law. When asked about WebTrust, Don said the same thing was possible – the Webtrust for BRs audit is not going to look at their EV issuance, so they could have issued certificates with that EV OID before they were EV audited. If browsers didn’t want that, they could push for new criteria into the BRs that would have the auditors explicitly test that the CA hadn’t issued EV certificates, such as by using/requiring all new EV certs use the CABF EV OID, so that you could have assurance that a BR-audited CA that later applied for EV wouldn’t have a bunch of pre-audit EV certificates. Wayne then began discussing specific scenarios that he wanted to make sure were covered, and getting feedback as to what the reporting would look like. The first scenario of a new CA spinning up resulted in the suggestion that the order should be a PIT audit before they’ve done anything, followed by a Root Key Generation report, one or more ‘parking’ reports that the key hasn’t done anything (no activity). Once the key (or certificate, if generated in the RKGC) was used to start up the infrastructure and sample certificates, that’d be the point in which a period of time audit would be expected to ‘start’ covering. It wasn’t clear whether another PIT would be necessary from when the infrastructure was started up, or if the PIT->Parking report would be sufficient for root programs. Chris wanted to understand more about what these reports would cover; would they be point in time or period of time. Don described them as something that WebTrust was actively working on (see the WT update), but that the reports would cover periods of time. Wendy wanted to know about the requirements for the audits for the intermediate/issuing CA. Would that be part of the initial 90 day period of time? Wayne said that it would need to be. If they had previously created the key for the intermediate, but not yet started using it, it should be covered by the ‘parking’ audit. Ryan said there was a gap in the BRs today, because the roots have the reports but the intermediates don’t, and suggested that we should align the reporting for the two so that if you’re creating keys, they’re covered by the same key generation and parking report, but if you’re an existing CA spinning up new intermediates for yourself, it can be covered by your existing/next audit.

Audit Lifecycle Download

Next meeting March 12-14, 2019, Cupertino, California, sponsored by Apple

Latest releases

Code Signing Requirements
v3.8 - Aug 5, 2024

What’s Changed CSC-25: Import EV Guidelines to CS Baseline Requirements by @dzacharo in https://github.com/cabforum/code-signing/pull/38 Full Changelog: https://github.com/cabforum/code-signing/compare/v3.7...v3.8

S/MIME Requirements
v1.0.6 - Ballot SMC08 - Aug 29, 2024

This ballot sets a date by which issuance of certificates following the Legacy generation profiles must cease. It also includes the following minor updates: Pins the domain validation procedures to v 2.0.5 of the TLS Baseline Requirements while the ballot activity for multi-perspective validation is concluded, and the SMCWG determines its corresponding course of action; Updates the reference for SmtpUTF8Mailbox from RFC 8398 to RFC 9598; and Small text corrections in the Reference section

Network and Certificate System Security Requirements
v2.0 - Ballot NS-003 - Jun 26, 2024

Ballot NS-003: Restructure the NCSSRs in https://github.com/cabforum/netsec/pull/35