Final Minutes for CA/Browser Forum Teleconference 27 April 2017 (as approved
May 11, 2017))
Attendees: Arno Fiedler (D-Trust), Atsushi Inaba (Globalsign), Ben Wilson
(DigicertBruce Morton (Entrust), Christopher Kemmerer (SSL.com), Connie Enke
(SwissSign), Curt Spann (Apple), Dean Coclin (Symantec), Dimitris Zacharopoulos
(Harica), Doug Beattie (Globalsign), Erwann Abalea (DocuSign), Fotis Loukos
(SSL.com), Frank Corday (Trustwave), Geoff Keating, Apple, Gervase Markham
(Mozilla), JC Jones (Mozilla), Josh Aas (Let's Encrypt), Ken Myers (US PKI),
Kirk Hall (Entrust), Mads Henriksveen (BuyPass), Masakazu Asano (GlobalSign),
Neil Dunbar, Trustcor, Peter Bowen (Amazon), Peter Miscovic, (Disig), Rich
Smith (Comodo), Rick Andrews (Symantec), Robin Alden (Comodo), Ryan Sleevi
(Google), Sissel Hoel, (Buypass), Tarah Wheeler (Symantec), Tim Shirley
(Trustwave), Tyler Myers (GoDaddy), .
1. Roll Call
2. Read Antitrust Statement
3. Review Agenda. The Agenda was approved.
4. (a) Approve Minutes of CABF teleconference of April 13, 2017 as amended.
The Minutes were approved.
(b) Complete F2F meeting minutes: Kirk noted that the following Minutes
segments had not been posted to the wiki, and asked the volunteers to complete
the missing Minutes:
Jeremy - Validation WG
Doug- Microsoft Program Update
Liang - 360 Update
Andrew Whalley - The Role and Relationship of the Forum
Kirk said he wasn't certain if anyone intended to post Minutes for the guest
presentation by Eric Mill - GSA update. He will ask Eric if he wants to
provide minutes or a summary. Kirk also noted that he had asked the leader of
each breakout group for the three Future of Web sessions to provide Minutes,
but none had done it so we will not provide Minutes for those sessions.
(c) Update on Cisco-provided WebEx account (Jos, Ben). Kirk noted that Cisco
had graciously created a WebEx account that the Forum could use for its
teleconferences and also for working group meetings. Ben and Dean said they
would try using the new account for some working group meetings first.
Credentials will only be provided to a limited number of leaders to avoid
misuse.
5. Governance Change Working Group update. Dean said the WG was making good
progress on draft amendments to the Bylaws. We will start using Webex on our
bi-weekly calls and the goal is to have a complete set of documents to
implement the governance changes by the time of the next F2F meeting in June.
6. Validation Working Group update. Ben said the WG had met the prior week
and worked on a number of draft ballots, which should be ready soon.
7. Policy Review Working Group update. Ben said the WG had a meeting just
before this Forum meeting, and continued to work on clarifying the use of terms
like CA, CA operator, etc. in the Baseline Requirements. They were also trying
to better incorporate RFC 5280 terminology in the BRs.
8. Draft Code of Conduct. Virginia was not on the call to review her draft
of the proposed Code of Conduct. Tarah, who had volunteered at the F2F to move
forward with this project, said she had reviewed the draft and thanked Virginia
for all her hard work. There were no comments on the draft from the members.
Kirk said the topic would be on the agenda for the next call, and he hoped
Virginia could participate on that call to provide an overview.
9. Ballot Status. Kirk noted the status of the following ballots:
Ballots in voting period: Ballot 197 - Effective Date of Ballot 193 Provisions
- Ends May 3.
Ballots in discussion period: Ballot 198 - .Onion Revisions - Ends May 1.
Ballot 199 - Require commonName in Root and Intermediate Certificates - Ends
May 2.
Ballots in IPR Review Period: Ballot 189 - Amend BR 6.1.7 to clarify signing by
root keys (ends May 15); Ballot 194 - Effective Date of Ballot 193 Provisions
(ends May 16); Ballot 195 - CAA Fixup (ends May 18); Ballot 196 - Define "Audit
Period" (ends May 18).
Kirk noted that other draft ballots had been listed on the Agenda, and asked if
anyone wanted to discuss any ballots during the call.
Ballot 198: Ryan said the ballot adds to the EV Guidelines the Tor service
descriptor because the onion name is essentially a truncated hash of the public
key used to identify hidden services. The subject is computed by generating a
1024 bit RSA key and hashing that with SHA1; the truncated hash of that is then
encoded and the onion name results. In the discussion as to why we are
permitting onion certificates, the goal is to ensure that there is no ambiguity
as to how the naming is done. In this ballot the goal is to ensure the certs
issued for onion clearly identified the public key that they are attesting to
so if someone is exploiting a SHA1 collision they will do so by generating a
different public key. A goal of the ballot is to put additional information in
the EV certificate to make sure you are going to the right site. In the
original onion ballot it was not a required extension, so the intent in this
ballot is to fix that oversight in the earlier drafting to make it mandatory.
Ballot 199: Gerv noted there was a discussion going on concerning the wisdom of
allowing a certificate to be reissued with the same name but different
metadata. Gerv noted his draft ballot would not permit this. Bruce had
suggested the use of the same name might be useful in some circumstances, but
had no concrete use cases - Gerv asked people to come forward if they had any.
Kirk asked Gerv why the ballot was originally proposed, and Gerv said it was
mainly housekeeping because the current rules would allow issuance of an
intermediate with no common name in it, which seems wrong if you want to avoid
ambiguity.
Ben asked if the ballot would prohibit reissuing a subordinate CA certificate
that had the same public key, same common name, but different metadata in it.
Gerv said that was what the current discussion was about. Ryan noted there are
a couple of attributes that arguably are in this gray area where we need more
discussion and feedback, such as cross-certification cases and AIA where you
later have to add that to assist in chain building. This needs to be discussed
because there are a lot of ways to reissue that cause negative security
consequences, so we need to figure out what the positive use cases are to
support those.
Bruce said Entrust definitely supported requiring common names. If the ballot
is just a clean up to put that in the BRs, then he supported it, but if it's
also a security ballot then he's prefer that discussion happen separately, as
the group has zero data on that. Ryan said the ballot is a little of both -
when you add the requirement of a common name you want to make sure you don't
introduce additional risk or challenge. Gerv thought that discussion might
take more time than was left for Ballot 199's discussion period. It would be
more than a minor change to add permitted use cases to the ballot a day before
voting starts. On this basis, it might make more sense to remove the
uniqueness constraint from this ballot and put in a future ballot. Ryan said
he saw a risk from someone reading these requirements and end up with the same
FQDN for two different logical CAs with two different keys - a CA in Taiwan had
run into this situation.
Gerv noted that the RFC key words used "should" for something you normally
should do, but where exceptions were permitted for a good reason - maybe that
should be used in this ballot instead of the current "must" for unique names
for now, and we can come back later and change that if we decide that is too
permissive. Ryan agreed. Peter mentioned the GIAG2 example of reusing the
same key and name with changing other things in the certificate, plus we have
seen several CAs change the key for the same name and use things like authority
key identifier to disambiguate any end entity certs - so changing "must" to
"should" in the ballot is a viable path forward.
Kirk noted there were about a dozen other pending ballots listed on the Agenda
and asked if anyone wanted to talk about any of them.
Mandating RFC 3647 format. Ryan noted he had put out two ideas (not listed as
a ballot on the Agenda) and wanted feedback. One touches on RFC 3647 and
mandating its format in CPs and CPSs. The current wording would require
updating to that format by December 8. One question was, should a CA's CP/CPS
use the same headings and sections as RFC 3647 - the Forum has done that for
its own Baseline Requirements, with "No stipulation" for those sections that
aren't relevant. We don't rename section headers, but may introduce new
subsections. Ryan asked if that was controversial, or there were concerns, and
would that make it harder to convert to the format over the next six months.
Ben asked if CAs could substitute certain words in RFC 3647 headings - e.g.,
change "Subscriber" to "User". Also, what if the CA is writing the document in
another language (even with an English translation) - you may need different
words and may not want to do a literal translation because it may not make
sense. Ryan said that was a good point - he had seen a translation from one CA
where they had introduced a Section 9 to cover issues like that, and it was
hard to understand in the English translation what they were doing. That kind
of substitution makes him nervous - he wants to make sure all information is
present and there is consistency, so he leans against it. There was also
discussion of RFC 3647 not using capitals in titles, except for the first word.
Ryan said he would update his draft in GitHub, and wanted more input.
Ballot re OCSP Profile. Ryan next mentioned another ballot concerning the OCSP
profile. He had floated a basic outline to capture a profile for OCSP
responses and requirements for OCSP responders. Under the BRs we put the
profile of how the request works and what sort of requests are generated and
other requirements in Section 4, but it's actually describing here's how the
request works fail to specify the OCSP Profile in Section 7. There is an
opportunity to clarify this.
We've got a lot of requirements in the BRs, some inherited from WebTrust for
CAs such as physical security controls, etc. In areas of "no stipulation", for
some there is nothing that can be said, but others were perhaps overlooked.
Some of the OCSP language in the BRs is outdated, plus there are some other
changes that would be useful regarding delegated OCSP responder certificates -
right now we don't have a specified maximum lifetime, and a compromised OCSP
certificate could compromise the whole revocation infrastructure system. Ryan
is working with GlobalSign to deal with RFC 5280's recommendation to keep such
delegated OCSP responder certificate lives short, such as 30 days for a maximum
validity period. Ryan would like more feedback on these proposals, some of
which could affect operations. We should first formulate an ideal end state
that all can accept, and then figure out how to get there - clearly we will
need time to implement any changes. We want a vision of OCSP that will
support stapling, high availability, and timeliness to help promote stapling.
Ballot 190: Ryan asked if Ben knew what the status of Ballot 190 on validation
methods was - it had been withdrawn over concerns with Section 2. He noted
Peter had suggestions on how to incorporate Section 2 into Section 1. Gerv
said he wanted to see Ballot 190 move forward, and offered his help. Ben said
Jeremy had been busy which had caused the delay. Ryan also offered to help.
Kirk noted he had drafted language to incorporate Section 2 into Section 1, and
would resend to the list.
Membership Rules Ballot. Gerv raised his membership requirements cleanup
ballot and asked if there were endorsers. Kirk mentioned some comments he had
forwarded - membership suspension for CAs would occur exactly 15 months after
their last WebTrust audit, which might be too soon as audits are due no later
than 15 months after the last audit, and there can always be last minute delays
with the auditor. Gerv noted that suspension is a light-weight process that is
easily reversed, so that should not be a great concern if an audit is a little
bit late, and it's better to match the time period with the audit requirement
date.
Kirk said his second concern is that the new membership suspension rule is not
self-enforcing - how does the Forum learn a member is in suspended status, how
is notice provided, what is the effect on a vote, etc.? He suggested a
procedure be included to determine all this publicly, and made suggestions in
his email to Gerv. Geoff agreed it was necessary to have membership status
known at the time of a Forum vote, and not challenged later. Gerv discussed
how the rule would apply to a CA with multiple roots where the audits were late
for some but not all roots. He will draft an updated ballot.
10. Next F2F meetings: June 20-22, 2017 Berlin (D-Trust) - Arno said the Forum
had invited Dr. Jens Bender from "Bundesamt für Sicherheit in der
Informationstechnik Referat D13 - eID Technologies and Smart Cards" to be our
speaker on topics like e-Identification, eIDAS and Website Certificates. We
will finalize the title of the lecture in May.
11. Preliminary discussion F2F Agenda - June 20-22 Berlin. Kirk asked if
anyone had preliminary ideas for the next F2F agenda. Dean thought the
breakout sessions on the Future of Web PKI and GitHub training in North
Carolina had been useful, and suggested we might want another session on
Network Security requirements in Berlin. Gerv thought it might be better to
wait a bit before more breakout sessions as we did for the Future of Web PKI,
but wondered who was going to follow up on the discussion about Network
Security at the last session.
Dean recalled that several people had intended to move forward on a possible
replacement for the Network Security requirements, possibly through a new
working group or subcommittee. Gerv thought two or three people were going to
come back with some specific ideas. Ryan noted that Jody is a fan of CI
Security, and he thought people were going to look at those standards in depth
and try to figure out if they would be a good starting point for the Forum,
plus talk with the auditors about possible changes.
Kirk asked if the Forum should create a new Security Controls working group to
work on this. Dean noted there had been interest in this, but there was
already a lot going on. He suggested adding new Security Controls as its own
topic again at the next F2F, but this time with some concrete action plans for
moving forward. Kirk asked members to provide suggestions for other full
sessions in Berlin.
The last F2F meeting of the year would be Oct. 3-5, 2017 in Taipei, hosted by
Chunghwa Telecom. Dean noted the hotel for the meeting had been changed, and
the updated information was on the wiki.
12. Any Other Business. Wayne noted that the Forum's email server had crashed
two days in a row, so delivery of some messages would be delayed.
13. Next call May 11, 2017
14. Adjourn
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
