[cabf_governance] Draft Notes of Meeting held July 5 2016

[Ben Wilson]

Here are draft notes from the call July 5th.  I'll get out my notes from
yesterday's call as soon as possible.

 

Present: Dean, Kirk, Ben, Peter, Robin, Moudrick, Virginia and Andrew

 

Dean: Let's start with Kirk's suggestion where we step back a minute. Kirk
sent a note last night saying we should step back and define what the
problem is. 

 

Kirk: Yes. We need know what we are in order to know and achieve and what
specific steps are taking us in that direction. I tried to lay out a week or
so ago what I thought was the genesis of this, and I could be wrong, so I
wanted to hear from other people. Didn't this just come up, in part, because
of the code signing ballot and that issues affecting the code signing ballot
didn't seem to be within the scope of the CAB Forum? And the realization
that there may be issues that CAs care about that browsers don't, and why
did we get "no" votes from Google and Mozilla? And I don't think it was only
because it was arguably outside the scope of the Forum. I definitely got the
feeling that there was a problem with our IPR policy and in voting for the
ballot, if it passed they would have to disclose IP and Google and Mozilla
didn't want to do that so that's part of why they voted "no"? So that's why
it was suggested that we just go to a participation form of IP agreement so
that people who want to stay away from the subject can just avoid the
working group that is working on it. And then we can also change our rules
so that working groups that don't have anything to do with SSL certificates
can adopt their work at that level, and it does not have come up to the
Forum level or be adopted by the Forum. So I was trying to think of what we
were trying to do, and there was some talk about looking at the W3C
structure and sort of copying it and opening the doors to potentially lots
of very big projects, and I have a real concern that we just don't have the
resources to operate the way that the W3C does. So I'm just curious to know
what other people think that the goal is or the problem is that we're trying
to solve here.

 

Dean: And Virginia, you had some comments around that that same area. Do you
want to say something?

 

Virginia: I had to drop off temporarily.

 

Ben: Well let me chime in. Yes, I was going to say that this is the same
comment as Virginia made about the W3C being too big of a model and that we
don't need a big huge infrastructure when we have a small problem. I am not
an advocate of adopting something with a lot of overhead, and that's why I
wouldn't want to copy the W3C policy verbatim. And Virginia has also said,
why go with the W3C model because it's going to create a lot of overhead,
but we don't have to have it be a lot of overhead. We can make it what we
want it to be, and that's all I wanted to say.

 

Kirk: Well, what do you think is the problem we're trying to solve?

 

Ben: Well, I think it is like you said, the code signing issue came up, and
that there were two issues, and I'm just reiterating what I heard at the
face-to-face meeting and in other discussions. There are two issues here.
Just the voting structure that is part of our membership structure. I think
that's the more difficult thing to resolve, like who gets votes when, and
why, and then a related thing that some members have expressed is the other
one which is the IPR policy and how you scope it to be just the working
group? I think if we get the pieces of the W3C model for the working group
model and use that we'll solve the IPR issue, but the bigger hurdle in my
mind is how do we decide who gets to vote. 

 

Kirk: On the voting thing, what is the voting problem?

 

Ben: It's do you have a skin in the game? Are you a real browser? Are you a
real software provider? And it also is how do we limit the number of
participants? I know that's the concern of a lot of people, and we don't
want to all of the sudden find that hundreds of people want to get involved,
and want to have a vote, and I'm not trying to be exclusionary here, I'm
just trying to be pragmatic.

 

Peter: To answer your question, Mozilla's concern is around whether the
right people are voting on topics--code signing, for example. Of the current
entities that are members but not CAs, none of them has been interested in
code signing except Microsoft. Whereas it was indicated during the code
signing development process that there were at least two other entities that
theoretically have an interest in code signing whose interests are not being
met because they are not members. So Mozilla's concern was fairly
straightforward, do we have the right people voting here on whether or not
there should be a standard? I think the other way to look at it is they are
not interested in the CAB Forum scope expanding to support a single vendor's
product. I think they don't want to see the Forum used to set those
standards for that one supplier.

 

Kirk: I agree that on the one hand do we have enough people here and on the
other hand but we don't want a great set of rules where we have too many
people. But do we have the right people here, and we tried to get those
other people in, and they didn't, as I understand, want to join the working
group because they didn't want to sign the IPR policy. So it would be good
to know if we could have solved that problem by having the IPR at the
working group level. And I'm not clear if Google and Mozilla would've said
even then we don't want it voted on at the Forum level because that's just
SSL certificates and we're not interested in the subject. I'm not sure where
they came down on that if they were been satisfied with having it handled
solely at the working group level and adopted there.

 

Dean: No, they would not have been satisfied. Google voted against it for
two reasons-one, it was is not in the scope of the Forum, and second was, I
believe, that they had intellectual property around this, 

 

Kirk: So it's easy to expand the scope of the Forum and if they're worried
about the IP, then again, we could go back to them and ask whether they'd be
satisfied if we went to a participation model?

 

Dean: Andrew Whalley of Google isn't on the phone, but certainly he has been
participating and I think we heard about some of the reasons why the current
model isn't going to work for them at the face-to-face. Now, speaking of the
face-to-face, you know we were talking about having our own governance
face-to-face, and I can give you the results of that poll in a few minutes. 

 

Peter: I think the other thing that has been mentioned is that a number of
CA members of the Forum have an interest in discussing other types of
certificates and standards thereof and would prefer to not have to do yet
another organization or forum. Obviously one of the solutions here, or one
path, is that the CAB Forum exclusively does server authentication
certificates and everything else is handled elsewhere. The reason we're
having this discussion is that I think that people want to do scope outside
of that.

 

Kirk: So, in the email I sent I suggested going to a participation model if
that would solve the problem for a couple of the browsers. My own feeling is
to keep SSL certificates at the top level and not push them down into their
own group, but then change the scope so that we can have working groups work
on non-SSL certificate issues and their final product is voted at the
working group level, not at the Forum level, so that their work never has to
come up for the browsers that don't want to participate. That would result
in minimal changes that I think could accomplish this, but it wouldn't be
worth going in that direction unless we found out from Google and Mozilla
upfront if that's the kind of thing they'll accept.

 

Peter: Well, I think if that's the consensus then I think we need to give
them something in writing that asks, is this the right direction? 

 

Kirk: Would that idea appeal to you if it appealed to the browsers? 

 

Virginia: Why would be catering to what they want?

 

Kirk: Good point. This is the CA - Browser Forum and a bunch of CAs want to
go in a direction that doesn't involve browsers. So the question is, do we
therefore push everything down into working groups leaving it unclear what
the parent organization does. Or do we solve it a different way? And I guess
why do we care about them? Well, we care because they blocked adoption of
the code signing guideline by the Forum, and I think CAs would like to work
not only on that, but maybe some other things using the convenience of
tucking in more meetings around Forum meetings. So all I'm really trying to
do is figure something out to let CAs do what they want to do and expand the
scope of the Forum in a way that avoids the IP issues that two of the
browsers were concerned about.

 

Peter: Virginia, I think you're the only person on the call today that is
representing non-CA member of the Forum. Does your organization have any
interest in a scope larger than server authentication, that is what we call
TLS certificates?

 

Virginia: I don't have an answer for that right now. I have a meeting to
discuss it later in the week. 

 

Peter: OK. I think that the answer to that question from all of the current
members of the browser class might be very helpful. Because I think that to
Kirk's point it would be helpful to understand where the browser group wants
to go and it would be very helpful to understand what options there are. The
fact is that the structure is set up such that the browsers in the aggregate
are equivalent to the CAs. 

 

Kirk: So Virginia, apart from your few meetings with Geoff, from what you've
heard today, do you have an idea of what the problem is and what the
solutions might be? 

 

Virginia: I don't think I have the big picture. I still think we're trying
to solve a problem for two companies. 

 

Dean: That's not it. Here is the issue. We have code signing issues that
people want to work on. We have S/MIME standards for secure email that
people want to work on. The same people that are currently in the Forum are
referencing the same standards that we currently use in the Forum, and
instead of creating a separate group that would have to reference the
standards of the Forum and then have the same people and have to come up
with a whole new org structure, let's use the structure that is already in
place. Let's use the standard that we have already contributed to, and let's
come up with these other working groups and teams to work on these other
problems. Then currently some of the browsers don't care about those
problems, so we're trying to figure out a way where some of the same people
in this group can work on these issues without worrying about what people
who don't care about these problems have to say. 

 

Kirk: So I think it's mainly the IP problem, I think it's not so much about
the scope of the bylaws. I'm willing to accommodate them if it will avoid
working groups getting vetoed in the future. 

 

Virginia: We have make sure that it is in the best interests of the CAB
Forum as a whole, and not just fixing the issue so that those two companies
will be happy.

 

Ben: I agree with Dean. It's not just doing it for those two companies. It's
because we work on more or less a consensus basis, and sometimes the
majority wants something, 20 of us vote for it and 2 vote against it, and we
have to somehow get past that especially with the voting rights that the
browsers have. They have a veto because of the limited number of browsers
and in the end a browser can block any kind of proposal. All that is
required to block something is a simple majority, or even if it's a
stalemate or tie that blocks us from moving forward. That's become, in my
mind, a problem, and if we can somehow get past that by addressing these
members, which are Google and Mozilla's issues, then we can move forward,
but right now, and that's not to say that Apple itself would be a problem in
the future in voting against something that we want to do, so it's not just
solving just two members, it's even those potential future members, and like
Dean said, sometimes we want to talk about things that are of interest to
everyone, but we don't want to have to go out and create another
organization just to do that. 

 

Dean: We talked about having a face-to-face meeting and as you know we sent
out a poll, and I have the results here, and right now the most "yes" votes
is on Tuesday, July 19, . or August 10, .. 

 

Kirk: There were two organization that would not participate in the code
signing working group because they didn't like the IPR agreement and that
was Cisco and Oracle? 

 

Peter: Adobe I believe.

 

Kirk: Cisco and Adobe? Adobe and Oracle?

 

Peter: The two that were identified as code signing users were Adobe and
Oracle.

 

Kirk: Do we know what would make them happy? In terms of if we change our IP
agreement? Did they give us any indication of what they would sign and then
participate?

 

Dean: They didn't like the RAND-Z model.

 

Jeremy: Well, somebody brought up on another call that they actually do
participate in other groups with a RAND model and RAND-Z model as well, but
they had said originally that they wouldn't join groups with RAND-Z models,
so maybe it's just the scope issue, but I am not 100% sure which way, but I
do think that Dean's point still stands that there are people who do have an
interest in the community, people who are looking at client certificates and
code signing certificates as well as SSL certificates. Bringing all of this
together is part of the objective, not necessarily just for those two
companies, but we have other people that would like to discuss these things
in addition to SSL certificates. 

 

Kirk: Is there anybody that we know of who insists on a RAND-Z model as
opposed to a different model?

 

Jeremy: Yes. Mozilla. 

 

Kirk: Would Mozilla go with a participation model?

 

Jeremy: I don't know if they would push for a RAND policy.

 

Kirk: Does the participation model end up being a RAND-Z model? People were
worried that . they could say, "I have nothing to do with this working group
and yet I now can be forced to disclose IP that I have or as a consequence
face a RAND-Z policy, and I don't want to do that." 

 

Peter: That's participation. The model for participation is using the term
"participation" with a capital "P", as roughly defined by W3C, which
basically means that the IPR policy only kicks in under a certain set of
circumstances that is defined as participation. It still can be a RAND-Z
policy, which is what Mozilla requires. Mozilla has stated they want
everything under RAND-Z, and I think actually some other members may also
prefer RAND-Z over the other option, which is essentially, if you don't have
RAND-Z you have the problem that you can end up with standards that the only
way to implement is to pay licensing fees, etc.. 

 

Kirk: So why don't we just keep our RAND-Z policy but layer over it working
groups that are not working on SSL certificates a participation threshold?
And because it's not SSL, it does not have to come back to the Forum level.
So, working group on code signing, if you don't participate in it, then you
never have RAND-Z apply to you and the final product is adopted in the
working group, and the working group is a participation plus RAND-Z policy? 

 

Jeremy: That is more complicated, and it doesn't really solve the problem
because you still have the nonparticipation-based application of the IPR to
the SSL group, and people like Adobe and Oracle don't care about SSL. 

 

Kirk: But that would be done in working groups. 

 

Peter: Just to clarify, there are basically two things that have been
proposed. One is to push the SSL work down into a new working group and have
an umbrella group called the CAB Forum. So there would be a separate code
signing working group. I'll call that Option A. Option B is similar except
for the SSL working stays at the CAB Forum level. You prefer Option B, is
that correct? 

 

Kirk: That's a part of it, and also I think the CAB Forum as it is has done
some really important work and it has a name, and reputation, and so forth.
The problem is the other stuff that we want to do at the working group
level, and if we can just keep it quarantined at the working group level and
solve the problem of Mozilla and Google where they say that it has to come
to the Forum level to be approved, and we don't want that because of the
RAND-Z policy, then change our rules so non-SSL stuff stays in a working
group, and Mozilla and Google can avoid any RAND-Z problems if we just
clarify that there is a participation model at the working group level, and
if you didn't participate in a working group, you don't have to disclose
anything once the working group adopts its final product. That is what I was
trying to maintain.

 

Peter: Let's pretend we create a group called the PKI Forum, and I know that
has already been used, but that the CAB Forum becomes one group within
there, and then there's a code signing forum, a client forum, etc. All that
really is in play there is the name, CA Browser Forum and the value of that.

 

Kirk: One more thing- we as CAs and browsers would lose control because at
the top level it's not just going to be CAs and browsers, I expect. Then
they could come up with a bunch of rules that apply to us at the SSL forum
or modify the SSL working group, and I don't really want to lose control.

Peter: Your concern is that if there was a different umbrella group, then
the SSL group might not be the controlling group, and therefore might end up
subject to changes and the new parent might say, oh well no grandfathering
and the new rules apply.

 

Kirk: Yes. They could say we all decided to change the IPR policy for all
working groups, here it is, take it or leave it. Or we're going to change
the voting rules for every working group. So we don't know what a new parent
organization that is not just like the current one with CAs and browsers
will do. I just don't see the benefit of going in that direction if we can
refer to ring-fence the non-SSL stuff in working groups but keep the parent
organization more or less the same. Maybe we should develop some questions
for Mozilla and Google and some for Adobe and Oracle that asked, "what would
you do if?" and see what their answers are. Then we'd know whether making
certain changes will solve our problems or not. It would be really a waste
of our time to spend months on this and then find out that some of the key
players wouldn't be satisfied.

 

Jeremy: I don't think that's true, though, because like we said, it's more
than about Oracle and Adobe, it's about being able to discuss code signing
and S/MIME and having that separate from the SSL discussions so that we can
have all the right players.

 

Kirk: That would be included-we would expand the scope of the Forum, but the
non-SSL work would happened through working groups. So that would definitely
be part of what they would be asked, would you go along with this or would
you still object?

 

Andrew: Hello everybody sorry for joining late. 

 

Dean: Thanks for joining Andrew. We're discussing something that we can use
Google's input on.

 

Kirk: Let me summarize. Before you got on the call I asked maybe we should
ask some of the players who have expressed a concern in the past about how
we're structured and what we're doing. If a set of changes would satisfy
them or not because if we went through all of the changes in organization
and so forth and that wasn't sufficient and that would be a waste time. So
my thinking was I'd like to keep the SSL issues at the CAB Forum level and
not create a new SSL working group under a governing organization at the top
level that would no longer be just CAs and browsers. I want to keep that
part the same. I would keep RAND-Z for SSL certificate issues. But change
our bylaws so that the Forum can also work through working groups on non-SSL
issues and those groups would have some form of participation barrier
meaning you're not required to do any disclosure on anything, on any issue
being worked on in a non-SSL working group, and the non-SSL working groups
would then have a RAND-Z policy also on a participation basis for work done
in a working group, and when they finished a product they can adopt it at a
working group level and it does not have to come to the CAB Forum level for
endorsement by ballot. So, for example, if we would have had that in place,
code signing work would have been done in a code signing working group that
would be application providers that use code signing and CAs that issue the
certificates, and when they finished they will be subject to a RAND-Z policy
based on their participation at that working group level only, and when they
finished they'd adopt the code signing guideline at the working group only
and would not come up to the CAB Forum level for a vote or anything and
therefore would not trigger any RAND-Z disclosures by members of the CAB
Forum itself who did not participate in the working group. Do you think that
would satisfy Google's concerns from what we went through recently?

 

Andrew: Does that imply that you can be a voting member of a working group
but not of the top level? 

 

Kirk: Yes. That's the actual rule today. Non CABF members and members of
working groups participate with Forum members who are on the working group
though the one difference would be the voting at the working group level
would be much more important because that is where final adoption of a
working group product would happen if it is not related SSL certificates.

 

Ben: So let me pose a question? Let's say Adobe is a member of the code
signing or S/MIME working group and an issue for SSL comes up at the top
level. Would they have a vote on that issue? 

 

Kirk: No. They would not be a CAB Forum member. 

 

Jeremy: Let's say it's not an SSL issue. Let's say it is deciding where the
next meeting is. So would Adobe not get a vote because they are not members
of the main forum? Or let's say they wanted to vote on a membership
application or for the creation of a new working group to discuss
document-signing certificates. 

 

Kirk: They can offer an opinion, but no, they don't get a vote. 

 

Peter: So you're proposing a new class of member, which is a
working-group-only member, because we have interested parties but working
groups don't actually have formal votes today because they are done at the
Forum level. You are basically proposing a second-class member, a
working-groups-only member, not of the actual CAB Forum, therefore things
like the IPR policy apply to them, but they also don't have a chance to vote
on anything that is actually at the CAB Forum level. 

 

Kirk: So I wouldn't say this is a new class of membership. It's a new set of
voting rules for certain decisions that are pushed down to the working group
level and let them be decided there. We would have to decide if it is a
majority vote, is it two-thirds of all the working group members, that is
one of the issues. Actually, we'd be empowering them because if they are
interested parties today they don't really get to vote and now they'd get to
vote on things that are in the areas of interest where they signed up to
participate.

 

Peter: The most important thing is that they are not CAB Forum members. 

 

Jeremy: I don't think this is any easier to set up than creating the
umbrella organization so I would think that is an alternative proposal to
where there's the umbrella organization that gets to decide these things
with separate working groups under it where what we decide what the
membership of the organization is.

 

Peter: To paraphrase Kirk, he said, I don't want the current SSL stuff being
pushed down because we don't want some other group putting rules on how we
do it. I would expect that any other working group is going to have that
exact same feeling. Put another way, why is SSL a first class citizen and
every other working group has to be second class? 

 

Kirk: But don't forget we're only doing any of this because of CAs. This is
basically a CA issue. If Adobe and Oracle get an equal vote on a working
group for code signing or anything do you think they care about the issues
that are going on at the CAB Forum level? 

 

Peter: I don't think this is only about Adobe and Oracle. If you look at
Adobe it operates a trust list that is used today for document signing. I
think you'll find that there's a large number of entities that issue
certificates that are not eligible to be Forum members today, so the
definition of CA is going to have to change because there are audit schemes
that apply to CAs that do not issue SSL certificates that do issue some
other types of certificates that may be in these new working groups. 

 

Moudrick: I agree with Peter and just want to add something more. Today in
our bylaws we have three membership groups which are issuing CAs, root CAs
and browsers. What if we add a fourth membership group which would be the
signer group, or whatever we want to call it, organizations that produce a
different kind of software? In that case we will have more generic issuing
or root CA group not just bound to SSL alone and also have those who are
interested in using these certificates. Of course, it will be a separate
problem how we organize the voting because of the different interests of the
SSL and non-SSL group. But I think we will have the existing structure and
just add that one more group, then focus on the voting thing. 

 

Kirk: This makes me wonder why are we trying to keep these other groups in
the Forum? Let's just give them a copy of our bylaws and our IPR and tell
them to go form yourself. It really can be hard to keep all these disparate
groups with different interests all in a single organization. 

 

Virginia: That's my concern as well. 

 

Jeremy: I think it's not because although there are other members, it's
primarily the same players over and over again. If you look at the trust
list for Adobe there are a couple of new ones or a few additional members
that we would add, but for the most part the people discussing it are all
the same set of CAs. So from an organization standpoint and administrative
standpoint it's just easier to have these be the same group, and I think
that most members are probably interested in having these discussions and
being part of these discussions and having them here rather than in a
different group. 

 

Peter: It's not just the Adobe trust list, there's also groups working on
the EU trust list, since we're past July 1st, eIDAS, and in that manner
maybe Kirk is right. The other option is to do this in reverse-- yet another
group gets created and if later it turns out there is synergy we can merge
them. There's nothing to say that the meetings can't be held/set with CAB
Forum meetings. There is nothing to say that the CAB Forum can't choose a
meeting location, and in many cases have a different group find space in the
same general geographic vicinity on an adjacent day. I don't think that's a
huge challenge in most cases.

 

Kirk: Look at our schedule today. We have a few days of already jam-packed
meetings. And if there is a whole bunch of the people in code signing, they
are not going to want to come to one of our meetings for a two-hour segment
on code signing. So I'm not convinced that these multiple groups as a
logistical matter can meet in the same time same place, but that remains to
be seen. 

 

Jeremy: It happens with IETF though. You have people coming out for a few
meetings where they have an interest, and I think there's a precedent there
that that's exactly what people want to do. 

 

Andrew: And there is a precedent in our guest speakers who do exactly that. 

 

Kirk: I'm just saying that if any of these new groups that are non-SSL
really take off and have a lot of stuff they want to work on, it will affect
the logistics of hotel rooms, it will affect the logistics of meeting times
and places, and I don't know about you, but I don't want to spend five days
away on back-to-back meetings. I might prefer that code signing meetings
occur at a different time and place than SSL meetings. 

 

Jeremy: I still think that most members will be the same. I think you will
add a couple but I don't think it is going to change. There is no evidence
of that.

 

Peter: So, what is the path forward? I've heard a couple of options. 1- do
nothing, we don't change anything, the CAB Forum stay as is and essentially
stays as an SSL-only group.

 

Andrew: And what goes along with that is we jettison the
code-signing-specific parts of the documents we already have.

 

Peter: Yes, we would also want to jettison the EV Code Signing document. So
I think that is option one. Then the other option is to allow the CAB Forum
to expand in scope. Is there enough support for option two? 

 

Jeremy: We could do a poll. The only way you'll find out the feelings of the
entire CAB Forum is with a poll to decide which way you want to go. I think
the way forward is going to be similar to how we did the governance reform
before where you can have a group of proposals that get whittled down. The
first step in the poll is to see if there's interest in doing this. 

 

Andrew: Well, wasn't that the creation of this working group?

 

Jeremy: I think what we do is a poll of the different options. One choice is
do nothing and do just a reform of the SSL group with working groups. The
other is to form an umbrella organization and find out roughly which way the
Forum wants to go, and then proceed with that. 

 

Peter: And then I would actually pose a third which is not quite status quo,
but jettison the EV CS. 

 

Jeremy: I would like to keep it to two options.

 

Peter: I would propose three options. Is there anybody that sees the status
quo of code signing not being in the CAB Forum but the EV CS being in? 

 

Jeremy: Well, I don't think that all of us agree that code signing is not in
the scope of the CAB Forum. I think that the fact that we worked on the EV
CS guidelines in the CAB Forum shows that code signing is in the scope of
the CAB Forum despite what other people feel. There hasn't been a ballot to
exclude it.

 

Andrew: It is, but we might want to change it. The other thing about the
proposal to not push down SSL to working group might be an interesting
half-way house, or at least a first step. If we create a mechanism whereby
people could join a code signing working group, who are not members of the
top-level forum, it would provide a mechanism for those people to join, see
if anybody does. It wouldn't destroy the SSL top level. We wouldn't be doing
huge amounts of bylaw changes that affect our current work. And it wouldn't
preclude shaking out how that would work in the future. I don't think the
two options are mutually exclusive. 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/govreform/attachments/20160720/02cf32de/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4954 bytes
Desc: not available
Url : https://cabforum.org/pipermail/govreform/attachments/20160720/02cf32de/attachment-0001.bin