[cabfpub] For Discussion: Code Signing Working Group Charter

Ryan Sleevi sleevi at google.com
Wed May 2 12:42:56 MST 2018


On Wed, May 2, 2018 at 3:34 PM, Doug Beattie <doug.beattie at globalsign.com>
wrote:

> Hi Tim
>
>
>
> As far as the voting logic, I like the proposed 2 voting groups because
> it’s important to have the Certificate Consumers represented with
> sufficient authority and power in the balloting process.  While only one
> member expressed interest in this role in the past, it’s possible there
> will be others this time around.  Maybe this could form the basis for
> Apple, Android, Oracle java or other eco system code singing, if they
> express an interest.
>

There is zero interest from Google in joining a Code Signing Working Group
on behalf of Android at this time. The discussion of Code Signing proposed
here relates to publicly trusted CAs, which are not part of the Android
code signing ecosystem.

I am curious as to whether you've spoken with representatives at these
other organizations, given that the code signing exercised by a number of
the respective products do not use nor benefit from publicly trusted CAs.


>  Like you said, we will need to police this to be sure that the core
> Consumers get the voting power they need.  I’d also be interested to hear
> that Microsoft and other Certificate Consumers think about this.  We’d
> prefer to avoid Code Signing baseline requirements that are then modified
> by Certificate Consumer Code Signing policies.
>

Isn't the experience from the Web PKI demonstration of the inevitability of
this, especially given that a package 'signed' in a way compatible with,
say, a Microsoft code-signing tool is inherently incompatible with any
other vendor you listed.

I think it's critical to define the objective of such as Working Group - I
presume your goal is to ensure that Third-Party Entities (CAs) can perform
some form of Identity-vetting service for a Software Supplier. If so, it
would be useful to actually catalog what sort of systems are involved in
such mutual trust. In systems that are bereft of such mutual trust - for
example, Android - there's no need to be involved in a CSWG because there's
no need for mutual agreement on any certificate profile or practices.

Incidentally, this is a rather significant flaw of language related to
"Certificate Consumer", in that it's intrinsically overbroad in scope (for
example, one can consume code signing certificates without ever interacting
with a third-party entity, such as GlobalSign).


> I agree that this working group should be for those certificates with the
> id-kp-codeSigning EKU, but I wouldn’t rule out additional EKUs being
> present (at least for now).
>

Could you explain more? It's far better to start with a narrow scope, and
then, if you have legitimate need, broaden it, rather than to start with an
unnecessarily broad scope. If you have concrete ideas in mind, it might be
good. Alternatively, rechartering the WG when there is consensus to adopt
such a broader scope equally seems appropriate - and can undergo the full
review as appropriate.


> Do you think we’ll need our own Network and Certificate System Security
> Requirements [3], or can we reference something?  I hate the idea of
> keeping more documents in sync.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20180502/461ce54e/attachment.html>


More information about the Public mailing list