incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <orc...@apache.org>
Subject RE: key signing
Date Wed, 10 Oct 2012 16:28:25 GMT
+1

An Apache CA would also be handy for setting up code signing (the kind carried in the code
package and recognized by operating systems, not an external signature of the kind being discussed
here).

To clarify one aspect of the Apache Trust Chain.

It is not about email.  It is about the public-key cert being on <https://people.apache.org/keys/committer/>
and the fingerprint of that cert being in the Account Record of the identified committer.
 It is the fact that only a person with the committer's credentials (or a highly trusted internal
party) can manipulate the Account Record to establish a fingerprint.  The appearance of a
name@ a.o e-mail as an identifier in the cert is not a free-standing claim.  It is verifiable
by confirming the Apache Trust Chain related to (1) that committer Apache Name/ID and (2)
the cert/fingerprint provided for that identity in the keys/committer/ directory.  Someone
who knows to do this can mark that certificate as one that is trusted in their own store of
certs without contributing to any WoT.

The security issues are around privacy of the committer's Apache credentials (same as privacy
of a secret key), security of modifications to Account Records (and whatever audit trails
there are), and security of the keys/committer records.  That is the transitive trust dependency
for the external signatures claimed to be made by that committer.  The foundation of the chain
is the validity of the issuance of the committer ID and credentials and their connection to
an iCLA for the e-mail to which the credentials were delivered.  

This process also depends on the trustworthiness of those individuals who produce and issue
the initial credentials and operate the services on which the trusted artifacts are retained.
 Since that is always the foundation, additional web-of-trust ceremony may be satisfying but
the attack surface is right here and unchanged.  (One could even argue that reliance on WoT
increases the attack surface, especially if folks rely on the WoT to the exclusion of the
Apache Trust Chain.)

I think the fundamental problems are that (1) this trust structure is not widely understood,
even among (new) committers, and (2) the process is opaque to external parties who might want
to know how an external signature earns ASF trust.  (I'm not certain that there are such folks,
apart from security wonks and vulnerability seekers, but that is no reason to avoid an understandable,
transparent account.)  

 - Dennis

PS: I do think one might want to threat-model the existing attack surface and see what can
be done there.  I am not sure it mitigates against malicious introduction of exploitable vulnerabilities,
presumably the real concern.  That requires examination of a much broader attack surface around
all the ways code can be injected and vulnerabilities passed undetected into an Apache release.
 There is a high level of trust placed in the processes used, and it has little to do with
the trustworthiness of digital certificates.

-----Original Message-----
From: Benson Margulies [mailto:bimargulies@gmail.com] 
Sent: Wednesday, October 10, 2012 04:20
To: general@incubator.apache.org
Subject: Re: key signing

I could argue that we'd be better-served with X.509 certs.
An Apache CA could be programmed to issue a cert to each committer.
Users would just verify the source CA, and we'd accomplish the goal of
giving users assurance.


[ ... ]


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message