Following up on Benson's statement, I want to confirm my understanding of how the "LDAP key" connection works:
1. I generate an OpenPGP key pair for myself. I use orcmid@ a.o as an e-mail address associated with the PGP cert. I put the public key in an appropriate public place where it can be found by the fingerprint, my name, orcmid@ a.o, etc. (Does it matter which established public place is used for this part?) 2. I go to the Apache Account Utility, <http://id.apache.org> and log on with my Apache credentials for Apache User Name/ID orcmid. 3. I add the OpenPGP Public Key Primary fingerprint in the appropriate field of the account details. 4. Somewhere there is a way that anyone who sees a signature with the private key (1) can confirm that public key cert carrying that fingerprint is the one in (3). I have to say "somewhere" because the link on the ASF Committers by ID page, <https://people.apache.org/keys/group/svn-committers.asc> is a 404. A little URL fiddling reveals that the correct link is <https://people.apache.org/keys/committer/>. When I complete the ceremony (3), I assume orcmid.asc will appear in that directory by virtue of my having completed (1) successfully. So, the level of trust, in this case, is via the fact that I used the Apache credentials to record the details of a key pair for which I am expected to have the exclusive possession of the private key. And my possession of the Apache credentials for ID orcmid establishes the connection between the PGP key, orcmid, and the person who provided the iCLA for which ID orcmid was subsequently granted. A repudiation, along with the public ways of doing that, is by removing the fingerprint from my Apache Account record, yes? I might want to leave an expired-but-not-repudidated fingerprint there, since it is needed to check old signatures? (The Account page appears to limit me to two such keys, but that may just because there are no entries just yet.) If I understand this correctly, I have to agree with Benson that it can't be any better than this. The fundamental link is the association that is established by my being responsible for the secrecy of the private key and my Apache "persona" being tied to the possessor of that Apache account, how that account was approved, how the credentials were delivered for it to the provider of the iCLA, and the exclusive control of the setting of the fingerprint in the account record. It appears that key-signing ceremonies add nothing to this. My public appearance might reveal that orcmid is an imposter or that the iCLA is fraudulent or something, but that applies to the chain of committer establishment trust, not whether I can convince folks to sign my public-key cert. I agree that all of this needs to be documented in an understandable way, and that members of the public need to know how to verify and authenticate signatures created with these private keys. - Dennis -----Original Message----- From: Benson Margulies [mailto:[email protected]] Sent: Sunday, October 07, 2012 08:32 To: [email protected] Subject: Re: key signing - issues Shane, After reading all the responses, I'm no longer very interested in pushing the idea of key signing. I am much more interested in explaining to users the existence and use of the LDAP keys. We can explain: "If something is signed with a key associated with an Apache committer via the Apache infrastructure, then you have assurance of the pathway from Key -> Apache Account -> CLA on file. Even if the key is not signed at all, this tells you that the signature comes from the named Apache account." The bigger the Foundation gets, the less likely that any number of key signing parties at ApacheCons are going to put a dent in all the possible release managers. I suppose that comdev could try to organize a web of key signing parties that aren't at ApacheCons. --benson --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
