www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Official code signing certificate
Date Thu, 21 Mar 2013 15:35:21 GMT
On Thu, Mar 21, 2013 at 9:09 AM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Jürgen Schmidt wrote on Thu, Mar 21, 2013 at 13:32:40 +0100:
>> On 3/21/13 1:09 PM, Daniel Shahaf wrote:
>> > Jürgen Schmidt wrote on Thu, Mar 21, 2013 at 08:53:29 +0100:
>> >> On 3/20/13 9:37 PM, Daniel Shahaf wrote:
>> >>> So... what kind of certificate is that?  How much does it cost, what
>> >>> kind of year to year maintenance it requires, etc.
>> >>
>> >> for windows it is a
>> >> "Code Signing Certificates for Microsoft Authenticode
>> >> Digitally sign 32-bit or 64-bit user-mode (.exe, .cab, .dll, .ocx, .msi,
>> >> .xpi, and .xap files) and kernel-mode software. Provider for Microsoft
>> >> Windows Logo programs."
>> >>
>> >> see [1] and [2]
>> >>
>> >> [1] http://www.symantec.com/verisign/code-signing/microsoft-authenticode
>> >> [2] overview http://www.symantec.com/code-signing
>> >>
>> >> I found a price by Symantec of 499$/year (reduced prices for 2 or 3
>> >> years) but there was already an opportunity that we can find a sponsor,
>> >> potentially a provider of such certificates.
>> >>
>> >
>> > Can you summarise it for me with the marketing stuff stripped please.
>> > Is it "Any company can pay $500 a year to get a signing certificate
>> > which is trusted-by-default (via trusting Symantec) by all Windows
>> > installations"?
>> well money sells and everybody can buy a certificate for whatever
>> reason. I think it is comparable to any other certificates like for
>> domains etc. I don't know but I think the provider of such certificates
>> do some verification before you get or are allowed to buy a certificate.
>> But I don't know for sure.
> In SSL certificates the issuer checks your identity (much like most
> people would ask to see your passport before signing your PGP key).
>> Important is that today systems like Windows 8 or Apple with their app
>> store require signed applications that can be verified in some automated
>> way to check at least the certificate chain until the root certificate
>> etc. If it can't verified the user get informed with some dialogs to
>> request further approval or acceptance to continue.
> You're simply describing how certificates work (basically, we generate
> a secret and then Symantec signs f(secret) and we provide that signature
> to end-users --- who trust Symantec's signing key).
>> >
>> > Are there any strings attached here?  Would using such a cert grant
>> > any rights to Symantec/Microsoft/Endusers that ASF doesn't currently
>> > grant?
>> I don't understand. If Symantec for example would decide to sponsor such
>> a certificate the ASF would get a certificate with all the related data
>> to ASF. Means as publisher the user would see the ASF somewhere in the
>> verification process if necessary.
> What are the differences between your proposal and just
> using PGP detached signatures, other than the latter being a different
> technology and lacking the advantage of a pre-trusted key (Symantec's)
> and of integrated-in-the-OS (or required-by-the-app-store) verification.

PGP detached signatures are typically verified by human admins.  Code
sigining is typically verified by integrated signature-verification
code in end-user facing tools like browsers, anti-virus software and
operating system shells.

So the technology is different, though there is not really an
interesting cryptographic difference.  The important practical
difference is that the tool chain of the people consuming the
OpenOffice binaries expects a particular form of code signing.  That
is the recent trend.  Most recent versions of Windows and MacOS both
reject, by default, execution of binaries that are not signed.
Reputation-based heuristics in anti-virus also look at code signing as
a hint for trust.  None of these technologies look at detached

> For example: does releasing software under a certificate Microsoft
> pre-trusts (or into an app store Apple moderates) subject ASF to an
> indemnification clause towards that company?  Does it grant the company
> a license to use our trademarks in advertising?  Does it compel ASF to
> offer warranty to end-users?

We're not signing any agreement with Microsoft or Apple.  We're just
talking about a signing certificate that would be issued by, say,
Symantec, where their root certificate is pre-installed on Windows,
for example.  So instead of a "web of trust" like detached signatures,
we're dealing with a hierarchical chain of trust.

I believe that we'd be required to make some sort of assertion that
our code does not contain intentionally malicious software, but I
don't know the details of that statement.

In any case, if possible, let's focus on the Infra side of this here.
We should separately review the language of any agreements we need to
sign with Legal Affairs and/or the Board.



View raw message