2013-09-19 Minutes
Notes of meeting
CAB Forum
19 September 2013
Version 1
1. Present: Dean Coclin, Mert Ozarar, Atilla Biler, Ben Wilson, Sigbjorn Vik, Eddy Nigg, Atsushi Inaba, Mads Henriksveen, Sissel Hoel, Rick Andrews, Geoff Keating, Robin Alden, Cornelia Enke, Jeremy Rowley, Gerv Markham
2. Agenda: Approved
3. Minutes: Minutes from 5 Sept. 2013 approved.
4.Discussion of Face-to-Face Meeting Agenda: We should probably discuss a little about the NYT/Guardian article on NSA/GCHQ. What is the global perspective on this? Mads said that there was an article in the Norwegian paper recently. It’s quite difficult for people like us representing important parts of the SSL ecosystem, to answer on behalf of all the people in the ecosystem. How should these questions be answered? Some statement from the Forum could be helpful for us. The CA Security Council, and GlobalSign have written posts as a responses to this news. These may all be good resources for others to use in response to the questions/concerns. Besides that, our understanding is that CAs weren’t really alleged to have been involved with the NSA spying, it was more software compromise and algorithms that might be compromised and this is what we are saying. Geoff noted that more than one person is thinking that CAs are insecure, so some type of denial by the Forum would be smart. Mads said a statement of what could be compromised rather than about CAs is a goo approach. Ben will send out links to the posts. Here they are: (https://casecurity.org/2013/09/13/encryption-still-works-its-about-how-you-implement-it/#! – https://www.globalsign.com/blog/trust-the-math-choose-your-friends-wisely.html). From the inside we know, but for instance, in Norway, it might be more difficult to get that word out. Mads, you could take these responses, and link to them if you need something to say that these are replies from the industry, maybe that will work. It depends on how far you want to go, and how you want to respond.
Sigbjorn, Rick, Gerv and Connie: There are issues raised by Bruce Schneier about whether or not we should raise key lengths or trust elliptic curves created with Dual EC_DRBG. I think that was mainly in the context of a random number generator, not in certificates. There was a random number generator that NSA had a hand in generating. That was the Deterministic Random Bit Generator (DRBG) Algorithm. That’s the first issue. The second issue is that the constants (curves) for these standards may not be as quite as secure as we thought they would be. https://www.schneier.com/blog/archives/2013/09/how_to_remain_s.html The issue is that because NSA had a hand in selecting the curves, there might be might an unknown weakness or backdoor for decryption. The answer is that nobody uses DRBG, so the concern is only about the curves. (Speculation is that they could have been favored based on brute force searching for constants with certain properties that would give the NSA a head start on being able to decrypt data that was encrypted by relying on such curves.)
Sigbjorn: Another topic I’d like to discuss is that some CAs do everything for the customer, generate private key, public key, and send to customer encrypted. If in this process the NSA is able to obtain the private key, they can then get to all of the communications. Shouldn’t this be prohibited?
Eddy: CAs should be allowed to provide this as an option for customers, otherwise you’ll have lots of support problems.
Connie: This depends on the implementation and a consideration of the architecture of your backend systems and how you are doing this. We should discuss this on Wednesday morning. It could be a problem, because some customers might really want such a service.
Gerv: Can the CAs that offer this answer what percentage of customers request that the CA generates the private key for them vs. those that only require a CSR?
Eddy: The majority of our subscribers request that the private key be generated by the CA-for server certificates. This might be around 70%.
Gerv: Do you think that this is because generating it on the customer’s server is more complicated?
Eddy: Yes.
Robin: We don’t generate keys for our server certificates. There are some clients that need us to generate client certificates for them.
Eddy: We do just the opposite, because the browser software helps customers generate their own key pairs for SMIME.
Gerv: That would be an interesting topic to discuss.
Ben: Atsushi has requested that we talk about the use of SHA2 on mobile devices in Japan.
Atsushi: Yes, I would like to address the issue of SHA2 in the Japanese market.
Ben: SHA2 can be discussed in the morning, and then the other topics on the schedule are collaboration with other groups (IETF, NIST, etc.) and then we’ll talk about interested party and observers. There is an update from ICANN as well.
Finally, we have also invited the audit and supervisory groups of Turkey to attend the meeting as invited guests.
5. Any Other Business: None.
6. Next phone call: Thurs. October 10th.
7. Meeting adjourned.