<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-text-html" lang="x-western">
<div class="WordSection1">These are the Approved Minutes of the
45th F2F meeting in Shanghai for the CA/B Forum session.<br>
<br>
<a class="moz-txt-link-freetext" href="https://cabforum.org/2018/10/18/minutes-for-ca-browser-forum-f2f-meeting-45-shanghai-17-18-october-2018/">https://cabforum.org/2018/10/18/minutes-for-ca-browser-forum-f2f-meeting-45-shanghai-17-18-october-2018/</a><br>
<br>
<h2>Day One – 17 October 2018</h2>
<p><strong>Attendees on October 17, 2018:</strong> 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.</p>
<h3 id="mce_8">Call to Order – CA/Browser Forum Plenary Meeting</h3>
<h4><span id="Read-Antitrust-Statement">Read Antitrust Statement</span></h4>
<p>The Antitrust Statement was read.</p>
<h4><span
id="1-Approval-of-CABF-Minutes-from-Oct-4-call-emailed-Oct-5">1.
Approval of CABF Minutes from Oct. 4 call (emailed Oct. 5)</span></h4>
<p><strong>Presenter:</strong> Kirk Hall, Entrust Datacard<br>
<strong>Notetaker:</strong> Kirk.<br>
The draft Minutes were approved, and will be posted to the
Public list.<br>
</p>
<h4><span id="2-Report-from-Forum-Infrastructure-Working-Group">2.
Report from Forum Infrastructure Working Group</span></h4>
<p><strong>Presenter:</strong> Jos Purvis, Cisco<br>
<strong>Notetaker:</strong> Robin<br>
The first item discussed by the Forum Infrastructure Working
Group was website content management. The website is going to
be reconfigured to add sections for each of the working
groups. The chair of each working group is going to be
responsible for maintaining their own content. The sections
will be divided to indicate subcommittees of working groups.
We will be adding minutes and ballots for each of the working
groups.<br>
The second item discussed was the wiki. We have an offer from
Microsoft to test out SharePoint. We also have a couple of
open-source, self-hosted options we can test, so the idea was
to test the options. When we have something set up, we’ll
migrate over a little bit of data and test and then make a
recommendation to the Forum as a whole.<br>
The third item was document management. We felt there were
several different problems. One was identifying the canonical
version of the Baseline Requirements. The EV Guidelines and
the Network Security document already have defined GitHub as
the canonical version. We discussed how to improve the
document management workflow for ballots. Tim volunteered to
put together a set of instructions on how to get a ballot from
idea into GitHub and to the Forum vote. Hopefully in working
on the process we’ll identify where we have problems, such as
identifying the canonical version of the Baseline
Requirements. We discussed whether to use GitHub or Word, but
before deciding on a process, we felt that we needed to
identify the canonical version first. We also decided that we
need to identify the what – “I need a red-line version, I
don’t care what format it’s in”, etc.</p>
<h4><span
id="3-Report-on-Governance-Change-Bylaws-Issues-1-Governance-WG-or-Subcommittee-2-Review-Bylaws-Change-List">3.
Report on Governance Change, Bylaws Issues: (1) Governance
WG or Subcommittee, (2) Review Bylaws Change List</span></h4>
<p><strong>Presenter:</strong> Jos Purvis, Cisco<br>
<strong>Notetaker:</strong> Bruce<br>
<em><strong>Allow the formation of a Bylaws Subcommittee</strong></em><br>
Ben pointed out that the work of the Forum was
compartmentalized into working groups in order to section off
IPR scope. In keeping with that, using a Working Group for
Governance seems the only way to go. Others agreed after some
discussion that IPR is bound at the Working Group level, so
there’s minimal IPR coverage for work done purely at the Forum
level. This is one objection to subcommittees at the Forum
level: that there is minimal IPR coverage for their work,
which could expose IP conflicts.<br>
The group then discussed whether a sub-committee or a Working
Group was the right model for this. The concern with a Working
Group was two-fold: the additional overhead from the
establishment and operation of a Working Group, and the
concern with pushing work on Forum-wide issues of the
Forum-level Bylaws to a Working Group operating as a peer of
the other WGs. There was some debate over whether the Bylaws
permit for subcommittees at the Forum level; the result of the
discussion was that work would begin on a ballot to clarify
the Bylaws to permit subcommittees with specific requirements.<br>
Wayne pointed out that if people felt strongly that this work
should be done at the Forum level, there wasn’t anything in
the Bylaws to prevent the Forum itself from holding a Forum
meeting specifically to work on the problem. After some
discussion, there was agreement that it was permissible to
hold a Forum meeting to tackle specific issues like Governance
questions, so long as it was an official Forum meeting with
all the usual trappings (agenda, schedule, minutes). This was
the suggestion to tackle these problems immediately while
working out the subcommittee issue with the Bylaws.<br>
<em><strong>Establishment of Subcommittees</strong></em><br>
Discussion then turned to subcommittees themselves. Dimitris
asked what to use as the model for subcommittees, and whether
to enact these rules at the Forum or the Working Group level.
The group agreed that it was important to spell out the rules
for how Working Groups and Subcommittees were required to
function, and that the charter of the SCWG had taken place
without fully spelling out those rules, which led to the
current conflict. The group agreed that it was important to
spell out the minimum requirements for the establishment and
operation of a subcommittee as a general requirement, with a
focus on transparency and general rules rather than being
overly prescriptive. Tim pointed out that we had a good
working model for this with the previous model for what we
used to call Working Groups (e.g. the Validation Working
Group), we just didn’t enforce them properly which led to some
WGs being better than others about producing things like
minutes. The group agreed after some discussion that the
minimum requirements for a subcommittee was the combination of
a public mailing list for discussions and minutes for any
meetings held, with those to be consistently and firmly
enforced. A remaining concern was whether to institute those
requirements at the Forum level or to make them at the SCWG
level first. Ryan suggested that we focus our efforts on the
work-output-producing groups first, which meant the
subcommittees of the SCWG, and then consider propagating those
requirements upwards into the Forum.<br>
<em><strong>Conflicts in Forum and WG Rules</strong></em><br>
Finally, Dimitris raised the question of whether the Forum
rules take precedence over conflicting rules from the WG
charters. Ryan pointed out there are two questions here: one
of conflicting rules, and one of lack of guidance. The group
agreed that conflicts in WG charters should be avoided by more
careful reviews of charters while establishing them; Ryan
added that a more specific list of requirements would improve
this (e.g. ‘must specify voting structure’, ‘must specify
mailing list requirements’, etc.).<br>
Tim indicated that a major problem with the Bylaws was a lack
of guidance over what rules applied only to the Forum, what
rules also were required to apply to Working Groups or
Subcommittees no matter what, and which rules were required to
apply to WGs if they didn’t specify anything else. That is,
which rules descended to WGs and which ones of those could the
WG decide to override in their charter. The group agreed that
the resolution to this was to review and revise the Bylaws to
add statements like “Working Groups must do X” vs. “Working
Groups must do X unless otherwise specified in the WG
charter”. We know the SCWG has this issue with the Bylaws
already, so everyone felt the group as a whole could begin
tackling the Bylaws for review immediately, without needing to
wait on the resolution of the Governance committee issue.</p>
<h4><span id="4-Potential-Amendments-to-SCWG-Charter">4.
Potential Amendments to SCWG Charter</span></h4>
<p><strong>Presenter:</strong> Tim Hollebeek, DigiCert<br>
<strong>Notetaker:</strong> Dimitris<br>
This topic was covered by the previous (slot #3) discussion.
There was consensus that the current SCWG Charter should be
amended to reflect the changes that we would like to see in a
CWG template. This review needs to take place along with the
review of the Bylaws.</p>
<h4>5. Creation of additional Working Groups – Code Signing</h4>
<p><strong>Presenter:</strong> Ben Wilson, DigiCert<br>
<strong>Notetaker:</strong> Arno<br>
Tim had sent the draft charter on 24.04.2018 to the
Mailinglist. Previously there were a set of CS guidelines
developed, but not adopted by the Forum. Governance reform
gives the ability to create a new, chartered working group.<br>
Ryan S – Regarding scope, it would be good to identify the
work in detail and then define the working group.<br>
Discussion followed on who should participate in a working
group and what user agents would be involved.</p>
<h4>6. Creation of additional Working Groups – Secure Mail;
Other</h4>
<p><strong>Presenter:</strong> Ben Wilson, DigiCert<br>
<strong>Notetaker:</strong> Kenneth Myers, Protiviti
supporting the US Federal PKI<br>
A Secure Email Working Group was first brought up at the
London meeting. We understand the multiple types of email
clients and the differing types of certificates. It might be a
good idea to have it scoped toward a specific application such
as a desktop mail client vs a web-based mail client.</p>
<ul>
<li>Ryan Sleevi, Google – This has the same pitfalls as the
code signing discussion. Secure Mail can also be regionally
specific such as a Euro profile based on specific crypto
algorithms and extensions. There could be multiple owners of
a Secure Email certificate private key such as a person, an
organization, or even an application. What is the most
pressing issue with Secure Email and I would suggest focus
on that. Maybe start with a certificate profile as a first
work product and then work on a baseline requirement after
that. In addition to specific EKUs and key sizes, what
should be the identity validation properties?. In an
enterprise RA model, maybe the user doesn’t manage or
protect their private key and they are stored in a cloud or
a multi-tenant environment.</li>
<li>Ben – Let’s hear from some of the Euro CAs and browsers
who have email trust bit enabled for their perspective.</li>
<li>Tim Hollebeek, DigiCert – One item of clean-up could be to
look at certificates that currently assert email and then
create a BR based on those.</li>
<li>Wayne Thayer, Mozilla – We are interested in email
validation requirements.</li>
<li>– We suggest maybe an approach similar to Adobe with
integration and recognition of QC signing certificates.</li>
<li>Ben – Do we want to carve out desktop from web email to
narrow the scope?</li>
<li>Ryan – The initial scope is the minimum set of
requirements to meet the current challenge. If the current
challenge is standardization of email certificates, start
with that. Then you can move onto identity validation,
private key protection, secure email validation, etc. We can
get to an end state with all these pieces, but I suggest a
solid foundation based on a profile to start.</li>
<li>Ben – It sounds like the initial charter should focus on
three aspects: profile, identity validation of email and
identity (host and local part), and private key protection.</li>
<li>Kirk Hall, Entrust – Is that enough to start drafting a
charter?</li>
<li>Ben – Yes, I can start a charter based on those three
principles.</li>
<li>Geoff Keating, Apple – Maybe start a CA Certificate
working group?</li>
<li>Ryan – We talked about this at London also. Start with a
limited number of working groups, find the commonality
between the groups and then work on common certificate
profiles. Instead of focusing on different CA conditions
such as CA = True and EKU = SMIME which may lead to having
separate roots which I think no one is interested in doing.</li>
<li>Wayne – Is your interest in a CA Cert working group, based
on a problem or a notion from the governance reform?</li>
<li>Geoff – It is based on governance reform. For example, if
we find OCSP may be a requirement of one CA type and not
another it may have to go through multiple working groups
and what if it fails in one and not another.</li>
<li>Dimitris Zacharopoulos, HARICA – This came up during the
Network Security Subcommittee discussion and we anticipate
this happening as more working groups are established. It is
better to approach the issue when it comes up rather in
theoretical.</li>
<li>Tim – A working group could simply be a mailing list and a
charter with no document management.</li>
<li>Ryan – IETF ran into this problem where they had multiple
groups with no products and caused confusion when trying to
update or create a new document because of the overlapping
scopes.</li>
<li>Kirk – Geoff, if you are interested in a CA Certificate
Working group, please draft a charter for the group to
discuss.</li>
</ul>
<br>
</div>
</div>
</body>
</html>