[cabfpub] Final Minutes - August 4, 2016 CA/Browser Forum Teleconference

[Dean Coclin]

BEN-Please post to website.

*****

 

Updated Draft Minutes - August 4, 2016 CA/Browser Forum Teleconference

 

Attendees: Alex Wight (Cisco), Atsushi Inaba (Globalsign), Ben Wilson
(Digicert), Cap Hayes (Cisco), Doug Beattie (Globalsign), Geoff Keating,
Apple, Gervase Markham (Mozilla), JC Jones (Mozilla), JP Hamilton (Cisco),
Jody Cloutier (Microsoft), Josh Purvis (Cisco), Kurt Spann (Apple), Li-Chun
Chen (Chunghwa Telecom), Peter Bowen (Amazon), Rick Andrews (Symantec),
Robin Alden (Comodo), Ryan Sleevi (Google), Tim Hollebeek (Trustwave), Tyler
Myers (GoDaddy), Virginia Fournier (Apple), Wayne Thayer (GoDaddy).

 

1.            Read Antitrust Statement 

 

2.            Roll Call completed

 

3.            Agenda reviewed - no changes

 

4.            Approve Minutes of July 21st.  There were no changes suggested
on the call.  The following day, Ben suggested minor edits by email, which
will be incorporated in the Minutes as posted.

 

5.            Ballot status:  Kirk reported that Ballot 173 (removal of
requirement to cease use of private key) had passed by a large margin on
July 28, and reminded Members that they would probably need to make
corresponding changes to their CPSs and Subscriber Agreements within 45 days
(i.e., by Sept. 11, 2016)

 

Kirk noted that Gerv had posted a pre-ballot for Ballot 174 (amending BR
9.16.3 regarding procedures a CA should follow when the BRs are in conflict
with local law), and suggested the Members should review the pre-ballot
before it is formally started.

 

Kirk then raised the draft ballot on requirements for SRV names.  The
sponsor Jeremy was not on the call to give an update.  Kirk noted that an
entire section, BR 4.2.2, was deleted in the ballot, and asked why that was
included in this draft ballot.  Peter stated that this section had been
relevant when Internal Name certificates were allowed, but is no longer
relevant now that the period for Internal Server names has expired, and so
should be removed.  Ryan said this is part of ongoing cleanup of the BRs as
provisions expired, and noted that the final sunset date for Internal Name
or Reserved IP Addresses under BR 7.1.4.2.1 is October 1, 2016, when all
unexpired certificates must be revoked.

 

6.            Deadline for disclosure of subordinate CAs in SalesForce.
Peter asked if Mozilla was going to announce a new, extended deadline for CA
disclosure of all subordinate CAs in SalesForce, noting that various sources
had noted subordinate CAs not yet listed by the previous June 30 deadline.
Gerv stated that Mozilla had not taken action against CAs for undisclosed
subordinate CAs after the deadline because Mozilla staff were busy with
other projects and also wanted to make sure there were no errors before
taking action.  Mozilla is now discussing what actions to take.  Gerv
emphasized that all CAs should make certain they have disclosed all
subordinate CAs in SalesForce to avoid future problems.

 

7.            SHA-1 Procedure: Lessons Learned?  Kirk asked the Members for
any "lessons learned" from application of the existing SHA-1 exception
process to date.

 

Rick noted that the one application had been completed, but the current
rules said an applicant had to wait a minimum of 10 days for a response.  He
questioned whether a 10 day minimum is too little or too much.  Running the
Marc Stevens analysis program didn't take too long - could the review
process be shortened next time?  Ryan said 10 days was a minimum for Google,
as it performed other tests of its own, had to deal with the applicant's OU
issues, and the issuer had issues of its own that delayed completion of the
review. Ten days is necessary for feedback from the community.

 

Gerv noted that the current procedure states the notBefore date for the
proposed SHA1 cert may be up to 14 days in the future to accommodate the
review time, but wondered if this was too restrictive - there could be cases
where the notBefore date might need to be more than 14 days to allow
additional time for review.  Ryan agreed that having more lead time was a
goal, but the idea that the request could only be submitted with 14 days
left was either due to unintentional wording or a misinterpretation
(subsequently clarified below).  Peter said the 14 day maximum might come
from how the CA's CPS is structured, and not from the BRs or the procedure.

 

Ryan clarified that the 14 days comes from the request being able to set the
notBefore up to 14 days in the future from the submission of the request.
This is to avoid situations where a CA submits a request with the notBefore
as the same day at the request, but the CA's CP/CPS has a statement about
how they set the notBefore relative to when they issue the certificate,
which won't happen until the end of discussion. This allows at least two
weeks of discussion without the risk of another CPS violation, but Ryan
didn't think that concern was terribly significant, since by issuing SHA-1,
they're already going to be violating their CP/CPS.

 

As the Baseline Requirements don't require CA's make this statement, Ryan
said it was a concern only if the CA made such a statement in its CP/CPS.

 

Gerv asked if the procedure should change 14 days to 28 days to allow more
review time and greater flexibility (if a CA is concerned about violating
its notBefore CPS provisions, the CPS can simply be amended for a short
period if desired).  Ryan said he didn't see a problem with this.

 

Rick asked what would happen if review were completed in less than 10 days -
could the certificate be issued earlier than 10 days?  Gerv said if a CA
wants a notBefore date of 10 days, the CA can set it at 10 days, but the CA
can't change it later.  Or with a change, the CA can choose 28 days if it
wants to, and then live with that.  Ryan said there was a danger of a dual
CPS violation in choosing 10 days or 28 days depending on the CA's CPS, but
said this issue might be more hypothetical than real - do CPSs even specify
maximum notBefore dates now?

 

Gerv then noted there could be other alternatives - during the recent
review, Phillip Hallam-Baker had suggested serial numbers be generated using
"strict construction" for greater security.  Should this change also be
considered for future requests?  Tim Hollebeek said more cryptanalysis was
needed before making this change, as strict construction is more predictable
so may not be more secure.  Ryan also said he was concerned that CAs may not
implement strict construction correctly, and it would be better if CAs
introduced entropy-based numbering in their systems.  Peter agreed with Tim
that more analysis was needed, and raised further concerns related to the
truncation of hashes, since they need to be truncated to sit within the 159
bits available in the serial. He also raised a concern about unrelated hash
attacks; would it be better to use SHA-1 in this serial construction as
well? Perhaps this would be better for IETF feedback as a draft RFC
explaining a formal construction, to get broader feedback.

 

 

Ryan pointed out that unrelated hash attacks were largely related to hashing
the same message (such as in the case in TLS's concatenated hashes), rather
than the cascade of independent hashes.

 

Gerv said consulting with IETF probably was not worthwhile, as the window
for special issuance of SHA1 certs was closing.  

 

Ryan offered some lessons learned.  First, while there was only one sample,
the applicant seemed not to understand the dangers from continued use of
SHA1, so maybe there should be more industry education.  Second, the
applicant made the statement that the SHA1 certificates were not being used
in modern systems, but they were in fact being used on modern platforms.
Third, in the future there should be analysis of using the certificate
switching mechanism - for example, there are open source solutions from
Cloudflare and others for certificate switching, and applicants should
examine these options first.  This will be an additional question in the
future.

 

Peter stated the recent application showed we need greater coordination
between the Forum (which promulgates the BRs) and other groups that set
their own guidelines.  For example, the PCI Council (payments industry) does
things differently.  If multiple certificate policies apply to a common
community (e.g. when payment terminals using the same root set as web PKI,
cable boxes, etc.), there needs to be better coordination.  It may be
inappropriate to apply the same roots to solve multiple scenarios and
products.

 

Rick noted that PCI evolved alongside Web PKI, and in many cased PCI
customers and others simply grabbed existing trust store roots without
telling the CA.  The process evolved without much CA input.  Peter noted
that outside of the browsers involved in the Forum (who therefore are
involved in coordinating with CAs), there is very little in the way of
alternative root programs (e.g., for devices), and other users are simply
copying the Mozilla roots store for these other devices.  Can the Forum give
these other groups some guidance to avoid future problems?

 

Ryan thought there was an opportunity for the Forum to offer guidance.  Kirk
suggested the Forum come up with and publish a list of non-trusted roots
that could be used by others (devices, etc.) that would still be
WebTrust/ETSI audited at least as to common security issues (data centers,
etc.) for assurance, and recommend use of these roots with implementation
guidelines.

 

8.            New Members.  Kirk noted that Cisco had applied for membership
as a CA in September 2015, completed all requirements, and was accepted.
Later, Cisco delayed in signing the updated IPR agreement, and its
membership was suspended.  Cisco has now signed and submitted the current
IPR agreement.  Kirk suggested that Cisco should now be restored to Member
status, and asked if there were any objections.  There were no objections,
and so Cisco is again a full Member of the Forum.

 

Kirk then reviewed the status for membership of ComSign.  ComSign previously
submitted all necessary documentation, but there was a question whether its
current WebTrust for CAs was conducted according to the most recent,
applicable audit guidelines.  ComSign conferred with its WebTrust auditor,
who submitted additional documentation correcting the audit guideline
version to the most current and reaffirming that the most recent audit met
these guidelines.  Kirk suggested ComSign be confirmed as a Member, and
asked if there were any objections.  There were no objections, and so
ComSign is now a Member of the Forum. 

 

9.            Governance Change working group update.  Kirk noted that the
working group would have a face-to-face meeting at Google's offices in San
Francisco on Aug. 9th.  He noted that Dean had prepared an agenda, and asked
Ben if there was any further update.  Ben said there was no further update.

 

10.          Validation Working Group Status: Ballot 169 - Updated domain
validation methods.  Kirk noted that Ballot 169 was now in the voting
period, which would expire on Friday, and urged all Members to vote.

 

11.          Procedure for election of new Chair and Vice-Chair.  Kirk noted
that on the last call, Members had asked Dean to outline the upcoming
process for election of a new Chair and Vice-Chair, which Dean had done by
email dated August 2.  Dean noted his terms ends October 21 and Bylaw 4.1
says the Forum should start the lection process at least 60 days before
that, and also presented the following summary table:

 


Date

Period

Activity


Aug 4

7-28 days for Chair

On CABF call, review election process and announce nominations for Chair are
open (for 14 days).  Send email to management list also.  


Sept. 1

7-28 days for Vice Chair

Announce close of nomination for Chair and start of nomination period for
Vice Chair is open (for 14 days)  Ask Chair nominees for election statements
by Sept. 8


Sept. 8

14 days (regular ballot period)

Start ballot for election of Chair - one week comment, one week voting
(public if only one nominee, private voting if multiple nominees)


Sept. 15

 

Close of nominations for Vice Chair.  Ask for election statements by Sept.
22


Sept. 22

 

Close of voting period for Chair, announce results


Sept. 22 (don't want 2 ballots running at the same time)

14 days (regular ballot period)

Start ballot for election of Vice Chair - one week comment, one week voting
(public if only one nominee, private voting if multiple nominees)


Oct. 6

 

Close of voting period for Vice Chair, announce results

 

Kirk asked for comments or questions about the process, but there were none.

 

12.          Policy Review Working Group.  Kirk asked Ben for any updates.
Ben said on the last call the working group discussed possible solutions
when the "locality" for a subscriber in a smaller jurisdiction was in
conflict with the current BR requirements.  Ben had posted a possible
solution to the public list, and Robin had posted a response.  The working
group will continue on the issue.

                

13.          Fall Face-to-Face Meeting - October 18-20, 2016, Redmond,
Washington.  Kirk noted the approaching meeting dates, and asked Jody if
there were any updates.  Jody said he needed a complete list of attendees
for planning purposes, and asked Members to add their names to the wiki very
soon if they are attending.

 

14.  Any Other Business.  Kirk asked if there was any other business to
discuss, but there was none.

 

15.          Next meeting.  Kirk noted the next Forum teleconference would
be on August 18th.

 

16.          Adjourned.

 

 

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