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

2015-05-14 Minutes

Minutes May 14, 2015 Attendees: Dean Coclin, Ben Wilson, Doug Beattie, Gerv Markham, Atsushi Inaba, Kirk Hall, Atilla Biler, Bruce Morton, Burak Kalkan, Cecilia Kam, Davut Tokgoz, Volkan Nergiz, Rick Andrews, Moudrick Dadashov, Eddy Nigg, Mat Caughron, Tim Hollebeek, Patrick Tronnier, Billy VanCannon, Jeremy Rowley, Robin Alden, Ryan Sleevi

  1. Minutes of 30 April meeting were approved. These will be posted to the public list.
  2. Ballots: Ballot 149 (Bylaw updates from Kirk): Kirk wants to hold the ballot until the WebTrust audit team determines what the new name of the audit will be.
  • Domain Validation Ballot*: There are a few open issues on this ballot:Working on revising #10 from the list. Some folks were concerned with the “test cert” provision. Tim H said the test cert should be allowed and that #10 needs to be tightened up. A longer discussion in the working group is warranted. Kirk also said it needs more details to make it more like methods 6-9 (which are explicit). Ryan also agreed. Jeremy said he put Doug’s proposed method in the proposal for now.

The “random value” was 128 bits but Kirk wanted it back to 112 bits. Kirk said that 128 bits was overkill. The random value is provided by the CA to applicants so it’s not practically predictable by hackers. Kirk felt the lower value is adequate (and is commonly used for some other purpose). Ryan disagreed and said there were threats like reversible random number generators and things like passive observation which may allow for reconstruction of the RNG. He would like to see the standard to be 128 bits. Tim said he also had these concerns but after looking into Java Secure random generator (which apparently doesn’t do 128 bits) he felt it was cryptographically secure and is no longer concerned. Gerv said the cryptographic strength of the generator is more important than the bit size but feared that specifying a smaller key size would lead people to use a less secure RNG. Kirk challenged the security issue. Ryan further explained (and said we should err on the side of caution) that a network based adversary could observe traffic sent to a CA’s customer and (theoretically) predict a random number challenge sent to a future customer and cause a miss-issuance which is not the CA’s fault. Gerv suggested a compromise of specifying a cryptographically strong random number generator (with a lower key size) instead of specifying a higher key size (which would include the Java generator but not the Windows GUID generator). Doug said an adversary could submit an order and get a random string back w/o monitoring the network (Ryan’s example threat). Ryan said it depends on the type of cert (OV/EV vs DV). Rick said how would an auditor determine if a RNG is cryptographically secure. Ryan said in theory they should but in reality, recent reports and events prove they probably don’t. But he said it could be an auditable requirement. Tim H. said that in the financial industry, this type of thing gets audited all the time. Kirk said this is not the place we should be focusing this type of effort. Ryan asked what harm a requirement for 128 bits would cause. Kirk said what CAs are using today may not meet that requirement and it would be a wasted effort to get people to switch for no real benefit. Ryan said there are already requirements for cryptographically strong random number generators but Kirk said for this issue, it wasn’t that important. Discussion was terminated due to time constraints.

#6 Anoosh commented (in a thread) that he doesn’t like the well-defined path item.

  1. Membership Application, China Financial Certification Authority: We have received an application CFCA. IPR was signed and they appear to meet all the CA membership criteria. Dean to double check with the applicant to make sure the signed is authorized to sign on behalf of the company. Otherwise, the application was conditionally approved. Mat asked if there was a relationship between this entity and the Chinese Government and wondered if there were other Government owned CAs in the Forum. Atilla said that the Government CA of Turkey under Tubitak, is a Government owned CA. Mat thought it might be helpful to put those CAs in another category. Dean said Izenpe is also owned by the Spanish Government. Gerv asked if CFCA were a Government CA, would we treat their application differently? The answer from the floor was no. There is nothing in the bylaws that state that. Mat said it would be helpful to understand which companies are public and which are owned by Governments. Especially when security incidents occur, private companies may be motivated to act differently. Dean suggested we discuss this further on another call or F2F meeting and we approve this request as is. Kirk suggested we ask in our application whether or not it is a Government applicant. Gerv said it isn’t relevant to their application and we should not ask it there. A discussion ensued on who audits Government CAs because sometimes it’s not a 3rd party auditor but ended w/o conclusion. Mat said the cross signing habits of Government CAs and Company CAs are different and this should be noted for the browsers when managing the risk.
  2. Optional OIDs for IV and EV: Dean said we don’t have optional OIDs for IV and EV (but we do for Domain validated and “Identity” validated) in the BRs and suggested we add these OIDs in section 9.3.1. Moudrick supported this approach. Dean said Jeremy would have to request these OIDs as he is the CA/B Forum “OID custodian”. Kirk said it was probably a good idea and said that the current OID for OV doesn’t say OV but rather “Identity Verified”. Jeremy said it was because it encompassed both IV and OV. But now it can be separated. Eddy also endorsed. Dean suggested that he and Jeremy work on a ballot.
  3. Qualified Auditors: Jeremy would like to see auditors be “certified” and he will circulate some language around this. Apparently this came from Jody so Jeremy will work with him on a discussion email.
  4. EV Wildcards: This came up at the last face to face meeting. There were arguments for and against adding wildcards for EV at that time. Ben said that EV was originally based on anti-phishing and wanted certs to not have misleading info in the server name. Ryan said that a hosting site (i.e. appspot, azure, aws) could have *.appspot.com issued to Google Inc while hosting subdomains representing different logical organizations. Gerv said this might “mislead” people into who they were dealing with. Ryan said that he doesn’t agree with the cons on this. Gerv suggested we try to reach consensus on what is the goal of the information in the certificate. What does it represent? Ryan agreed and said that this is a separate discussion. Dean said wildcards are currently forced on the least authenticated customer (DV). Ryan disagreed. Eddy supported wildcards in EV but not DV. Ryan said Google would not support Wildcards in OV (as a minimum). Dean suggested we add this to the F2F agenda. Jeremy would also like to see adding to the agenda a topic on 27 vs 39 month validities.
  5. Validation Working Group: No further updates other than domain validation. Jeremy also circulated a draft for legal existence on attorney opinion letters which will become a ballot. Ryan said he had some concerns which he will write up.
  6. Code Signing Working Group: Dean said the group is waiting on one final section change (Appendix A) before releasing the document to the forum for ballot
  7. Policy Review Working Group: Ben sent out an email with the status of the group
  8. Info Sharing Working Group: Call tomorrow 1600 UTC, talking about TAXII gateways to share information
  9. Other Business: CA Day in Berlin June 9th, Ben and Moudrick will attend.
  10. Next meeting: May 28th.
  11. Adjourned.
Latest releases
Code Signing Requirements
v3.7 - Mar 4, 2024

S/MIME Requirements
v1.0.4 - Ballot SMC06 - May 11, 2024

Ballot SMC06: Post implementation clarification and corrections

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).