www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: Official code signing certificate
Date Thu, 21 Mar 2013 13:09:24 GMT
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.

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?

View raw message