[cabfpub] Ballot 158: Adopt Code Signing Baseline Requirements

[Dean Coclin]

Thanks for your comment. I would like to refer you to the pre-ballot where
we posted the formulation of the baseline requirements, the participants,
and the fact that it has been an open process from the beginning. While it’s
true that an IPR agreement is required to participate, public drafts were
made available at 2 points during the last year to anyone that wished to
download them. In addition, we emailed contacts at large software companies
to invite them to download the drafts. One large software company that we
know of could not get the IPR signed but expressed interest in implementing
the results of our work.

 

Thanks,

Dean

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Adriano Santoni
Sent: Tuesday, December 15, 2015 10:56 AM
To: public at cabforum.org
Subject: Re: [cabfpub] Ballot 158: Adopt Code Signing Baseline Requirements

 

Although we have voted "yes" to Ballot 158, because they certainly are an
improvement on the current state of things, I also believe that certain key
stakeholders in the field of code signing, that are currently not
represented in the Forum, should at least have a chance to read the new Code
Signing BRs and share their opinion thereon, before the new BRs are
"enacted". It seems weird to me if this is not going to happen (unless it
already happened, unbeknownst to me), and if so I think that's a mistake,
although it's nobody's blame.

Adriano




Il 14/12/2015 18:45, Ryan Sleevi ha scritto:

Google votes NO.

 

While Google understands and appreciates the considerable effort to produce
these documents, as we previously indicated we would[1][2], we vote NO.

Rather than focus on the matters we disagree with, which have been
non-exhaustively but substantially documented in the past, I think it might
be better to look at possible paths forward. To that end, I’m going to set
aside some of the technical considerations from discussion, and instead
focus on the policies and process concerns, which are arguably more
important and require much more care to approach.

As our Bylaws state, we are primarily an organization of CAs and Internet
Browser software vendors. As reflected in our Bylaws, the voting membership
is made up solely of CAs and Browsers. This presents an existential
challenge to taking on any new work not within the scope of activities that
Browsers typically engage in—such as code signing, but also including
activities such as S/MIME certificate issuance or timestamping authorities.
These all have overlaps with PKI and policy, but whose constituencies lack
standing within the Forum.

If we are to take on new work—and, to be clear, we’re not fundamentally
opposed to the idea—it minimally requires revisiting how we structure
participation in the Forum. We’ve seen discussions range from opening the
Forum to greater public participation (which was rejected during the
Governance reform discussions), to structuring the Forum in more of an à la
carte participatory framework (in which the CA/B Forum becomes an umbrella
organization for multiple working groups, each in charge of a document, and
with their own voting/participation definitions), to seeing the creation of
independent entities (separate from the Forum) to take on these efforts. All
have trade-offs, but all work towards a goal of ensuring that the relevant
and affected constituencies for the work product documents of the Forum have
a venue to discuss, debate, and decide.

Equally important is to consider the implications of our IPR policy, and how
such work products can support or hinder participation. As presently
structured, all documents within the Forum are subject to the Forum’s IPR
policies; objectively, this is good, as it provides a broad range of RF
assurances from the members who participate in the Forum. However some
members had to leave the Forum due the Policy’s breadth, and we’ve seen the
challenges it poses for new members to participate. If we make changes to
how governance is structured—and, to reiterate, Google views this as
necessary in order for the Forum to progress on such non-browser work
products—then it also invites the discussion of whether our IPR policies
should reflect that of the governance structure.

Concretely, I mean that if WGs independently work on documents (such as a
hypothetical SSL/TLS WG, the S/MIME WG, the Code Signing WG), it may make
sense to structure IPR commitments to the scope of that participation. If a
member organization decides to participate in discussions of SSL/TLS, that
does not mean they have to stay actively aware of or participating in code
signing discussions in order to stay abreast of IPR risks or challenges, nor
do they have to worry about portfolio searches in the event of changes. This
presumably would encourage greater participation and reduce the risk of
attrition or aversion due to the policies. Alternatively, we may decide to
leave the IPR policy worded as is, broadly applying to all of the work
products.

Google is less concerned about the precise nature of how this is resolved
(beyond the broad strokes already outlined), but is certainly concerned that
these matters do get resolved before taking on such activities. It is
important for us, and no doubt for others as well, to have a clear
understanding of the commitments necessary for participation in the
Forum—both time and IPR—as well as ensuring that we have a clear path for
greater participation, but in a way that does not impinge upon the overall
security goals of the adopted work products.

[1] https://cabforum.org/pipermail/public/2014-August/003740.html
[2] https://cabforum.org/pipermail/public/2014-August/003750.html






_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public

 

-- 
Adriano Santoni 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151215/e258638a/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5747 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20151215/e258638a/attachment.bin