CA/Browser Forum
Home » Posts » 2014-10-02 Minutes

2014-10-02 Minutes

Minutes of CA/Browser Forum, 2 October 2014

1. Antitrust Statement was read.

2. Roll Call: Atilla Biler, Ben Wilson, Doug Beattie, Rich Smith, Mads Henriksveen, Jeremy Rowley, Rick Andrews, Joanna Fox, Dean Coclin, Kirk Hall, Annabel Lewis, Atsushi Inaba, Bruce Morton, Kelvin Yiu, Anup Chauhan, Tim Hollebeek, Dave Barnet, Ryan Sleevi, Robin Alden, Stephen Davidson, Tim Shirley, and Gerv Markham

3. Agenda reviewed.

4. Minutes of 4 Sept 2014 approved as corrected.

5. Membership Application of 360 Browser was approved.

6. Ballot review: Ballot 125 CAA, Ballot 123 Reuse of Information – Jeremy will send a redlined version that just tracks the changes, not the move. Ballot 136 Chair Election voting starts next week. Because we have all of these ballots, Ben will put together a little chart that shows the dates.

7. Draft Ballot 118 – SHA1 Deprecation (email of 9/17 re: Updated Drafts of Ballots). There was a November 10, 2014 deadline in the draft ballot prohibiting the sale of SHA-1 certs that live beyond 2017. Is that still Microsoft’s position? Rick: At the face to face, several CAs expressed concern that the November 10 deadline would not be achievable. They suggested a 3-month timeline. Doug: maybe mid to late January would be best for them. Bruce also had an issue with the release date. He would be able to do mid to late December. Doug: it will only be a couple of weeks after the ballot is approved. Kelvin: if we give it three months, then we are talking early January, so mid-January seems reasonable. Ryan: I think from a policy standpoint the auditable standard would be 3 months. Ryan seems fine with the three-month timeframe. Kelvin: should we have some kind of a minimum metric for CAs that want to delay for software changes? Ben: Can we go with a date in January? January 16? Ryan does not want to tie the date calculation into the wording for the ballot–that would make easy for a no vote. If you have concerns other than the date, it would be good to state them now. Seems like a quick and painless thing to go forward with. The ballot makes it so much easier to know what you are voting for. So, the proponent of Ballot 118 is Microsoft, endorsers would be Trend Micro and Google, and the ballot will go out after the call.

8. Draft Ballot 133 – Insurance for EV

Ben sent draft Ballot 133 out last night and is looking for comments. Kirk doesn’t think there should be an insurance requirement. Symantec needs to read it first, but in general we are supportive. Comodo will review it as well. Ben has edited this and toyed with the best way of replacing subsection (A) and has replaced it with a requirement for sufficient property casualty insurance for your CA. It would require coverage for physical assets, but not for intangible property. Atilla: it seems quite reasonable, content-wise, and on their side, they are getting feedback from insurance companies, so Turktrust would endorse the ballot. Ben: I realize that “adequate amount” is not auditable, and a sufficient amount would come from national law, so that amount might be different in different countries. In total, this ballot cuts down the insurance requirement by at least 4 million dollars on its face.

9. Draft Ballot 134 – Application of RFC 5280 to Pre-certificates

Kirk said the discussion online is no longer very fruitful. There’s too much of a technical discussion going on about what constitutes a certificate, and the other way that you can avoid this situation is by using an intermediate pre-cert CA. That raises questions about what’s expected of the intermediate pre-cert CA whether it makes changes to infrastructure necessary. The goal and the desire and the intended wording is that no CA should have to develop new software to have an intermediate pre-cert CA., but if you are using an intermediate pre-cert CA, you should have no problems with this ballot, since we as a Forum can decide. We can clarify that a pre-certificate with the same serial number does not violate the Baseline Requirements. Digicert would endorse this ballot. We just need one more. Google will endorse. Kirk: Then we can move forward with this as a ballot. Rich: does it say effective immediately? We can’t wait for the new audit regime to pick up the new requirement. Kirk: Yes – the last version proposed does say that it would be effective immediately.

10. Draft Ballot 135 – ETSI Auditor Qualifications

This morning we received updated ballot wording from Iñigo. Ben will take a look at the draft ballot and confirm that it is in order, and if so, circulate it as a ballot with some explanation.

11. Draft Ballot 137 – Voting Process Bylaw Amendment

Ballot 137 proposes a process to narrow the field of candidates for Chair and Vice-Chair. The latest discussion has been a request that the process not be too complex, Rich suggested an instant runoff. He doesn’t have a strong feeling about it, but personally feels like some form of an instant runoff would be good in that we are a consensus-based organization–any of the candidates would be perfectly fine, but it is something we should consider. Dean: we’re trying to make it simple and straightforward. Not only are we trying to make a bylaw change, but we also are trying to go forward with Vice Chair elections, too. Kirk: the ballot has a process in case you have a tie. If we suffer some kind of inconvenience in the future, we can always revisit it, so I think the existing language is good enough. Rich: we could do a single transferrable vote, not an instant runoff. If there were four candidates, a member would cast their vote with ranked preferences. Dean: We should just vote and be done with it. Ben: I added a few edits to the last version of the ballot to clarify the voting process and separated them into two different paragraphs-one for nominations and one for voting. Ben and Jeremy will get together and prepare a final proposal and send it out.

12. Draft Ballot 138 – Information Sharing Working Group

This is an issue that we have had a hard time cracking, so the proposal is that we create an information sharing working group with an objective of coming up with a proposal. A deliverable would be a document offered to the Forum for participating in an info sharing arrangement for security issues. In the past, people have raised legal issues/concerns, such as liability for libel if people are concerned that they are being blackballed, and we may decide that there’s no easy way for us to do this. We should be careful that the name of this working group does not imply that we are working on something that is anticompetitive. Ben will call Kirk after the call to discuss the working group’s proposed name. Digicert and Symantec will endorse. If anyone has additional edits, then they should post them online as quickly as possible so that there is enough time before this is posted as a ballot.

13. Discussion on Adding Policy OIDs for DV and OV certs

Dean asked to present this topic because we currently have a standardized policy OIDs for EV, albeit they are EV OIDs put forward by EV issuers, and we haven’t discussed the policy on requiring policy OIDs for DV and OV, even though the Forum has identified OIDs. There’s been an ongoing desire for relying parties to be able to tell the difference between OV and DV certificates. It’s also difficult for some organizations that report on certificates. Is there interest among members to make those OIDs mandatory? Ryan: we would be opposed to any ballot that mandates a BR or OV OID. There have been discussion in the past on the Mozilla list about necessitating OIDs, and the response has been that it doesn’t provide information to a relying party, but instead provides misleading information. Dean: I would like to understand that a little bit better, so I’ll start a thread to discuss this and maybe someone can cut and paste the Mozilla discussion into the thread. Ryan will revisit that. This is an initial discussion topic.

14. Any Other Business

Working Group Updates: There is work that needs to be done in all three groups. We need more volunteers for the Policy Review Working Group. Ben will send the RFC 3647 topic list out again and solicit volunteers before the Policy Review Working Group call next week. We could keep track of these RFC 3647 issues with bugs in Bugzilla and then people could be assigned to work on them.

Bugzilla: Members should become familiar with how https://bugzilla.cabforum.org/ works and what it can do. There are some statistical things to work out and some additional functionality that Gerv can add-things that were only available for version 4.2, but he will pass them on to Wayne for installation.

Upcoming Calls: You should have all received a meeting invite for the next four meetings, skipping Thanksgiving Day in the U.S., and we could move the meetings to a week later, if members want. Daylight Savings Time ends at the end of the October in Europe and in the first of November in North America, which the meeting invites should show, but just in case, the meeting after the last of October, first of November, will start an hour earlier after you go off daylight savings.

15. Next phone call - Thurs. Oct. 16

16. Meeting adjourned.

Latest releases
Code Signing Requirements
v3.8 - Aug 5, 2024

What’s Changed

Full Changelog: https://github.com/cabforum/code-signing/compare/v3.7...v3.8

S/MIME Requirements
v1.0.6 - Ballot SMC08 - Aug 29, 2024

This ballot sets a date by which issuance of certificates following the Legacy generation profiles must cease. It also includes the following minor updates:

  • Pins the domain validation procedures to v 2.0.5 of the TLS Baseline Requirements while the ballot activity for multi-perspective validation is concluded, and the SMCWG determines its corresponding course of action;
  • Updates the reference for SmtpUTF8Mailbox from RFC 8398 to RFC 9598; and
  • Small text corrections in the Reference section

Network and Certificate System Security Requirements
v2.0 - Ballot NS-003 - Jun 26, 2024

Ballot NS-003: Restructure the NCSSRs in https://github.com/cabforum/netsec/pull/35

Edit this page
The Certification Authority Browser Forum (CA/Browser Forum) is a voluntary gathering of Certificate Issuers and suppliers of Internet browser software and other applications that use certificates (Certificate Consumers).