[cabfpub] FW: Revised Final Sept. 15 Minutes

[Dean Coclin]

Although these minutes were approved, some issues were noted after approval.
Those corrections are included in this approved version.

 

Final Minutes September 15, 2016 (v2, revised 9/29/2016)

 

Attendees: Alex Wight (Cisco), Arno Fiedler (D-Trust), Atsushi Inaba
(Globalsign), Ben Wilson (Digicert), Bruce Morton (Entrust), Carolyn
Oldenberg (Globalsign), Curt Spann (Apple), Dean Coclin (Symantec), Dimitris
Zacharopoulos (Harica), Doug Beattie (Globalsign), Erwann Abalea (DocuSign),
Jody Cloutier (Microsoft), Josh Aas (Let's Encrypt), Ken Myers (US PKI),
Kirk Hall (Entrust), Li-Chun Chen (Chunghwa Telecom), Mads Henriksveen
(BuyPass), Patrick Tronnier (OATI), Peter Bowen (Amazon), Peter Miscovic,
(Disig), Phillip Hallam-Baker (Comodo), Ryan Sleevi (Google), Tim Shirley
(Trustwave), Virginia Fournier (Apple), Wayne Thayer (GoDaddy), Wendy Brown
(FPKI).

 

(Vice Chair Kirk Hall presided because Chair Dean Coclin was in a location
where he could listen only.)

 

1.           Roll Call

 

2.           Read Antitrust Statement  

 

3.           Review Agenda - no changes

 

4.           Approve Minutes of Sept. 1st - Kirk asked if there were any
edits to the draft minutes.  There were no edits, and so the minutes of
September 1 were approved and will be posted to the public list.

 

5.           Ballot Status

 

(a) Ballot 175 - Addition of given name - Kirk stated that Ballot 175 on
given names had passed on September 8.

 

(b) Miscellaneous edits to Ballot 169.  Kirk noted that several members had
noticed small typos in Ballot 169 as enacted, and had suggested corrections.
Ben said he planned to make the corrections soon.  Peter suggested maybe
this issue of corrections should be delayed until after discussion of the
IPR policy and our future plans on making any corrections.  Gerv recalled
that in the past we had some ballot language somewhere that gave the authors
of ballots editorial discretion to correct errors, and that might apply
here.  Kirk stated that he had previously proposed amending the bylaws to
allow something like a "consent ballot" where minor corrections like this
would be formally proposed to the members, and then if no one objected
within a certain period (e.g., 7 days), the corrections would be made.  He
thought a somewhat more formal process with a record of our actions would be
better than simple ad hoc corrections with no record, and would bring up the
issue in the Governance Change Working Group.

 

(c) OID needed for Test Certificate under Ballot 169.  Dimitris pointed out
that the new definition of Test Certificate under Ballot 169 called for the
CA to include "a critical extension with the specified Test Certificate CABF
OID" in the Test Certificates.  Kirk asked if this was meant to be a single
Test Certificate OID used by all CAs, or one unique to each CA.  Dimitris
said the natural interpretation was a single CABF OID used by all CAs, and
thought the Validation Working Group should get an OID assigned.  Doug
agreed.  Kirk noted the Validation Working Group recently became inactive,
but that he would talk to Jeremy Rowley about scheduling new meetings.

 

(d) Updating BR 3.2.2.5 (IP Address verification) to match Ballot 169.  Doug
had sent an email suggesting the validation methods for IP addresses in BR
3.2.2.5 be updated as appropriate to match the new validation methods for
domain names in BR 3.2.2.4.  Gerv agreed, and suggested the issue be sent to
the Validation Working Group.  Kirk will make this request to Jeremy Rowley,
who was not on the call.

 

(e) Draft Ballot 176 - Addition of CNAME verification to domain validation
methods.  Kirk noted that Jeremy had suggested amending BR 3.2.2.4 to allow
authentication of domain names by CNAME.  Jeremy was not on the call, but
Kirk noted there had been discussion by email of Jeremy's draft proposal,
and asked if members were close to a resolution.  Ryan said that Jeremy's
proposal was good, and Peter proposed some improvements.  We are now waiting
for Jeremy's revised proposal before proceeding.

 

(f) Draft SRV names ballot.  Jeremy has also proposed a ballot allowing SRV
names in certificates, but because he was not on the call, there was no
update.

 

6.           Miscellaneous topics:

 

(a) Inadvertent domain validation by email scanning applications.  Peter
pointed out by email that some email scanning applications click on links in
emails to check for malware, and that any CA using the email validation
method and confirming domain ownership or control via a simple one-click on
a link in an email could end up with inadvertent domain validation when no
person had actually clicked on the link to confirm.  The better option is to
require a second step, such as directing the subscriber to a page where
another button had to be clicked to prove domain control, requiring the
subscriber to copy and paste the Random Value in a field and send it back to
the CA, etc.  Kirk asked Peter if he wanted to propose a ballot to require
steps by CAs to avoid inadvertent validation by email scanning applications.

 

Peter, Phillip, and Dimitris discussed various technical methods that might
help prevent inadvertent validation.  Peter said he didn't think every
possible danger needed to be addressed in the BRs, and simply wanted to
alert CAs to this possibility.  Dimitris said a BR requirements might not be
auditable, and it might be better to post an article on the CABF website
concerning "best practices" in this area.

 

(b) Continuing the discussion on CAA.  Rick Andrews had asked by email what
the next steps should be for CAA, but Rick was not on the call so the
discussion was postponed.

 

(c) Questions regarding timestamping certificates.  Dimitris noted that BR
6.1.7 prohibits CAs from signing certificates with root CA private keys,
except for five specified exceptions.  Exception (3) allows signing the
following types of certificates with a root "Certificates for infrastructure
purposes (e.g. administrative role certificates, internal CA operational
device certificates, and OCSP Response verification Certificates)."
Dimitris asked whether time stamping certificates qualified as
"infrastructure purposes" and could be signed by a root.  (CAs must operate
an RFC-3161-compliant Timestamp Authority using a time stamping certificate
under Sec. 16.1 of the Code Signing Minimum Requirements, which is not a
CABF document.)  He thinks the current BR language is ambiguous.

 

Bruce thought it was a bad practice to issue time stamping certificates
directly from a root, and said that exception (3) could be amended to
specifically disallow them, or we could remove all examples from exception
(3).  Peter noted that there may be some systems that "expect" a time
stamping certificate to be signed by a root.  Bruce said he would be
surprised if it required the root to be a publicly trusted root for TLS
certificates.

 

Wendy noted that because code signing certificates require a time stamping
service, would there be the same objection to signing a time stamping
certificate from a root if the root were not publicly trusted.  Dimitris
said that issue probably should not be decided by this Forum, as some key
players in code signing certificates are not Forum members.  The Forum only
has jurisdiction over SSL certificate issues.

 

Bruce said members should look at the Code Signing Minimum Requirements
document again - that document has all the specifications needed on this
issue.  Dimitris said that was not a complete solution, as he has seen some
code signing certificate implementations that include a time stamping
certificate that was signed by a publicly trusted SSL root.  He thinks
that's a bad idea, and should not be allowed by exception (3) of BR 6.1.7.

 

Peter noted that the current BR 6.1.7(3) language could be interpreted to
allow this practice, and asked if the language should be amended to prohibit
it.  Dimitris noted the current language already allows for OCSP response
verification certificates to be signed by trusted roots.  Peter noted that
exception (5) for existing infrastructure situations had effectively expired
as of June 30, 2016.

 

Ben asked what a CA would do if it wanted a time stamping certificate to be
signed by a root.  Peter said the CA could either sign the time stamping
certificate from a sub-root of the trusted root, or sign from a non-trusted
root.  But he noted that signing a time stamping certificate from a trusted
root does not appear to be a prohibited practice under the BRs today.

 

Dimitris reiterated that he believes signing a time stamping certificate by
a trusted root should not be allowed under the BRs, and exception (3) of BR
6.1.7 should be amended to prohibit the practice.  Bruce asked the question
whether time stamping certificates qualified as "infrastructure" under
exception (3), and said it seemed not.  However, OCSP Response verification
Certificates did seem like "infrastructure" that would qualify for exception
(3).  Dimitris said he would draft a ballot to prohibit signing of time
stamping certificates by trusted roots.

 

7.           Governance Change Working Group update. Ben said the working
group had met by teleconference on September 13, and was still working on a
number of open issues remaining from the draft governance change proposal
discussed on the last CABF call.  These issues included a discussion of the
meaning of "affiliates" and how the IPR policy would apply to affiliates,
and also whether the IPR policies would apply to all forms of participation
in working groups or subcommittees, or not apply in certain limited cases
where it's not clear at the start that any proposals will result that could
involve IP.  

 

Virginia said the working group had a difference of opinion on this point,
and she believes the IPR policy should strictly apply to all CAB Forum
activity, including involvement in a particular working group or its
subcommittees - that's how the W3C IPR policy applies, for example.  If the
IPR policy doesn't apply at the start of a discussion, but the discussion
soon turns into a proposal involving IP, then the members can never know for
sure if they will be protected by the IPR policy and receive a royalty free
license. 

 

Ben noted that the current IPR Policy applies to all activities, which is
what we are trying to change.  Peter noted that under the draft proposal,
members must clearly participate in a working group and any of its
subcommittees for the IPR Policy to apply with respect to that working
group/subcommittee.  In further discussion, it was explained that the IPR
Policy would only apply to members participating in a particular working
group, and that members would not have patent obligations with respect to
working groups they do not participate in.

 

The next meeting of the Governance Change Working Group will be on September
27.

 

8.           Validation Working Group Status.  Kirk noted that Jeremy Rowley
had suspended further meetings of the Validation Working Group after the
passage of Ballot 169, but it would have to be restarted to deal with the
new issues raised on the call today.  He will talk to Jeremy.

 

9.           Policy Review Working Group.  Ben said the Policy Review
Working Group was reviewing other standards to see if the Forum should adopt
additional requirements to strengthen CAs.  At present the working group is
reviewing all the places in the BRs where the words "CA" and "Root CA" are
used to find multiple meaning for the terms, and perhaps adopt new terms for
clarity.  Dimitris said that "Root CA" generally means an organization that
functions as a certification authority, and "root certificate" generally
means an X509 certificate, but not always, which can be confusing.  The
working group will come back with a proposal.

 

10.         Application of current IPR policy.  Virginia discussed a
presentation she had sent to members on what the Forum's IPR Policy
currently requires.  In essence, the Forum should prepare new or amended
Guidelines in the following order: (1) circulate draft ballots adopting or
amending Guidelines, (2) send out Review Notices, (3) members identify
patents with Essential Claims, if any and file Exclusion Notices within
Review Period of 30 or 60 days, as applicable, and (4) proceed to a vote on
the ballot if no Exclusion Notices are received.  If Exclusion Notices are
received, then (5) the Forum should appoint a Patent Advisory Group (PAG) to
consider the notices and possible resolutions, after which a vote may be
held.  The Forum should follow this sequence exactly to get the benefits and
protections of the IPR Policy.

 

Kirk then stated that he and Dean would soon be forwarding a detailed memo
on this subject outlining how the Forum should readopt its current
Guidelines to be in compliance with the IPR Policy.  Peter noted that the
members had voted on Ballot 169 and received two Exclusion Notices after the
ballot, which meant that members did not know of the exclusions when voting,
although under the IPR Policy members should have been made aware of the
Exclusion Notices before voting on this ballot.  Virginia stated we would
likely need to form a PAG to evaluate the Exclusion Notices received.  Kirk
said there was some question of whether any past ballots would need to be
readopted. Virginia stated that all members were now on notice of possible
patent infringement claims relating to the Exclusion Notices filed for
Ballot 169, and should check with their attorneys to see what the
implications are for them.  

 

11.         Voting implications after CA or browser merger.  Kirk noted that
there were some pending mergers of CAs or browsers, and this presented the
question of whether both merged companies should still vote in the Forum (or
instead only one vote should occur).  He noted that Bylaw 2.2(b) says "Only
one vote per Member company shall be accepted; representatives of corporate
affiliates shall not vote."  Gerv said that Mozilla had outlined the
relationship between WoSign and StartCom based on public documents in a
posting, and suggested members could see the details for themselves.  He
noted that the Forum's IPR Policy has a definition of "affiliate", and asked
if the Bylaws had one.  Kirk said the Bylaws use the term affiliate when
discussion voting (members and their affiliates only have one vote), but the
Bylaws have no definition of affiliate.  

 

Peter noted that the same issue could arise from the pending merger of Opera
and Qihoo 360 once the transaction has closed.  He also stated that in some
cases a CA and a browser could be affiliated - Amazon has a CA division, and
a separate Silk browser division, for example (which are separate legal
entities under common Amazon ownership).  Kirk suggested this issue should
be referred to the Governance Change Working Group for proposals.

 

12.         Ballot 177 - Election of Chair.  Kirk noted that voting started
today for election of a new Chair, and that the candidates were Ben Wilson
and Kirk Hall.  Voting will end on 9/22/16.  Dean has outlined the procedure
for members to submit their votes by separate email to Don Sheehy and
Clemens Wanko who will tabulate the votes and announce the result.

 

13.         Ballot 178 - Election of Vice Chair.  Kirk noted that the
nomination period for Vice Chair opened a week ago, and would close that
day.  So far there were two nominees: Ben Wilson and Phillip-Hallam Baker.
Election statements from the candidates are due by 9/22/2016.

 

14.         Any Other Business - Kirk noted that the registration list for
the Fall Meeting in Redmond, WA (Oct. 18-20) was closed, but Dean and Jody
have a waiting list, if anyone else is interested.  He said that Dean and
Jody had called for Agenda items.

 

15.         Next Forum teleconference on Sept. 29th

 

16.         Adjourn

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161013/d0ca0674/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/20161013/d0ca0674/attachment.p7s>