[cabfpub] Final Minutes of CA/B Forum Call April 14, 2016

Thu Apr 28 13:52:59 MST 2016

Teleconference April 14, 2016

Attendees: Andrew Whalley (Google), Alex White (Cisco), Atsushi Inaba
(Globalsign), Ben Wilson (Digicert), Billy VanCannon (Trustwave), Bruce
Morton (Entrust), Dean Coclin (Symantec), Dimitris Zacharopoulos (Harica),
Doug Beattie (Globalsign), Eddy Nigg (Startcom), Geoff Keating, Apple,
Gervase Markham (Mozilla), JC Jones (Mozilla), Jeremy Rowley (Digicert),
Jody Cloutier (Microsoft), Josh Aas (Let's Encrypt), Josh Purvis (Cisco),
Kirk Hall (Trend Micro), Li-Chun Chen (Chunghwa Telecom), Marcelo Silva
(VISA), Mat Caughron (Apple), Moudrick Dadashov (SSC), Patrick Tonnier
(OATI), Peter Bowen (Amazon), Robin Alden (Comodo), Ryan Sleevi (Google),
Tim Hollebeek (Trustwave), Tyler Myers (GoDaddy), Virginia Fournier (Apple),
Wayne Thayer (GoDaddy)

1.       Roll Call completed.

2.       Antitrust Statement was read by Kirk.

3.       Agenda Reviewed.  

4.       Minutes of 31 March meeting: The minutes were approved with one
change submitted by email and will be sent to the public list.  

5.       Ballot Status: Ballots 165 (Governance Review Working Group) and
166 (change to membership bylaws) both passed.  

Peter discussed the content of the draft Ballot 168 on the contents of
Subject Alternative Names. The ballot addresses three things - the
definition of a wildcard certificate, allowing the use of underscores in
FQDNs, and introducing support for SRV names. The clarification for
wildcards  was originally part of Ballot 167, but removed because there
wasn't clear consensus. The goal of the ballot was not to change the
definition of wildcard certificates, but merely clarify the language, as
some members expected that it is a single asterisk followed by an FQDN,
while others saw confusion between "left-most position" and "left-most
label" language used in the BRs to permit forms of additional preceding or
following characters in the certificate ('ab*.example.com
<http://example.com> ' or "*ba.example.com <http://ba.example.com> ').
Underscore support was meant to allow them anywhere a dash can be used, as a
number of CAs are already issuing such certificates, presumably because
Microsoft hostnames can contain underscores, and so the proposal was to
allow them everywhere but the first and last character, which might
otherwise cause ambiguity with service identifiers in DNS. Finally, SRV
names allow scoping a certificate not just to an FQDN, but to a service or
protocol. There's a chicken/egg problem in that it's not widely implemented
because it's not presently allowed.

Dean asked for clarification on the wildcard, and whether this was related
to concerns with Microsoft's standards. Peter clarified Rick Andrews had
wanted to discuss with Jody about how Microsoft products behaved and what
they supported. Jody pointed out a TechNet article on the list and indicated
that's all his team knew.

Ryan explained the concern had been that CryptoAPI supports more liberal
form of wildcard matching, supporting everything described by Peter. Rick
had raised the point about whether this should be allowed to issue, since
Microsoft products supported it and it could be used there. This is similar
to the discussion of underscores - they're prohibited in hostnames by the
DNS RFCs, prohibited in TLS SNI, and prohibited in protocols like QUIC.
However, because the APIs for Microsoft's resolver supported more than just
DNS for name resolution, they weren't strict about validating these, and so
they just worked. In both cases, we have a set of standards - RFC 6125 or
RFC 1034 - that describe how things should behave, and implementations
diverge.

Peter pointed out it wasn't strictly Microsoft's resolver, and how companies
and services, such as Blogspot, had come to use underscores, as shown from
the Alexa Top One Million.

Ryan explained there were a number of interoperability concerns that had
been inherited from Microsoft's original behavior, so implementations
supported them despite the standard. However, there were a number of bugs
being tracked in Chrome, in the URL spec, and with the Mozilla Networking
team to try to clarify and correct these. When Mozilla implemented
enforcement for RFC 1034 hostnames, they ran into compatibility problems
because CAs weren't following it, and had to implement workarounds. It's
true that a number of implementations support it, but at least two browsers
are trying not to. A larger technical discussion about how the issue arose
ensued.

Peter pointed out that even if the specs prohibit it, it's still used
widely. Kirk indicated he was having trouble following the conversation and
understanding what was being discussed, and asked that Peter provide further
details about the ballot on the list. He pointed out that the original
ballot on April 8 goes straight to discussing the changes, and requested
that Peter instead provide details about the problem being addressed with
each change, how it's being addressed, whether there are problems
anticipating with the change, and if so, why it's not actually a problem.
Peter confirmed he could do that for the underscore change, but for the
wildcard change, he pointed out that this was a clarification matter that
had been discussed previously as a point of confusion, and wasn't meant to
be a change in behavior.

6.       Domain Validation draft ballot: Jeremy noted that the Validation
Working Group (VWG) had finished its draft ballot on domain validation
methods at BR 3.2.2.4, and had forwarded on the public list for comment.
Jeremy indicated the need to get public feedback on the proposal, and had
gotten some feedback after Ryan posted on Twitter. The VWG had already
received a number of suggested edits by email, and would consider at its
next meeting to move toward a final ballot.  He explained the background of
the ballot, and the desire to eliminate the "any other method" provision of
current BR 3.2.2.4(7).  Jeremy highlighted some changes to the existing
methods while reviewing. The use of domain contact information, such as via
WHOIS, now required the use of a Random Value, as did contacting one of the
well-known email addresses (hostmaster, postmaster, etc). The practical
demonstration of control, which used a file on a server, has now been
significantly restricted to use a /.well-known/pki-validation path. The
means for proving via DNS were established as using CAA or TXT records, and
two new methods - using a test certificate or a TLS handshake with a random
number - were also introduced. Peter emphasized that the current draft
ballot may not be perfect, but included many improvements and could be
further improved in the future as needed.  Kirk encouraged all members to
review the draft and get comments to the VWG by its meeting next Thursday.

7.       Governance Review Working Group.  Dean noted that creation of the
Governance Review Working Group (GRWG) had been approved by Ballot 165, and
asked which members wanted to participate.  Volunteers included Kirk Hall,
Virginia Fournier, Jeremy Rowley, Josh Purvis, Moudrick Dadashov, Peter
Bowen, Patrick Tonnier, Dean Coclin, and Andrew Whalley.  Dean stated he
would also send an invitation for additional volunteers by email and set up
the first working group call.

Dean noted that the GRWG may want to bring in experts as well to help the WG
review its options.  Peter asked if experts could participate without
signing the IPR, and said the WG might want to invite participation by
representatives of relying parties such as Adobe and Oracle, but they might
not be willing to sign the IPR.  Kirk stated that the Forum had invited
experts to make presentations at meetings before without requiring an IPR,
and they could perhaps be invited as guests or "witnesses" to help the WG.
Dean stated this could be discussed on the first call.

8.       Dean noted that ETA had applied for Associate Membership, and there
was a question from the last call and the list about whether Associate
Membership is the right category, or whether they should join as Interested
Party, and wanted to solicit feedback from the members. Kirk indicated that
Interested Parties can't come to meetings or on the call, but Dean pointed
out they could, if invited by the chair. Kirk proposed the distinction as
Associate Membership being about the Forum reaching out and inviting people,
while Interested Parties invite themselves, and suggested to get a single
representative from the financial services industry who would be responsible
for gathering the combined input from that industry, and communicating back
to all its constituents the views and actions of the Forum. He objected to
them joining as an Interested Party, if all they can do is participate in
Working Groups.

Peter pointed out that ETA is a trade association, not a standards
organization, and primarily one focused on lobbying, education, and US
public policies. Other standards organizations exist in the financial
services industry, like EMV or PCI, and they'd likely point out that ETA is
wholly independent from that. While it may make sense to have someone from
financial services, it's not clear that ETA is the right group, or
necessarily a technical group.

Tim raised concern about the idea of only having a single participant from
an industry. There's three different standards bodies, a trade group, and is
overall, a complicated industry. If all of these organizations wanted to
provide input, there should be a means for them to do so.

Peter stated that would point to an Interested Party being the right
approach. A key distinction about Associate Members is they get a seat at
the table for every meeting, which is the entire point for Associate
Membership. If we went with Associate Membership, the Forum would
effectively be expanded to the "CA, Browser, and Financial Services Industry
Representative Forum"

Kirk stated we need a resource for these activities, and we can't have ten
different resources. He suggested ETA could be responsible for taking the
feedback back to members of financial service industry, but that he didn't
think Interested Party was right, because they couldn't attend meetings or
calls.

Ryan disagreed, suggesting that ETA, as a non-technical trade association,
was unlikely be the group that could enact, respond to, or even be
supportive of change. As a trade association, their interests are not
necessarily security, but that of the interest of the members. He argued the
important discussions should be happening on the mailing list, and when a
member of any community might be impacted by the discussion, that they could
speak up and allow the chairs to invite them. The risk of a large number of
associate members is that the size of the meetings grows, impacting the
ability to accomplish work, and that it may prolong conversations past the
point a decision needs to be made. Interested Parties allows for more
discretion to address that.

Kirk pointed out the SHA-1 deprecation never went to a WG, and thus adding
Interested Party status wouldn't help. However, Peter pointed out that the
bylaws don't restrict Interested Parties to working groups; it allows them
full participation on the public mailing list. Kirk pointed out that the
SHA-1 discussion did happen on the public mailing list, but still caught
these parties by surprise. Peter then pointed out that they weren't
participating all, and that the problem was unrelated to the discussion of
Interested Parties. If we are to grow this Forum to address more parties
than just ETA, such as what Tim pointed out, then the mailing list is far
more scalable than the current phone calls and meetings.

Kirk emphasized he was just proposing allow one member from financial
services industry, and they should be responsible to communicate with all of
the constituents in that industry. Ryan pointed out that multiple people
have pointed out that there's more than one organization, and it's unlikely
the Forum could find just one to be responsible. If the Forum is to scale,
having a public discussion on the mailing list, with multiple distinct
voices representing their interests, is much more open and welcoming of
participation.

Peter then highlighted that the problem isn't just about financial services
- members have raised concerns about cable box manufacturers or consumer
electronics devices, such as BluRay manufacturers, who may also be affected
by SHA-1. So the decision here isn't about just one industry, but about how
to address the needs of many industries that may be affected and wish to
participate.

Dean suggested the governance WG should address this confusion between
Interested Parties and Associate Members as part of its activities, but then
highlighted the need to come to consensus and a conclusion on the specific
matter of ETA's application. Peter proposed that there's consensus on having
them as an Interested Party, so having them sign the IPR and participate on
the mailing list as a first step. If there are topics on the call or meeting
that they're interested in, they can talk to the chair, and the chair can
invite. Meanwhile, the Governance WG can work on providing better guidance
long term. Dean agreed that was a workable solution, and would take that
proposal back to ETA.

9.       PAG/IPR Status: Dean said the list of non-signed IPR agreements was
down to four.  He had done all he could to contact them, and three of the
four were totally non-responsive.  The fourth member still has the updated
IPR under legal review, but at this point the deadline has long passed, and
he suggested the four members be suspended, with access and posting rights
cut off until they signed the IPR, at which point they could be readmitted.
The other members agreed by consensus.  One member pointed out that its
legal team was uncertain about what is a "draft guideline" and a "final
guideline" as referenced in the IPR.  Peter suggested the Forum website be
updated to designate both the current version of the BRs and EV Guidelines
as "final guidelines), and noted there were currently no "draft guidelines"
as referenced in the IPR.  Ben stated he would update the Forum website to
reflect this, which may help speed up the legal review by one member.

10.   Validation WG Update: No further updates

11.   Code Signing WG Update: Dean noted there was a form of contribution
agreement circulating that WG members needed to sign so the final Code
Signing Baseline Requirements could become "creative commons" intellectual
property.  Peter noted that Microsoft had essentially adopted the Code
Signing Baseline Requirements as a requirement for code signing under
revisions to its root program rules, effective February 1, 2017.  Jody noted
that some have said the Code Signing Baseline Requirements can't be labelled
as a product of the CA-Browser Forum because the ballot for their adoption
failed, and wondered if Microsoft could name its version of the guidelines
the Microsoft Code Signing Baseline Requirements under the creative commons
rule - if not, what should they be called?  The WG will discuss by email.

12.   Policy WG Update: Ben said a ballot would come soon amending Sections
5.1 and 5.2 of the BRs, and possibly Sections 5.3 and 5.4 also. 

13.   Information Sharing WG Update: Ben said Virginia will talk on the next
WG call about some open issue relating to choice of law and antitrust
issues.

14.   Other Business: Dean stated that the Fall meeting date in Redmond has
been set for October 18-20, 2016 in Redmond, Washington near Seattle. He
noted that the Bilbao meeting is coming up May 24-26, and asked members for
Agenda items.  Mat noted he is leaving Apple, and indicated how much he had
enjoyed working with the other members.  Dean thanked Mat for his
contributions, and wished him well. 

15.   Next teleconference scheduled for April 28th 

16.   Meeting adjourned 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160428/887ddf21/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5747 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20160428/887ddf21/attachment-0001.bin 