[cabf_governance] Draft Notes of Meeting July 19, 2016

[Ben Wilson]

Here are draft notes of our call last Tuesday.

 

Present:  Dean, Rich, Peter, Kirk, Rich, Jeremy, Patrick, Virginia, Robin,
Mike, Moudrick, Jos, Ben 

 

Kirk:  I think on the last call we talked about, and I tried to capture what
I thought were the three main alternatives and the pros and cons of each.  I
invited people to modify and correct. My recommendation is that we first try
to either work with that document or some other documents and lay out the
basic choices and directions. Perhaps this group will reach consensus on
which way to go. I think it would be wise to take it back for a quick trip
to the CAB Forum to say, "this is what we're thinking of" to get input from
a larger group so we don't end up drafting something that then fails after a
lot of work on our part. And related to that is I think we have to keep our
laser focus on what problems we encountered in the past, and my analysis was
twofold. One is the code signing working group had its product fail because
of Mozilla and Google voted "no".  Then second, is that some people like
Oracle and Adobe chose not to participate as interested parties in the code
signing working group apparently because they didn't like the IPR agreement.
So in my mind those two things are kind of the first things for us to
diagnose.  What would work to make it better? And then once we've got that
figured out and some assurance that any of these changes will actually be
approved by these people or will change how they view this in the future,
once we know that, then we can draft stuff. 

 

I came up with three options. These could be tweaked, and they're not the
only options, but one is basically do nothing-keep the CAB Forum only for
SSL certificates. Other projects have to go somewhere else and maybe form
their own groups, and I think if we did that we wouldn't necessarily change
the IPR policy.  The second option is to change the IPR policy.  It would
stay as RAND-Z, but we would put in a participation element.  So it's not
triggered for a company, a member, or an interested party or member unless
they actually participate in a project.  If they are careful and choose not
to participate either at the working group level or at the Forum level then
they never have to disclose anything, or license or share anything. And the
third option is we follow the W3C model where the Forum itself at the top
group is nothing but a coordinating committee and doesn't work on any
substantive issues.   All work occurs at working group levels, and we push
them to a new working group. I think there's been an expression that there
ought to be uniformity.  At one time people were saying that we would allow
different working groups to have different IPR agreements.  I have heard
some resistance - that it's too complicated for companies to track and stay
on top of, so I think that probably we would try to find a uniform IPR
agreement that would cover all those groups.  

 

The open questions are:  if we did any of those things would that satisfy
Google and Mozilla?  But if we did option two - the participation thing
where they could stay out of something if they didn't want to be involved
would that satisfy them?  Would option three satisfy them?  The separate
question is with any of the options 1, 2, or 3, would they bring in people
like Oracle and Adobe.  Dean, I think you're the only one who had direct
contact with Oracle and Adobe. They didn't like our IPR agreement, and one
important thing, a threshold question, is would they feel more like
participating if we had a participation with RAND-Z, or do you want to go to
RAND?

 

Jeremy:  I don't think it is a relevant question because I think that the
governance reform needs to happen regardless of whether it brings in new
membership.  I think there's a lot of topics that we prefer to discuss that
don't require the involvement of those two.  

 

Kirk: Well one of the problems that we have discussed is that we can't get
these guys to participate, so we have treated it as a relevant problem.  At
least we'd like to know the answer.  Do we know if there is anything we
could do that would cause them to participate?  

 

Dean:  I don't think you're going to get a concrete answer to that.  All you
can do is remove obstacles that have come up in the past, and whether we
remove those obstacles and they still say, "you know, we're really not
interested this time," you can help that by removing those obstacles so that
they don't say, "no, I can't join because of that."  

 

Virginia:  I would like to understand what they think are obstacles and why
is it important for the CAB Forum that they join.  

 

Jeremy:  Well, I don't think that it is important for them to join. I think
that's exactly what I'm saying.  I don't see their participation as the
important factor in this whole reformation process.  It seems to be more of
a red herring as far as reorganization goes.  The point is to expand the
scope so that we can actually discuss relevant issues such as code signing
without objection.

 

Rich: I just wanted really quick to say we respectfully disagree with that
position. I don't think it is wise to expand our scope unless we are looking
to bring in members who have a vested interest in the scope we're moving
into.  I think that was a big part of Google's and Mozilla's objections to
code signing. It was that other than CAs there was nobody with skin in the
game except for Microsoft on the user side of things to participate and
craft the specifications. So without that I really don't see that there is
anything to do.  

 

Jeremy:  That wasn't the reason they cited for voting "no."  They said it
was out of scope.  

 

Peter: There were three things between the two of them.  I think Opera voted
against it as well. I think there were between the three they indicated a
mixture of things. There were potentially IP issues, definition scope of the
Forum (but I think that itself is not an issue-I think that's related to IP
and other things), and I think there's also added that it's not the
objective of the CAB Forum to be the policy review board for Microsoft.  The
point of the Forum is to help align or come to agreement with multiple
vendors.   The code signing guidelines are only adopted by Microsoft, so
that I think is definitely relevant.  Does the CAB Forum just want to be the
Microsoft policy advisory board?

Kirk:  That's why we wanted to bring in Oracle and Adobe. 

 

Jos:  I think it is important to remember that scope for this is larger than
just code signing.  Let's pause for a moment to think about S/MIME and let's
think about IOT.  There's plenty more out there besides code signing, but
obviously code signing is an important part of this discussion because it
has come up in the past.  There are plenty of other beyond-the-current-scope
agenda items that need addressing that also have to do with certificate
management and would bring in other participants.  I'd be surprised if Apple
and Mozilla for example didn't have at least some interest in email signing
since they do it, and I think that there were a couple of others that came
up during previous meetings, so I think we would have other users that are
interested in. So I think it is important not to put blinders and not
rat-hole entirely on code signing.

 

Kirk:  I think that's a fair point.  Code signing is what led to us looking
at governance again, but you're right, it is a bigger issue.  

 

Andrew:  Communication with Adobe and Oracle to find out details of the
objections of how we could change to accommodate them might be a model for
others.  I'm not sure we would want to just accept any changes that they
would like, but it is no difference to us.  Hearing from their lawyers I
think will be interesting.  

 

Rich:  That was my point as well.  It wasn't specific to code signing, or
Oracle and Adobe specifically, it is important go through this whole
exercise and completely rework our forum.  We need to get some outside input
on parties that may be interested in joining other than Oracle and Adobe.
Let's approach some of the groups that deal with S/MIME as well see so we're
not just spinning our wheels and we end up going through this for months,
develop a new policy, split the Forum up, and we still have something that
nobody wants to deal with, and we're right back here at square one. 

 

Jeremy:  We'd at least have the scope extended to discuss client
certificates and code signing certificates.  

 

Rich:  If the goal is to bring out other members in the discussion, I see no
point in completely revamping the Forum.  

 

Jeremy:  I don't think you can do it that way.  

 

Peter:  I think that this also goes into what we output. When we look at
option three, especially the discussion on how we create working groups, and
option 2, it sounds like one of the things that needs to be in the bylaws or
is functionally going to be a requirement is multiple non-CA members.  In
other words, whenever a working group is proposed there would have to be at
least two non-CA members proposing to join that working group-- if the
objective here is to not have the Forum simply be a customer advisory board
for various organizations.

 

Jeremy:  But it really is a customer advisory board for various
organizations.  We work on stuff for Mozilla, we work on stuff for
Microsoft, stuff for Google and Apple.

 

Peter:  There are certain organizations, for example US federal PKI, have
their own policy working groups that define what their policy is. They are
adopting the CAB Forum shared certificate policy. The question is whether
the CAB Forum is ever an appropriate venue to do a certificate policy for a
single PKI?  

 

Kirk:  The main reason we do this is that all of the CAs come together and
meet up in the CAB Forum.  It was for our convenience, and it was great that
we had one company that was interested.  I don't buy off on the idea that to
have a working group on a subject we have to have another party there if
it's useful to CAs by themselves and does no harm at all to the browsers who
are not interested, then why shouldnt we be able to meet and do it? 

 

Jeremy:  I agree.

 

Kirk:  Now one possibility I think I may have written for option two is the
non-SSL certificate issues that are resolved as the product out of a working
group cannot come back the CAB Forum itself for approval.  That way, if
browsers aren't interested in it, they don't even have to vote on it at the
Forum level. 

 

Peter:  So back to what are we trying to solve.  It sounds like there is not
a desire to solve the advisory board objection, but that we want to provide
a vendor-neutral venue for discussion of shared standards or common issuance
practices or something like that for CAS. With all deference to our
colleagues the browsers what I'm hearing is the statement that the CAs want
to create a shared policy that could be adopted by browsers but they also
want the ability to create products that are outbound, e.g. certificates
that represent car serial numbers or something like that.

 

Kirk:  Yes.  One of the points that people made about code signing was there
is no standard.  So a bad guy could get rejected at a CA with more rigorous
standards and look for another CA with easier standards, so that was one of
the things we were trying to accomplish here.

 

Peter: Right, but code signing has a shared relying party, maybe not relying
party, but code signing falls within some sort of PKI, right?  Adobe, or I
guess Adobe doesn't really choose, but Microsoft, for example, when they're
choosing who to include as trusted issuers.  There could be situations where
CAs just decide that they want to offer some product in what browsers might
consider to be a private shared PKI, but you'll have a common policy root
set up where it says, if you want to trust that kind of certificate, here is
this common policy. That sounds like it could be in scope.  

 

Kirk:  Well, the guidelines don't apply to browsers either.  The browsers
are only participating to provide their input because they do rely on SSL
server certificates and display them and so forth, but they don't follow
those guidelines.  We found a new thing that was useful for CAs and probably
the public that happened to chain to trusted roots, although they don't have
to, and the browsers that don't rely on code signing certificates said we
don't want to participate in this, but otherwise I think it was a pretty
good project for the Forum to be working on, and the fact that one browser
said we do rely on this, I don't think that should have poisoned the output
and caused other browsers to say, well, we're going to veto it because we
don't rely on it.  

 

Jeremy:  I think the perception is that it was one browser, but actually it
is many CAs that are working on this. So saying that only one member is
interested is incorrect because the CAs were interested not just one
browser.

 

Andrew:  Doing generally useful things because they are useful butts up
against the scope of the Forum. With the code signing working group we don't
take issue with that.   It's that we need to find more of a way that that
sort of work would fit inside a wider scope.  

 

Dean:  It was clear that the people that voted against it thought that that
the work product was fine, they just thought that the venue was the wrong
place.

 

Peter:  Andrew, seeing as you also represent a vote against it, if the
bylaws changed to expand the scope, does that resolve your issue?

 

Andrew: That would remove one of the blockers. The other two are whether you
have skin in the game and the IPR issues.  It all goes together.  What I was
really getting at is just because something is useful for some people
doesn't mean that the Forum is currently constituted to address it.  

 

Peter:  By skin in the game, you're referencing a non-CA / relying party
representative involved?

 

Andrew: Yes. The example is usually a software vendor that does not issue
SSL certificates.  You can imagine a CA that only issues code signing
certificates and not SSL certificates voting on something that didn't affect
them at all.  

 

Kirk:  So skin in the game is a concern that too many people who don't have
skin in the game might participate as opposed to too few people who ought to
be there?  When you say skin in the game you're afraid that some people
might get involved who don't actually have a stake in the outcome and
shouldn't vote, is that right?

 

Andrew:  Correct. There's also the question about would it be the correct
thing to have only one software vendor in a working group?  I'll have to
think about that.  

 

Kirk:  So we developed the EV guidelines before any browser committed to
doing anything about it, so I strongly think that if CAs want to create a
new product and they go out and proselytize for applications not just
browser applications to recognize, then I think we should be allowed to do
that.  We can easily change the scope broaden it.  So I am curious, was the
IP issue on voting on this at the Forum level would then trigger a mandatory
disclosure requirement by everyone and that was something Google didn't want
to do on the code signing issue, is that a fair statement?

 

Andrew:  I believe it was, but unfortunately I was not involved at the time.


 

Kirk:  If we had a participation model so Google could say, we'll just not
to participate, would that solve the issue?

 

Andrew: I think so.

 

Dean:  This was before your time as well, but when we had the last
governance reform meetings back 3 to 4 years ago Paypal with Google's
backing actually was advocating to have everyone, any interested party,
become a voting member of the Forum and that approach was rejected, so this
seems like a change of direction from what it was a few years ago. Am I
right?

 

Jeremy:  Not all CAs rejected it, but Google was one of the primary parties
looking for general public involvement and widespread membership.  

 

Andrew:  I just want to change  tack and see what people's opinion was on
option two as a steppingstone for option three.  Would we want to consider a
short-term, medium-term, long-term objective?  I could see option two
occurring and not precluding a future option three.  

 

Kirk:  Would you be saying that we're committed one day to move to three, or
that we just keep the door open to moving to three?

 

Andrew: Just to keep the door open.  My thinking is that under the cons of
section 3 there is the concern that after 11 successful years of doing this
model we through everything up in the air and what comes down isn't as
efficient and we want to get the kinks worked out.  Taking code signing or
S/MIME or something that is not a working group and setting it up in the
model of option two would allow the procedures to settle in, to figure out
what it means to administer a participation-only working group and not
interrupt the day-to-day working of the top level of the Forum and then it
would provide an opportunity for everybody to look at what it is like having
run the model for a year or so with changes before we moved to option 3 for
the entirety of the organization. It's just a thought that wouldn't
inextricably commit us to option 3.  

 

Kirk:  It makes sense.  If we don't get any extra participation by making
these changes to the IPR agreement there is a question in my mind about
whether option three is worth trying. 

 

Peter: I think we're supporting three as well because trying to sort out the
IPR situation in option two seems very challenging.  Option three appears to
have a clean IPR solution, whereas two is much less clear.  

 

Kirk:  Wouldn't it be the same IPR policy under two and three? Participation
with RAND-Z? 

 

Jeremy:  But participation becomes weird when you have an administrative
group that includes the SSL group with the code signing and client groups
under it.  So that's also one of the reasons we do like option three better
because it opens the door to additional participation that doesn't
necessarily have to happen right at the reformation stage.  It permits
people to come and join in working groups to be created as new problems
arise instead of having to have this strange side situation where the SSL
certificate community controls all of the other communities that are using
PKI.  We already know that the client certificate community is probably
bigger than the SSL community yet it would be the small portion controlling
the big portion.  

 

Kirk: That is why we want option 1. 

 

Jeremy:   Because most of the players are the same--it's just that the
interests are different.  For example, most of the European CAs primarily
issue client certificates instead of SSL certificates, so they are here at
Forum meetings and are interested in the SSL portion. If 99% of the players
are the same, let's just revise it and make sure that they can participate
in the things they really want to.

 

Kirk:  With option 1, the other organization could schedule its meetings
back-to-back with the Forum.  You still get that efficiency of being in the
same place.  

 

Jeremy:  You find that a lot of the synergy that that happens between us
naturally as we are just talking. When we are talking about digital
certificates there's a lot of things that go on and as we already see with
trying to define what an SSL certificate is.  There's a lot of interplay
between the various types and so it would be nice to have a forum that can
address those synergies and those interoperability issues.  That is why we
support option three over the other two. 

 

Peter:  The other thing I said in email is I would strongly encourage that
regardless of if we go with option three, which we support, but also even if
the decision is for option two, I think the word "participate" is far too
confusing for people.  It essentially turns into a legally defined term.
It's far too easy to assign a different definition to "participate" in the
meaning like the dictionary definition rather than that, we need to make
sure to substitute in the specific definition that is intended. For example,
I think there's confusion about what happens if you stay silent on calls or
don't think because you are not participating, and I think with what comes
with the IPR agreement it is important to understand that.  With the W3C
agreement and many other standards groups, even if you fail to do any
action, you are participating.  So I think that we need to because the buses
it appears I would strongly encourage that that term gets changed simply so
that it is not unclear to people and that you are still subject to the
agreement even simply by joining.  In other words, you don't join any calls
and you don't do anything, but you are still subject to the agreement.

 

Kirk: So I know we need if we go to a participation model, we clearly are in
favor of having the agreement be very clear, and on that I think Virginia
knows a lot about that as do other people, so I think that it almost goes
without saying that, yes, if we go to the participation model we will have
to be very clear what that means, and I thought we would follow a model set
by somebody else.  So I'm concerned about resources. We don't favor model
three, but if it gets adopted, do you think we can do it with the existing
resources and no budget and no staff?  

 

Peter:  I do.  To me model three, other than a minor procedural change,
doesn't appear to be any different than what we currently do from a
staffing-requirements perspective.  It has a major legal potential
difference that isn't going to involve staffing.  

 

Kirk: And explain the benefits again of pushing SSL down into its own
working group and maybe explain who would be in the parent group making the
coordinating decisions.

 

Peter:  So I think in our view the only thing that the parent group does
outside of the kind of actions that we've already mentioned kind of happen
on the management list. The doodle poll, where do we want to meet, what
dates, and stuff like that.  The parent group, I believe, would only approve
creation of a new working group and presumably they may determine that a
working group needs to cease. I think those would be the only two actions
that would come into play. They would specifically never approve any
technical standard, that would be explicitly excluded.  So the difference
between number one and number three is almost administrative. All three
working groups would have the same IPR policy and it is a
working-group-membership-based IPR policy, which is what the W3C calls
"participation."  And the biggest advantage versus number one is the fact
that you are only joining once.  There's one signing of the IPR policy and
administratively, everybody who joins the Forum .  it might even be that the
voting action, kind of what Google had apparently mentioned prior to my
participation . there might even be no such thing as an interested party.
It is purely members, and each working group would have voting members under
it, but possibly it could be that everyone who signed the IPR policy is a
voting member at that top level. Again because the only two things that I
think would ever come into play are the creation and dissolution of working
groups.

 

Jos: I would put forward that actually depending on how you structured it,
modifications to the IPR policy itself might fall under that group, but
again that's probably not a huge overhead if we don't change it that much.

 

Peter: Right.  IPR policy and bylaw changes would be the other two things
that would be there at that level.

 

Andrew:  Something to keep in mind is potential technical de-confliction
between working groups' products.  So, imagine we had a payments terminal
working group who said it was absolutely in our best interests to carry on
with SHA1. And everyone said, yes, but what you're just proposing allows a
payment terminal certificate to be pivoted into any other kind of
certificate at all.  That would be problematic. One could imagine bylaws
saying that any technical standards created by a working group must be
technically distinct using whatever constraint mechanism.  That might be
something else that the top level would consider to make sure that working
group products remain independent.  

 

Peter:  That could be within the scope, but I am very hesitant to have
anything technical though at that top level.  I could see that there could
be a working group that defines . because part of it is that you're assuming
that they're shared roots in that case.  So when you day you could turn X
into Y, that assumes that the issuer is trusted for both, and I think that
it is not necessary to de-conflict everything simply because PKI is not a
global system.  

 

Andrew:  Indeed.  It's mostly getting ahead of the situation where something
goes wrong and puts web browser users at risk. The CA could say, "but we're
following the exact letter of this other working group's requirements." And
yes, using separate roots would be a fine way of technically constraining
them.

 

Peter:  I see where you're going with that, but I think part of the answer
is that today if you want to place a root there are numerous independent
trust stores who each have their own rules, and many of them have their own
contract, and if a CA wants to include a root in multiple trust stores they
have to de-conflict those policies or find how they can build their own
policy that complies with all of them.  I think that if two working groups
build policies then it's really up to the people implementing them as
policies to have to de-conflict them.  I think it's entirely
possible--undesirable but possible--that two Frum working groups create two
standards that cannot technically be issued under the same CA.  I can
imagine standard one that says "all certificate signed must use elliptic
curves and compressed points, etc.: and number two says, "all certificates
under the standard must use RSA."  There would be no way to issue under the
same CA.  

 

Andrew: It's more realizing than if you have a system where software vendors
are all trusting simply based on, "is this root included?  Yes/No."  Then
you have the possibility for cross-contamination but between certificate
types.  It may be that  every working group's product needs to have a
section which explains why or how its certificates can be distinguished by
relying parties. But we see all sorts of things like OCSP responding
signatures being able to be turned into CA certificates, and those sorts of
things.

 

Peter:  Back to the original question-we have Kirk's email on the three
methods.  Where do we want to take this?

 

Dean:  A couple things we want to do since we have the face-to-face coming
up in August.  One of the things that we want to do is create an agenda that
uses the input from what we've been discussing.  We need to craft an agenda
that can be productive for the day and with desired outcomes for the day. We
want to use it to address everyone's concerns here.  We want to look at
everyone's proposals.  Virginia what is open that we haven't addressed?

 

Virginia:  I still don't understand why we are considering making a change.
It seems we asking what do Google, Mozilla, Adobe, and Oracle want, but I
don't understand what their issues are and why it would be important for
them to be members, and why we need to make a change?  I think those issues
need to be addressed and we need to have a convincing reason why we need to
choose an option to change before we pick one of the options.  It seems to
be a foregone conclusion to some that we need to  make a change and that we
need to pick one of these options, but I'm still at square  one trying to
figure out why we are considering a change at this point.

 

Dean:  Okay, so let's get back to that right away now because it is
important to discuss. So, I think the reasons we're looking at making a
change are: one, getting more participation, getting the right participation
in the areas of focus that we want to be looking at, for example, at
present, code signing, S/MIME, document signing, IOT devices, etc.  So
increased participation and the right participation is one of the areas, and
when we say participation, we can have participation today, right?  We have
interested parties and associate members.  Those people can't vote,
therefore it was argued the last time we had these meetings, was that these
people would be reluctant to participate if they didn't have a voice or vote
in this.    

 

Virginia:  Do we know who we want to participate and why they aren't
participating? I don't think it works to guess, "well, they're probably not
participating because we don't have this." On these calls I've heard some
kinds of vague reasons, like, "oh, I talked to them and that won't work,"
but I haven't heard any specific reasons. Like, what does Oracle not like?
What does Adobe not like?

 

Dean: So, for example, in code signing, there are only a few application
software suppliers in the ecosystem for code signing.  You've got Microsoft,
Oracle, Adobe, and a few others. There is not that many that rely on code
signing certificates.  So, when we were doing the code signing baseline
requirements we canvassed those application software suppliers to ask them
to participate and join and to get feedback because we want this document to
be applicable to more than just Microsoft. And the feedback we got,
specifically from Oracle who owns Java, is that they could not participate
under the current IPR rules.  That was feedback number one. 

 

Virginia:  But do we know what specifically about the IPR rules would keep
them from participating.  

 

Dean:  I wish Jeremy was in line them with the details, but Ben, do you
recall if it had to do with the RAND versus RAND Z?

 

Ben:  Well, I think Virginia does have some valid points and that we would
need to probably go back and get some specific feedback from them.  And I
think on previous calls we said, "well, yeah, let's go back and get some,"
but we just have gotten around to doing that.  

Virginia: So I think that is critical to have prior to the face-to-face
because we need to react to specific feedback instead of just saying, we
think that it is this or that, and then we're adjusting something that may
or may not be correct.

 

Dean: That's fine. I think that we can get data. We have records that we can
go back and find.  So, the second reason that participation was lacking in
the past, and this is the evidence that we had from PayPal who at the time
was participating, was that interested parties weren't really interested in
doing all this work and participating, attending calls, and everything when
they had no vote in the issue. So the lack of a vote was another issue for
not participating.

 

Virginia: So, if they want to vote, why didn't they become members?   

 

Dean:  Because the way the Forum was structured, they were not a CA or a
browser and therefore they could not become a member, and that is the way it
works today.  If you're not a CA or a browser, you can't vote.

 

Andrew:  Just one more thing about the question whether we wanted to make
any change.  I would say that option one would include jettisoning the EV
code signing requirements and really just draw a very clear line around the
Forum scope of being TLS only, and that leaves the EV code signing
guidelines open to being adopted by another organization.  So that was one
reason why I think we need to choose one of the options to clarify the scope
and handle the code signing.

 

Dean:  It's all outlined in your memo, right?

 

Andrew:  Yes.  We do have a few more spots if you  want to  use the  chair's
prerogative to invite anybody else.  . 

 

Dean:  As Andrew said, the EV guidelines.  Getting a home for the EV
guidelines is another reason because right now they're out of scope of the
current Forum and it's a Forum document.  

 

Kirk:  People can participate that are interested parties at the working
group level under option two, if we make final decision on the standard,
leave it at, for non-SSL issues, leave it at the working group level, then
they can vote and they're just as important as everybody else.  So, we can
solve that one without going all the way to option three.

 

Dean: I'm still back where Virginia is, and just trying to answer some basic
questions.  She asked, why are we making this change and what are the
issues.  And so I've laid out a few things here.  Is there more that we need
to lay out there?

 

Peter: Regardless of getting more participation, there is a desire of CAs to
be able to do things outside of the scope of SSL certificates, and I believe
that there is value in doing it within the same organization and under the
same IPR agreement for some CAs and for other organizations as well, but I
think that if it is a separate organization, even with a duplicated IPR
agreement (that simply searches and replaces the term "CAB Forum" with "Code
Signing Forum" or something), that is more work for some organizations.  So
how do we expand the scope within the organization has value to some members
today. Conversely, some of our browser members have indicated that they
don't want organizations if they don't have appropriate skin in the game.
They don't feel that they should be voting on it because they don't have
skin in the game. So I think that that is the number one driver of this.  If
we happen to be able to get additional members representing skin in the game
for other things, great, but I think we heard solidly today that there are a
number of members who see it valuable to just have a CA industry consortium
or a venue for CAs to develop new products that they would each sell
independently, but that meet a common need.

 

Dean:  It is rare for CAs to work on products that don't work with other
things.  So for CAs to get together and work on something without the other
party that is affected by whatever CAs do wouldn't be productive.

 

Peter: Well, that was the argument that that was what EV certificates were.


 

Kirk: All I said was that if you build it they will come. Sometimes CAs have
an idea and better to proceed and develop the standards and then try to sell
it to the people you think will buy it. So I think Peter and I are in
agreement on that.

 

Dean: Okay, I'm going to outline this stuff because we keep rehashing some
of this over and over again.  I want to outline this on paper and address
the issues from the beginning and then we have to get to the next phase
which is, OK, here are the options which Kirk has nicely outlined for us,
and there might be some hybrid approaches, there might be some modifications
that we want to do, and then get to something that we can discuss at the
face-to-face.  At the end of the face-to-face we should be able to say,
"okay this is the option we think it's going to work the best given all
these issues, all of these inputs that we're getting, here is the option
that works the best that we can recommend.  We don't have to come to a final
conclusion that day, but at least we should be able to put a stick in the
ground and say this the one we think is the best one at this point. 

 

Kirk: The reason we're rehashing some of these things is that some people
have made up their minds that it's only for that, and other people are
saying, "are you sure?"  So I'm not sure I agree that it has been useless
rehashing.

 

Virginia:  Dean, if we could include the specific feedback we've received
from Microsoft, Oracle, Adobe, Google, and Mozilla, somewhere I think it
would be very helpful. Not just that they don't like it, but what their
specific feedback was so that we can take that into consideration as well.

 

Peter:  And we'd love to get any feedback that your organization would like
to provide, good or bad, as well.  For example, things you do or don't want
to see, I think we will welcome that feedback as well.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/govreform/attachments/20160722/b3e9de86/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/20160722/b3e9de86/attachment-0001.bin