CA/Browser Forum
Home » Posts » 2015-05-28 Minutes

2015-05-28 Minutes

CA/Browser Forum Minutes of May 28, 2015 Attendees: Atsushi Inaba, Atilla Biler, Ben Wilson, Billy VanCannon, Bruce Morton, Connie Enke, Dean Coclin, Doug Beattie, Gerv Markham, Jeremy Rowley, Jody Cloutier, Kubra Zaray, Mads Henriksveen, Mat Caughron, Patrick Tronnier, Peter Miscovic, Rick Andrews, Robin Alden, Ryan Sleevi, Sissel Hoel, Tim Hollebeek, Tim Shirley, Volkan Nergiz, Wayne Thayer

  1. Minutes of 14 May meeting were approved. These will be posted to the public list.

  2. Ballots

Ballot 149: Kirk was not on the call. No update.

Legal Existence by Attorney Opinion Letter (proposed ballot 150): Jeremy had sent out this proposed ballot which Ryan commented on. Ryan said he was satisfied with the responses for now.

Optional OIDs for IV (proposed ballot 151): Dean is working on a ballot with Jeremy and will send out shortly

Domain Validation Ballot: still in the working group. Jeremy said there are 2 types of ways to form the domain name you are validating: (1) by either taking the FQDN and removing parts/labels until you get down to whatever name you want to validate or (2) by only validating the base domain. There has been a debate on which one to do. For example mail.secure.example.com or example.com. You can validate by sending to secure.example.com or by pruning to example.com. The working group feels that they prefer the “pruning” method to make it consistent but wanted to run it by the broader forum for input. Jeremy will circulate this by email to the forum. Robin said he suggested an amendment to the proposal but hadn’t seen it incorporated. Jeremy will review again.

  1. EV Wildcards: A discussion around what the info in EV certs should represent began. Dean started by saying the 2 options were that the info should represent the owner of the website business you are communicating with or the entity hosting the website (i.e. Akamai). Ryan said the EV guidelines are vague as to what piece of information you should be validating. He went on to give examples of the different parties at play in hosting a website: domain holder (actual registrant or someone from say a whois anonymizing service), entity operating name servers, webhosting entity, Intermediate DNS holder/CDN provider (i.e. Cloudflare), design firm for website, and payment provider for website. Hence it is a complex question. In the context of wildcards, who is an EV certificate saying something about? This is where some of the concern comes in. Hence we need to decide who we want the information in an EV certificate to say about. Then we can discuss how wildcards play a role. Gerv agreed there are multiple parties that could demonstrate domain control but said the party of interest is the business owner, who would have contracts with the other parties. Hence he felt that the name of the party in an EV cert should be the entity responsible for the content in the site. Dean agreed and said this is all about establishing identity. Jeremy disagreed and said it should be about the owner of the private key which could be a CDN and they should be named in the cert. Rick said what good is a cert that says “Akamai.com” for a business that is not Akamai? Jeremy said it tells you who owns the private key. Gerv asked how is that useful? Ryan said this information is not consistently presented to users across browsers. He also cited an example of someone using AppEngine where theoretically Google could see all communication since they terminate the SSL session. Someone might want to know that. Gerv said it is impractical for certs to list all the parties that Ryan outlined above and reiterated that the info should be the one that is most useful to users of that website. Jeremy disagreed with that premise. Wayne questioned that for example hundreds of thousands of sites hosted by GoDaddy should be issued to GoDaddy? That didn’t make sense. Bruce said when the guidelines were created, it was to give the user strong evidence that they were on the site they thought they were. Jeremy agreed and hence hasn’t embraced wildcards on EV. Dean said that when you call your bank today, they may outsource the call center to a third party. They don’t necessarily disclose this and for most people it’s not an issue because you know you called your bank on the number they gave you. Hence the 3rd party isn’t relevant. The bank has a contractual agreement with the 3rd party and that should cover you. How does it help you to know that info in the SSL certificate? Ryan agreed but says it does (rarely) come up with some users. He also said one of the arguments against wildcard certs, for example, *.appspot.com, shouldn’t be allowed for EV because now you are communicating that all of the certs are operated by appspot. However, appspot could get EV certs for each of those domains that indicate you’re communicating with appspot, which may not be what you expect.” Jeremy said that would be true in any case. Ryan said it is true but it may not be what you expect. Tim H said he also would like to clarify what’s in an EV cert and that things like *.appspot.com should not be allowed. Gerv agreed and said the point of an EV cert is to know who you are talking to. Discussion was terminated due to time constraints.
  2. 2016 F2F meeting locations: Dean said he had offers to host from 2 parties, one in Europe and one in the USA. We are looking for a 3rd potential host, perhaps but not necessarily in Asia. Dean asked for volunteers to send him a note.
  3. Validation Working Group: No further updates other than domain validation.
  4. Code Signing WG: We now have a final document which the group is giving a final review. Then it will go to the public forum mailing list for final feedback. A ballot will follow.
  5. Policy Review Working Group: In the last call, the group went through the document and determined where to add “No Stipulation”. Ben will circulate a ballot to the working group.
  6. Info Sharing Working Group: No activity
  7. Other Business: Zurich F2F is up to 35 attendees. We are reaching capacity. Telephone conferencing will not be available. Dean suggested using Skype with an external speaker. One attendee on the list is an Interested Party. Discussion ensued on that but there were no objections.
  8. Next meeting: June 11th.
  9. 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).