[cabfpub] Notes of meeting - CAB Forum - 7 November 2013

[Ben Wilson]

Notes of meeting

CAB Forum 

7 November  2013

Version 1

1.  Present:   Ben Wilson, Jeremy Rowley, Atsushi Inaba, Carolyn Oldenburg, Wayne Thayer, Kirk Hall, Eddy Nigg, Ryan Hurst, Håvard Molland, Connie , Rick Andrews, Geoff Keating, Steve Roylance, Gerv Markham, Mert Ozarar, Atilla Biler, Dean Coclin, Tom Albertson, Robin Alden, Mads Henriksveen

2.  Agenda reviewed.

3.  Minutes of 24 Oct 2013 approved.    Ben noted that several comments and corrections to the Ankara meeting have been received and that he will update them on the wiki.  

4.  Ballots:  Ballot 109 (working group on performance) passed.  Ballots 89, 103, and 107 are all still on the table for editing. 

5.  Review of working groups:

Code Signing WG:  Jeremy circulated the Code Signing BRs to the CA/B Forum public mailing list, which is required by the Bylaws, but primarily for the benefit CA/B Forum members.  We have received several comments that will either be incorporated before the next draft is circulated or will be placed in an issue-tracking spreadsheet.  It was intended for CA/B Forum comment only, but we will take general comments.     If you still haven’t reviewed it and you want to make comments, please do so ASAP because we want to get the draft out for public comment by the end of next week (Nov. 15) at the latest.  We expect to have a two-month public comment period.  Jeremy will summarize all of the comments and put together an issues list.  Kirk suggested that an announcement of the draft be made on the Mozilla list.  Dean said that is planned when the draft is made available for public comment.  Dean and Jeremy will not be on next week’s code signing working group call.  They will get together ahead of time to discuss the public release of the draft.

EV WG:  Jeremy said the EV working group is moving ahead and that a couple of suggestions are almost ready to be circulated.  Jeremy thinks we will see something after the EV WG’s call next Thursday (Nov. 14th).

Performance WG:  Ben said that Wayne Thayer and Brian Smith are the new chairs of the Working Group.  Wayne said that he talked with Brian, and that Brian is at the IETF meetings this week, but that they will try to get the WG kicked off next week.  Ben said that one idea would be to start out with two certificate profiles based on the Baseline Requirements --one for RSA SHA 256 and the other one for Elliptic Curve, and whatever parts of a profile that we might want to have, based on the back table of the Baseline Requirements.   We will need to have Brian suggest a good time for having a regular WG telephone call.

6.  Website edits:   Dean has started working on the remaining items.  He said that there are several areas where we need external input.  He will try to get to it by the end of the week.  Ben asked how he might get commitments from more people to collect their thoughts and comments on it.  Dean noted that the link to cabforum.org/wordpress is in the agenda, and folks should be encouraged to click on the link and browse through it and send out comments.   Next week Ben will send out another email with high priority urging people to take a look at it and provide any comments to Dean or Ben.

7.  Review edits to the by-laws:   Ben received several comments today that he will try to address.  He asked how we should proceed on the next draft.  He said it was sent out in Word format, so if you want to mark it up any and send it back to him, that would be great.

Ben said the current draft says Browser/(new language) “Platform Provider” --  member organization  is a major global producer of software product intended for use by the general public:  (a) for browsing the web securely or (b) which authenticates digitally signed computer code. 

The question about Konqueror and other smaller browser developers could still be worked out if we wanted to address situations where the smaller developer had in some way a larger footprint--then we could revise this to include them, but without having some language proposed, Ben didn’t want to try to propose anything that might fit that entity type.  Any comments are welcome. 

Tom said that he had not really been focusing on the browser definition thus far, but in reading it, there was concern that expanding the concept of browsers to include something like digital document signing might conflict with work progressing well within ETSI and that would be a bad idea.  They’re doing pretty well on their own and making big advances.   Ben noted that the most recent draft removes the concept of document signing—as noted, it just covers browsers and code signing.

Kirk said if the revised definition of browser/platform is for Oracle Java, then we should go back to the specifics of what we are trying to accomplish and then make sure that the definitions accommodate that.  Ben said that was consistent with how the language is right now. So if we look at the proposed language, we can determine whether it narrowly allows us to accomplish what we want and that everyone needs to look at the language, and contemplate it, and see if they have something in mind that would be either in or out of scope based on the language, and if there are any concerns, then people need to say something.

Atilla said that he had raised an issue on the list about whether associate members should be mentioned in Section 5.5 as signing IPR agreements even though there is another note in section 3.1 that sometimes it may be waived due to some organizational reason.  Ben said he would make that change to section 5.5.   Atilla said he is not aware of which associate members have signed IPRs and which ones have not signed. His general doubt is the general difference between associate member and interested party.   Dean said that associate members are organizations that don’t fall into the category of CA or Browser with the traditional definitions, the CA/B Forum decided that there was a benefit of having these members of the CA/B Forum, so they were invited to participate, they have to sign the IPR, they do not have voting rights, and they can participate in the regular meetings.  The difference with interested parties is that interested parties are folks who can attend and participate in working groups, they have to sign the IPR, but they do not attend the regular meetings, and they can post to the public mailing list.   Interested parties can be invited by the chair as “invited parties” if the chair decides that the party can add value to whatever is being discussed at the meeting, but by default, interested parties do not attend telephone calls or face-to-face meetings.

Dean noted that we had not discussed which category is for Atos.  They have signed the IPR, but they haven’t started issuing certificates off a publicly trusted root, and we gave them observer status--like AffirmTrust had—but that status doesn’t fall into the explanation of these categories.

Ben said we could create a new “provisional member” group.  Dean said that they are just like an Associate Member, but we haven’t given them wiki access.  Kirk said that Affirm Trust was able to access the wiki, so maybe that is the only thing we need to make more clear.  Dean said that they do not have ability to post to the list or access the wiki yet.  Do we think this is ok?  Kirk said that he thought it would be fine. 

Ben asked whether there were any other comments on the draft by-laws that we had not yet discussed?  

Dean noted that Gerv had discussed whether ballots were needed to establish working groups.    Gerv said he thought that when we set up the working group, he felt that the process was a bit too heavy, but it did help define the scope of the WG.  Jeremy said he favored getting rid of the ballot requirement.    Dean said that the requirement forces you into formalizing a goal and definition--although we did not do it for the code signing WG, and it still worked out fine.  Kirk said he didn’t think we needed a ballot.  

Dean queried whether we just say that before a working group is formed, a scope and definition has to be articulated and presented in writing to the members?  Ben said he thinks that the current redline draft accomplishes everything that is being discussed.  It already says, “outline the scope of the Working Group’s activities, including deliverables, any limitations, and Working Group expiration date.”  And ballot is now crossed out, and it says “working group is chartered when it has been accepted by members by ballot, unanimous consent or other form of vote.”   Ben said he thought we were now ready to present this as a ballot. 

8.  Handling of Subscriber’s Private Key:  Ben asked whether we want to start out the discussion talking about “key escrow,” since that was the main issue that was mentioned during discussions on the list about this topic.  Ryan said that he could start out by talking about CA generation of the key, and that they do not do “key escrow” per se.   

Ryan said that they added the ability to generate subscriber private keys as a result of all of the bad keys that were being generated by customers.  They use hardware systems and follow procedures.   They think there is value to the service they provide to their customers, and as long as it is not forced as a service requirement—and they provide guidance that it isn’t for everybody, then he thought it adds value to the subscriber, so he’d hate to see it prohibited.   Ben said he tends to agree, once you consider how CAs provide security services to their customers.  Eddy said he agreed as well.

Ryan suggested that the CA/B Forum propose criteria for this practice—such as using hardware to produce random numbers, making sure that you’re storing keys in a way that they are deleted securely/ zeroized once delivered, and that upon initial creation no CA component  is in possession of the total secret-- you don’t email them around, etc.  Ryan offered to prepare an initial draft of what would be considered the reasonable bare minimum.

Kirk asked, “why do we need to do this? This has been working without any requirement for 20 years.”

Håvard said that he was the one who asked that this be added to the agenda.  In the latest events with Lavabit, compelled disclosure, all of the Snowden issues, etc., you break the trust model when the CA has the private key.  If I go to a site that has an American CA, it’s impossible for me to see on the server if someone else has the key.

Eddy said that you can know because we are audited, and this issue is discussed very clearly with our auditors. 

Ryan said that key generation by CAs is a minor issue when you specify bare minimums.  Many other issues arise if the server is using a CDN or hosting provider.  There are so many different cases where the site you are visiting does not have secure control of the private key.  There are just too many operational scenarios where you just don’t know who has the private key.  And frankly, you might have a shared key across many different vendor sites because of the lack of SNI support. The reason that we do this is that because we feel there is a reasonable chance that a number of these smaller CAs are going to offer the service, we want to stop somebody from doing the stupid things, like telling the customer to upload their private key for conversion--that does not look good for our industry, and having rules around subscriber private key handling is not a bad thing to have.  

Kirk: Håvard wants to raise the question of whether it should be permitted at all, which is a fair question to discuss. If it is permitted, do we want to come up with some standards for it, and I’m agnostic on that.

Eddy:  The alternative would be sending people over to some site to do it and they’re not CAs and what they’d do would be quite ridiculous.  

Håvard:  You don’t have to do it online.

Eddy:  You never have to do it online.  The CAs that provide this alternative to submit your own CSR--nobody forces you to do that.  But there are many people who don’t know how to get their private key and they end up using another site that is not a CA.

Ryan:  In our case, we provide tools that help people figure out how to call openssl and keytool and various other things.   CA key generation is not the primary way we push people down, and I would rather everyone generate them locally.  The fact of the matter is that we’ve had plenty of recent examples where people are not generating their keys well.  Conversely, we know how to do it because we do it every day.

Kirk:  Håvard, would you feel better if there were rules and limitations around this, since right now there are no rules and limitations?   Such as the CA that generates it cannot keep a copy of the key?

Håvard:  It would certainly be better.  

Eddy:  The rules would be like those for key escrow, which are part of WebTrust, and if you do key escrow, it must be audited, so requirements and controls have been there for a long time covering that.  

Geoff:  Could we have some other standard, and just say “do it like this?”

Ryan:  No specific thing comes to mind from the stuff I’ve seen around this.  It’s all very nebulous.  And some rules that are key-escrow focused would not be ephemeral-key-generation focused nor targeted at our SSL scenario.  “I agree with Håvard, that I’d want to know the providence of the key, but  unfortunately, we cannot know.  There are some cases where we know people are doing some bad things like we mentioned, uploading private keys to web pages to get them into the appropriate format, etc., which is more distasteful to me as a security practitioner.”  Whereas we have the expertise and hardware and systems designed to do this securely, and we will delete it when we’re done.  If write this up, then we should talk about it in the broader sense of key handling.  

Ben:  Should there be anything in the certificate that flags it as generated in some other way?

Ryan:  Personally, I don’t think that makes sense.  While there are a lot of scenarios where it might be good to know whether it was made on premise or generated in a cloud service on a piece of hardware, that still does not tell you if somebody else has a copy of the key.  Operationally, there are a lot of cases where somebody else has a copy of a meaningful key. 

Eddy:  Right, with cPanel or Plesk platform or something else with someone hosting the site, there are lots of issues about who generates the private key and who holds the private key for them, then CAs are not the worst choice in that case.  

Ryan:  I wouldn’t be surprised if it was the majority of the cases where somebody else has a copy of the key.

Ben:  Ryan, would you be willing to write up those three or four requirements? 

Ryan: I will look at the BRs again and find something similar and write a set of “subscriber key handling requirements”.  I won’t write them specifically about this, I think its bad form for CAs to say post your private key to me, so I’ll include that as a basis for negotiation for conversation.

Ben:  You could also make it a permissive statement and say “a CA MAY do this” so that it is on a CA-by-CA basis.  You could say that the CAs that do this, MUST disclose whether they do it in section 4.12 (or sections 6.1 through 6.4) of their CP or CPS, and say whether they do it or they don’t do it.

Ryan:  I can probably do it this weekend.

9.  Security improvements to SSL implementation:    

Ben:  This topic kind of crosses over into the work of the Performance WG, although not exactly.  This is more about Hårvard’s concerns about speculation raised about NSA’s involvement in the selection of Elliptic Curve parameters (a la Snowden).  

Håvard:  I am not saying that these curves are manipulated, but we should have a conversation about it.  It is only speculation.  The release about Dual EC DRGB, and the way the constants have been chosen, also shows that “it could have been”—it’s an unknown, and it is possible that it could have been done like some have suggested.

Rick:  At the IETF meeting  this week, there was a lot of discussion about that.  I think the IETF is ready to take on a review of everything that has already been in existing standards, with an eye toward trying to flush out anything that may have been tainted.  This group (CABF) probably can’t do much about it, it’s a much broader issue that needs to be tackled by IETF. 

Ben:  I was going to say almost the same thing.  One of the comments here at IETF was that maybe the IETF should deprecate the bad ones--there was a conversation on deprecating the bad ones vs. recommending other ones as good ones.   It does sort of cross over to performance, because if we’re talking about what the best way to do it, part of the scope of the working group, as I understand it, is that it would cover not only certificates and contents, but also algorithms.  But that’s not the first item on the WG’s task list, so I’ll let the working group discuss that.

Håvard:  But elliptic curves in certificates are almost not used yet, right?  So it’s only for the key exchange.

Rick:  We’re selling ECC certificates.  But you’re right, it’s not widely used except for key exchange.

Håvard:  It’s easy to stop now and look at what curves you want to use.

Ben:  But I’m not a mathematician that can take a look at an elliptic curve, and say, “see there’s a back door here.”

Håvard:  No, but you should be aware of it.

Rick: It’s very hard for CAs to lead here.  We might decide there’s another elliptic curve that should be used here instead of the NIST Suite B specifications, but unless support for those curves is built into widely accessible tool kits, we can’t deploy keys with those curves in them.  We kind of need the broader crypto community to decide perhaps on alternate ECC curves and make sure those are all built into crypto tool kits that everyone uses.

Ryan:  I don’t know if we can lead, but the way things are codified with ECC and which curves are allowable or not, that does introduce some challenges.  We are unlikely to see the kind of broad support that is typically required for us to make policy for everybody if we are still ultimately dependent on Mozilla, Microsoft and Google to add support for alternate curves.  But one of the side effects with the Snowden stuff is that we are going to see more countries come up with their own GOST algorithms, like has happened in Russia.  CAs would like to help this, especially domestic CAs, but they’d like to help them with managing the key material.  The CAs end up being gated on being able to do it by having HSMs that are allowed to support arbitrary curves.  If I wanted to support GOST today, there isn’t an evaluated HSM—there is just software running on a computer with duct tape around it so you can see whether it’s broken.  Products are missing that we would have to build to if we wanted to implement it.  I don’t think the bar should be browsers and servers supporting it, because there are other scenarios where publicly trusted SSL certs are valuable.  It would be nice to have more leniency in this area.  I don’t know how we do it, but I definitely think support for some of it is available on the safe curves web site (safecurves.cr.yp.to/‎).  There are some very interesting curves that are being advocated, and they’ve got some good reasons as to why they’re being advocated, but frankly I couldn’t help a customer with them even if I wanted to off of anything that is chained to a public root. 

Ben:  You know, there are two things—(1) maybe we find out more about these curves from people at IETF (and ask Schneier to retract his statement of inquisitive concern) and (2) figure out what to do?  We ought to figure out what we, as a CA/B Forum, can or should do.  Maybe nothing, maybe wait and see.

Ryan:  I think we can take a couple different positions.  Today, Windows doesn’t allow you to specify arbitrary curves in crypto API calls.  So you might have to use somebody else’s crypto, but they’ve recently added new curves to OpenSSL.  I don’t know what kind of litmus test we want to apply for adding a curve. 

Håvard:  I can definitely see it’s hard to do anything specific on this.  I just wanted to have a discussion about it.  I’m not sure what my position is on it.

Kirk:  I don’t think this group has the technical expertise to do anything about this.  I do think we should keep informed about what other technical groups are doing, and depending on what their conclusions are, possibly we change our standards.

Ryan:  I generally agree with that. We should probably agree on what the bar is ahead of time.  Rick previously wanted to get DSA supported.  And I couldn’t see a reason to say no. But why is that?  Well, I saw no reason not to, and I don’t see Dan Bernstein ECC curves as any different.  Why couldn’t Rick who is in a position to issue these today issue them then? Because we don’t allow him, but why?

Rick:  If there was a narrow case where somebody wanted an odd curve, we are perfectly capable of issuing them off a private root.  What we are talking about here are the public roots.

Ryan:  With DSA, it isn’t supported by mainstream browsers, but you can include those in public browsers.

Rick:  It’s not supported in IE, but it was supposed to be included in Firefox 24. 

Ryan:  But it’s not today, but it’s ok for you to issue them.  So, what criteria do we apply?  Whether or not we say today, the Bernstein curves are ok, so what’s the criteria?

Rick:  I didn’t’ slip DSA in the back door, we had a public discussion about it, and the CA/B Forum decided to allow 2048 as acceptable key sizes and algorithms.  So if you want to add something new, you just make a ballot and discuss it.

Ryan:  Maybe it’s that simple.  I see the value in it.  

Ben:  I guess that’s the best we can do right now -- stay up in the news about it.

10.  No other business – meeting adjourned.

11.  Our next call will be two weeks from today.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131125/d6bcf7f4/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5453 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131125/d6bcf7f4/attachment.p7s>