+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:[email protected]] Sent: Wednesday, October 10, 2012 04:20 To: [email protected] 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: [email protected] For additional commands, e-mail: [email protected]
