[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.
https://cabforum.org/2018/10/18/minutes-for-ca-browser-forum-f2f-meeting-45-shanghai-17-18-october-2018/
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
<https://cabforum.org/wp-content/uploads/CAB-Forum-2018-10-17-Opera-Root-Program-Update.pdf>Download
<https://cabforum.org/wp-content/uploads/CAB-Forum-2018-10-17-Opera-Root-Program-Update.pdf>
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.
1. For Audit Cases with roots in Mozilla’s program, it gets assigned to
Kathleen.
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
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
<https://cabforum.org/wp-content/uploads/Microsoft_CABF_45_Update.pdf>Download
<https://cabforum.org/wp-content/uploads/Microsoft_CABF_45_Update.pdf>
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
<https://cabforum.org/wp-content/uploads/CABTalks.pdf>
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
<https://cabforum.org/wp-content/uploads/Browser-Support-for-SM2.pdf>Download
<https://cabforum.org/wp-content/uploads/Browser-Support-for-SM2.pdf>
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
<https://cabforum.org/wp-content/uploads/Cisco-CABF-Trust-Store-Update-October-2018.pdf>Download
<https://cabforum.org/wp-content/uploads/Cisco-CABF-Trust-Store-Update-October-2018.pdf>
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
* 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
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
<https://cabforum.org/wp-content/uploads/360_Browser_Updates_CABF_F2F_Shanghai_October_18.pdf>Download
<https://cabforum.org/wp-content/uploads/360_Browser_Updates_CABF_F2F_Shanghai_October_18.pdf>
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
<https://cabforum.org/wp-content/uploads/2018-10-17-ETSI-ACABc-CABFORUM_ShanghaiWednesday.pdf>Download
<https://cabforum.org/wp-content/uploads/2018-10-17-ETSI-ACABc-CABFORUM_ShanghaiWednesday.pdf>
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
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
2017.
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
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 /
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 –
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
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
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.
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
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:
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
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
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
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:
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:
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
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
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
(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
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
6. 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:
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
<https://cabforum.org/wp-content/uploads/2018-10-17-CABFORUM_Shanghai_Thursday_ETSI_Clemens_Wanko.pdf>Download
<https://cabforum.org/wp-content/uploads/2018-10-17-CABFORUM_Shanghai_Thursday_ETSI_Clemens_Wanko.pdf>
Presentation of ETSI audit reporting
<https://cabforum.org/wp-content/uploads/20181018_ETSI_Overview_fin_pres.pdf>Download
<https://cabforum.org/wp-content/uploads/20181018_ETSI_Overview_fin_pres.pdf>
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
<https://cabforum.org/wp-content/uploads/CABF45-Sleevi-Whats-Wrong-With-the-Ecosystem.pdf>Download
<https://cabforum.org/wp-content/uploads/CABF45-Sleevi-Whats-Wrong-With-the-Ecosystem.pdf>
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
<https://cabforum.org/wp-content/uploads/Audit-Lifecycle.pdf>Download
<https://cabforum.org/wp-content/uploads/Audit-Lifecycle.pdf>
*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