[Servercert-wg] Final Minutes for the Server Certificate WG at the 45th F2F meeting October 17-18, 2018

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Fri Nov 23 10:35:52 MST 2018

These are the Approved Minutes of the 45th F2F meeting in Shanghai for 
the Server Certificate Working Group session.


      Call to Order – Server Certificate Working Group Plenary Meeting

*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.

        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 

        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

/*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.

 1. For Audit Cases with roots in Mozilla’s program, it gets assigned to
 2. Otherwise it gets assigned to Karina (Microsoft).
 3. 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
  * 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.
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


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

*Presenter:* Paul Yang, BaishanCloud / Open SSL

CABTalks <https://cabforum.org/wp-content/uploads/CABTalks.pdf>Download 

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

*Presenter:* Quan Liu, China Electronic Authorization Industry Alliance


        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.


        15. Apple Root Program Update

*Presenter:* Geoff Keating, Apple
*Notetaker:* Mike

  * 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
  * https://support.apple.com/en-us/HT205280 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 
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.


        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.


        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 

 1. *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.
 2. *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.
 3. *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
 4. *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)
 5. *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.
 6. *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.
 7. *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
 8. *Reporting:* Reporting requirements are illustrated on matrix at
    / Sample reports have been developed under each standard since W4CA
    program began – current ones are at
    / One other historical note – Microsoft qualification program
    guidance was initially developed for trusted root program beginning
    March 2001 /
 9. *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
10. *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)
11. *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.
12. *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.
13. *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
14. *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 –
    / More detailed license and process considerations for auditors,
    including international
15. *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.
16. *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
  * 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
  * 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.
      o Check commonality within the ecosystem
      o 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
  * 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:

 1. Contact owner of the site
 2. If false positive, then owner to contact Google safe Browsing,
 3. Maintain contact with owner
 4. Continue to monitor wbsite for 30 days and
 5. 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:

 1. Same O field but different C, ST, or SN;
 2. Same O field but different C or ST ignoring SN;
 3. 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:

 1. 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.
 2. 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).
 3. 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
  * 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

 1. 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

  * 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


  * 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:
      o Overall audit results (opinion)
      o Details on the policies and controls tested
      o 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:

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


  * 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
      o The audit report – more detailed than current
      o The assertion by management
      o Roots etc. under audit
      o The description of the CA business that meets detailed
        description criteria
      o The WebTrust Criteria, the controls that CA exercises to meet
        the criteria and the individual testing results
      o 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
  * 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

(c) SOC 2 like report

  * Similar to SOC 3 BUT
      o Detailed testing results included (period of time reports)
      o Normally restricted distribution
      o 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
  * 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

6. The path forward
We need to meet the attestation/assurance standards issued by the audit 

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

The path forward:

 1. Obtain general agreement from the Forum as to the type of reporting
    that will satisfy CAs and Browsers
 2. 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
 3. Meet with Risk leaders of firms to assess whether they would be
    willing to do non-restricted reporting that mirrors SOC 2
 4. 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
 5. Depending on 1, 2, and possibly 3 – develop detailed SOC 3 or SOC 2
    reporting template for approval by CPA Canada, AICPA and IFAC
 6. 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 
Presentation of ETSI audit reporting 

        27. Discussion of current state of audits and membership

*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?
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.
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.
*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 
/*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 
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 

        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 
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 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181123/073465f4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dbfplkiofolgkfkd.png
Type: image/png
Size: 657 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181123/073465f4/attachment-0001.png>

More information about the Servercert-wg mailing list