[cabfpub] Final Minutes CABF Teleconference August 18, 2016-CORRECTION

Sat Sep 3 05:04:18 UTC 2016

Corrected to add Kirk to Attendee list.

Final Minutes CABF Teleconference August 18, 2016

Attendees: Andrew Whalley (Google), Atsushi Inaba (Globalsign), Ben Wilson
(Digicert), Bruce Morton (Entrust), Cap Hayes (Cisco), Curt Spann (Apple),
Dimitris Zacharopoulos (Harica), Doug Beattie (Globalsign), Eddy Nigg
(Startcom), Geoff Keating, Apple, Gervase Markham (Mozilla), JC Jones
(Mozilla), Jeff Stapleton, Wells Fargo, Jeremy Rowley (Digicert), Jody
Cloutier (Microsoft), Kirk Hall (Entrust), Li-Chun Chen (Chunghwa Telecom),
Mike Johnson (Digicert), Neil Dunbar, Trustcor, Patrick Tonnier (OATI),
Peter Bowen (Amazon), Peter Miscovic, (Disig), Robin Alden (Comodo), Ryan
Sleevi (Google), Tyler Myers (GoDaddy), Virginia Fournier (Apple), Wayne
Thayer (GoDaddy).

1. Read Antitrust Statement 

2. Roll Call

3. Agenda Reviewed - no changes

4. Minutes of August 4th.  Ryan noted he had just sent out proposed edits to
Sec. 7 of the Minutes of August 4.  Kirk suggested the members defer
approval of the Minutes as edited until the next CABF call so a revised
draft could be circulated.

5. Ballot status:  

Draft SRV ballot - Jeremy said he would proceed with the draft SRV names
ballot that was previously discussed if there was support from other
members.  Peter said he would take up the next draft of a ballot, as further
edits were needed.  He gave a brief explanation of the ballot - its purpose
is to specifically allow CAs to include SRV names in a certificate if the
customer want it - that is not permitted under the BRs today.  Peter
explained that SRV names are useful were the customer wants to specify not
only the FQDN but also the specific service the certificate is to be used
with (e.g., web server, etc.).  The technical specifications are already
laid out in one or more RFCs, but SRV names can't be used by public CAs
under the BRs today.  

Ballot 173 - Modification of the subscriber requirement to cease use of
private key.  Kirk noted that this ballot had passed by a large margin, and
would take effect after 45 days.  That means that many CAs may need to
modify their CPS and Subscriber agreements by Sept. 9, 2016 (unless they
prefer to keep the more restrictive terms in place).

Ballot 174 - Compliance with local law.  Kirk noted that this ballot is in
the discussion period, and voting will start on Monday, Aug. 22.  Gerv
explained that this ballot amends BR 9.16.3 (Severability) to clarify a
process by which a CA may comply with local law even though it conflicts
with a provision of the Baseline Requirements, and lays out an improved
method of how the CA can give notice of the conflict to the public and the
browsers so they can decide what, if anything, to do in response.  Gerv
added that the current BR 9.16.3 is drafted in a way that it is never likely
to be invoked.

Updated Version of BRs posted - Ben noted that he had just posted to the
CABF wiki and to GitHub an updated version of the Baseline Requirements
including all changes through Ballot 169 (domain validation methods), and
invited other members to confirm that the information is correct.  Kirk
thanked Ben for his hard work on this and other projects.

6. Ballot 169 (domain validation methods) and IP disclosure.  Kirk stated
that Ballot 169 on domain validation methods had been approved, and in
response Dean had sent out the required IPR Review Notice to members by
email on August 10.  The notice states that the IPR review period ends on
Sept. 15, 2016, so if members want to avoid granting royalty free licenses
relating to Essential Claims, they should make the required IP disclosure
notifications by that date.

Peter noted that the current IPR policy only requires members to send IP
notices to the Chair, and asked if Dean would create a list of IP notices
received and post it publicly so others could know what notices were
received.  Kirk said he would pass this request on to Dean.

Gerv asked what would happen if a CA has already posted an IP disclosure on
an earlier version of the BRs (e.g., for an earlier version of BR 3.2.2.4
governing domain validation methods) that was previously changed by ballot -
would the CA have to make the same IP disclosure again after Ballot 169?  He
expected the answer was yes.  Kirk agreed the wisest practice was for a CA
to re-post - otherwise, there could be risk.

Peter noted that our current IPR disclosure policy requires a CA to specify
which section of a BR the CA's claim of IP applies to.  On this basis, even
if a CA has reported IP for a particular BR section as to an earlier version
of the BRs, once the BR language or section numbering changed, in his
opinion a new disclosure was required.  He noted that a new IP disclosure
had been required following adoption of the updated IPR policy v1.2, but
that according to the CABF wiki, only one new "active" IPR disclosure had
occurred (from Symantec).  Ben said that for historical reasons, we have
been leaving previous IP declarations posted on the wiki.  Jeremy noted that
our updated IPR policy also redefined what was an Essential Claim, so more
declarations will be needed now that we have eliminated the "any other
method" subsection for domain validation methods.

Peter agreed, saying the current IPR policy provides that each permitted
method must be evaluated on its own, meaning each domain validation method
is an Essential Claim, and any conflicting IP must be disclosed.  Ryan
agreed.  Peter noted that Ballot 169 added new sections and modified old
sections, so that new IP disclosure requirements would probably be triggered
as to all sections.  Ryan added an example - suppose a CA had made an
earlier conflicting IP disclosure for old domain validation methods 1-6
under IPR v1.2.  Now, methods 1-6 have been rewritten, and we have new
methods 7-10 - CAs should review the text of all ten methods to determine if
they have a new duty to disclose (particularly as to validation methods
7-10, which are totally new).  Peter added that BR 3.2.2.4 was totally
reorganized by Ballot 169, so reference to any prior section number in a
prior disclosure probably was no longer accurate, which would be another
reason for renewed disclosure of conflicting IP in a disclosure.

7. Governance Change Working Group update. Kirk noted that there had been a
productive face-to-face meeting of the Governance Change Working Group on
Aug. 9th, and that the Working Group had developed a set of tentative
recommendation at the meeting which Ben had sent out by email on August 16.
He asked Ben to provide an overview of the Working Group's tentative
recommendation for feedback, and Ben provided the overview.  Gerv said that
Mozilla was cautiously positive about the proposal, and congratulated the
Working Group on its progress.  He added that it seemed odd to name the TLS
server certificate working group the "Web" Working Group versus "Server", as
its focus would be on server certificates, and suggested the name might be
changed.

Kirk noted that the Working Group had received suggestions for creation of
additional working groups beyond Web (or Server) Certificates, S/MIME
Certificates, and Code Signing Certificates, but couldn't recall the
suggestions.  Patrick said he had recommended also creating a Client
Authentication or Devices Working Group.

8. Validation Working Group Status - status of ballot on BR 7.1.4.2.2 -
givenName and surname (IV or Individual Validated certificates).  Kirk asked
Jeremy for an update.  Jeremy said he had just sent out his previous draft
ballot to the list, planned to move forward with the draft, and was looking
for endorsers to proceed.  

9. Policy Review Working Group - Kirk asked Ben for an update on the working
group's recent discussions.  Ben said the group was considering email
comments and drafts relating to changes requested by Chunghwa Telecom to
deal with requirements relating to locality and state certificate naming
protocols in some smaller political subdivisions.  There could be conflicts
with nomenclature standards of ISO.  

[Immediately after the call, Ben updated the current status by email,
stating that Li-Chun has requested an amendment to BR Section7.1.4.2.2d/e to
make localityName and stateOrProvinceName optional when the
subject:organizationName and subject:countryName fields are present if "(b)
the country/jurisdiction specified by the subject:countryName field has a
centralized registry that ensures that the organization name specified by
the subject:organizationName field is unique in the entire
country/jurisdiction."  He said the working group was still working on this.
Similar changes would be needed in the EV Guidelines too.]

Peter stated there are also some CAs who are trying to follow another naming
standard outside of the BRs (e.g., a government identity standard for tax
purposes, etc.) which could be viewed as a BR violation.  As an example, he
mentioned a UK tax requirement some years ago to insert certain identifying
data in a specific type of certificate.  He said that the tax authority in
Taiwan didn't want CAs to insert data in the L or S fields as it wasn't
needed in Taiwan.  Kirk wondered if a similar conflict with the BR
requirements could occur with the new eIDAS certificate requirements in the
EU, and Peter agreed.

Ben said the Policy Review Working Group would continue working on the
issue.

10. Any Other Business - Fall Meeting -Registration, call for Draft Agenda
items.  Kirk again stated the next face to face meeting would be on October
18-20 at Microsoft's offices in Redmond, WA, and asked anyone who is coming
but has not yet signed up to sign up on the wiki immediately to help Jody
with meeting planning.  He also asked the group to forward any meeting
agenda items to Dean.

11. Next meeting on Sept. 1

12. Adjourn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160903/81f6642c/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5723 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160903/81f6642c/attachment.p7s>