Re: key signing
On Mon, Oct 15, 2012 at 1:46 PM, Benson Margulies bimargul...@gmail.comwrote: 1) send email to him and his PMC fellows, referencing this thread, as evidence that key signing is nice but optional. This seems like the most sensible option. AFAIK, signed keys have never been required to sign releases for Apache. (I'm the only one with a signed key on CouchDB.) Perhaps the project has by-laws that require it, in which case, this prospective release manager may need to wait a little while longer. -- NS
Re: key signing
It had to be done, given this thread's epic proportions... ;) [image: Identity] http://xkcd.com/1121/ On Fri, Oct 5, 2012 at 1:04 PM, Benson Margulies bimargul...@gmail.comwrote: I'm offering this discussion here, but it might need to go elsewhere if it goes anywhere at all. It seems to me that the there is a gap in the incubation process, and I don't know how to fill it. As far as I can see, we don't do anything to facilitate or encourage getting PGP keys signed. We tell people to create a key and put it in the SVN 'keys' file. Key signing strikes me as a bit of a conundrum for us. In all other respects, we emphasize that anyone, anywhere, in any time zone, can be a full member of a community. However, key signing requires something else. [1] Generally, it requires a face-to-face interaction. It is perhaps interesting to note that the foundation accepts CLAs as legally binding without any face-to-face identity verification. If you send in a CLA with a signature, we believe it, and we believe that the email address you provide is, in fact, controlled by the legal person who signed the form. I wonder, then, if secretary@ should be willing to sign a key. Alternatively, since the chain is CLA - svn access - unsigned key in svn, perhaps all we really need is to document that a signature corresponding to a key in svn is really good enough, and users need not be concerned further. [1]: http://httpd.apache.org/dev/verification.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- NS
Re: key signing
Now I have a practical problem. I've received email from a committer on a project. I have met him in person -- some years ago. I helped him get started at Apache. His fellow PMC members are telling him that it's *necessary* for him to come up with one or more signatures on his key to act at an RM. Choices: 1) send email to him and his PMC fellows, referencing this thread, as evidence that key signing is nice but optional. 2) go ahead and sign his key based on simple email. I'm a very bad paranoid; I'm not interested in the idea that some person out there is anxious to undermine Apache and has captured one or both or our gmail accounts, or is acting as an MITM. I have plenty of writing-style evidence that this email address disgorges communications from him. 3) Engage in some more or less baroque protocol involving skype or carrier pigeons. Anyone care to try to tell me what to do? My views are colored by my, and his, complete disinterest in the WoT outside of its use at Apache, and my conviction that I do, indeed, know that this key is under the control of a particular person who signed a CLA and got voted in as a committer of a particular project. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Mon, 15 Oct 2012, Benson Margulies wrote: Choices: There is another option, which I mentioned in the other key signing thread on members@, which applies equally here too. Reposting my answer from there, with a few tweaks... In-person keysigning doesn't just have to be at ApacheCons, there are more frequent and more geographically distributed options too! Most BarCamps do keysignings, and some meetups too. They tend to be more geographically spread than ApacheCon, and they're much easier to organise. [1] In addition, we have the Apache Local Mentors program, which I'd encourage all IPMC mentors to sign up to if they haven't already: http://community.apache.org/localmentors.html As well as going to your nearest local Apache mentor for advise on getting into open source, help with understanding the Apache way etc, you could also ask them to sign your key. Even if you can only get one link into the WoT from one local mentor, it's still much better than nothing! So, for a short-term fix for your potential Release Manger, I'd suggest you get them in touch with a nearby local mentor. IPMC mentors should sign themselves up for the local mentors program, to help out future new RMs :) Nick [1] If you're interested in organising something in your local area, be it a BarCamp, Meetup etc, small-events-discuss@ is the place to lurk / ask advice / seek volunteers / get going etc! http://mail-archives.apache.org/mod_mbox/www-small-events-discuss/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Mon, Oct 15, 2012 at 5:46 AM, Benson Margulies bimargul...@gmail.com wrote: Now I have a practical problem. I've received email from a committer on a project. I have met him in person -- some years ago. I helped him get started at Apache. His fellow PMC members are telling him that it's *necessary* for him to come up with one or more signatures on his key to act at an RM. Choices: 1) send email to him and his PMC fellows, referencing this thread, as evidence that key signing is nice but optional. In my opinion, the best thing to do would be to forward links to Daniel Shahaf's post describing the multiple-signer workflow and the relevant section of Subversion's release policy documentation. http://s.apache.org/NG2 (link to mail-archives.apache.org) https://subversion.apache.org/docs/community-guide/releasing.html#tarball-signing That technique seems far-and-away the most appropriate answer for Apache projects. 2) go ahead and sign his key based on simple email. I'm a very bad paranoid; I'm not interested in the idea that some person out there is anxious to undermine Apache and has captured one or both or our gmail accounts, or is acting as an MITM. I have plenty of writing-style evidence that this email address disgorges communications from him. 3) Engage in some more or less baroque protocol involving skype or carrier pigeons. The advantage of adopting an existing protocol (a la http://cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html) is that individuals don't have to roll their own -- they can just follow the recipe. The virtual protocol discussed earlier in this thread never got beyond the proposal stage before it was rendered obsolete by Daniel's suggestion. If you don't want to spend mindspace on this topic, I'd suggest adopting the policy of I only sign keys at key-signing parties. Or eventually, if the ASF develops a formal policy, adopt that. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Mon, Oct 15, 2012 at 6:02 AM, Nick Burch apa...@gagravarr.org wrote: So, for a short-term fix for your potential Release Manger, I'd suggest you get them in touch with a nearby local mentor. Why is raising the barrier to entry for new Release Managers better than having multiple experienced PMC members sign a release? What if there's no local option? Should the PMC regretfully forego the services of this volunteer RM? Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: key signing
@Benson There are two things that can be done, with (2) being what matters to you, it seems to me: 1. The committer can upload the fingerprint-associated public key to the PGP Global Directory at http://keyserver.pgp.com/. That will initiate an e-mail verification for every e-mail in the pubkey record (cert for short). The procedure and its risks are described in the Key Verification Policy, http://keyserver.pgp.com/vkd/VKDVerificationPGPCom.html. The key will not be published on that server until the e-mail verification occurs. It will there be countersigned by the PGP Global Directory Verification Key. Note that there is a revocation procedure and revocation (i.e., removal from that directory) will happen if one of the periodic e-mail confirmations fails. Here's an example of how those counter-signings show up: http://pgp.mit.edu:11371/pks/lookup?op=vindexfingerprint=onsearch=0xD80D0C3FA39327EC The e-mail verification is vulnerable (as described in the Key Verification Policy) in much the same way that Apache credentials and Account records are vulnerable with respect to the use of e-mail association as authentication. 2. In conjunction with checking for the key at (1), or independently, the advice from the PGP folk is that an independent means of identity agreement should be employed. So long as you have a way of doing that, and the other party can confirms that is the public key for which they possess the secret key, it seems appropriate to countersign the public key. Technically, this should not rely on the e-mail address. Use a different channel whereby the committer confirms identity, including having or knowing something that satisfies you. Since you can be confident about your own public key, have the party send you an encrypted message that satisfies you concerning the identity of the originator. That message plaintext could also be signed by the party, demonstrating their possession of the private key for the pubkey in question. The odd thing about the WoT is that it depends on how much *you* are considered dependable in verifying the cert creator's identity. Each inspector of the committer certificate determines their own trust of the counter-signing signatures (whether by WoT transitivity rules or their own personal knowledge/trust). -- Dennis Since I dropped in on this thread, I went through the key registration process for a unique key that only has orcmid@ a.o as the associated e-mail. The public key was put wherever the Gnu Privacy Assistant puts them. I uploaded the public key to the MIT PGP key server myself. I also went through the PGP Global Directory verification procedure. I put the fingerprint in my Apache Account record and a version of the cert magically appeared at https://people.apache.org/keys/committer/orcmid.asc. (I'm not sure where this is fetched from, so I'm not sure how counter-signed versions show up.) I am continuing to experiment. -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Monday, October 15, 2012 05:46 To: general@incubator.apache.org Subject: Re: key signing Now I have a practical problem. I've received email from a committer on a project. I have met him in person -- some years ago. I helped him get started at Apache. His fellow PMC members are telling him that it's *necessary* for him to come up with one or more signatures on his key to act at an RM. Choices: 1) send email to him and his PMC fellows, referencing this thread, as evidence that key signing is nice but optional. 2) go ahead and sign his key based on simple email. I'm a very bad paranoid; I'm not interested in the idea that some person out there is anxious to undermine Apache and has captured one or both or our gmail accounts, or is acting as an MITM. I have plenty of writing-style evidence that this email address disgorges communications from him. 3) Engage in some more or less baroque protocol involving skype or carrier pigeons. Anyone care to try to tell me what to do? My views are colored by my, and his, complete disinterest in the WoT outside of its use at Apache, and my conviction that I do, indeed, know that this key is under the control of a particular person who signed a CLA and got voted in as a committer of a particular project. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Dennis E. Hamilton wrote on Mon, Oct 15, 2012 at 11:07:56 -0700: https://people.apache.org/keys/committer/orcmid.asc. (I'm not sure where this is fetched from, so I'm not sure how counter-signed versions Currently keys.gnupg.net https://svn.apache.org/repos/asf/infrastructure/site/trunk/people/keys-fetch.py show up.) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: key signing
Ah, so the key servers federate! Cool. Thinking about the Man-in-the-Middle PKE attack, that is a little difficult with OpenPGP. That involves a man in the middle substituting their public key for mine and also arranging to intercept messages sent to me that are encrypted using the MitM public key for decryption and re-encrypted with my actual public key. Since I can easily tell whether or not the public key retrieved from any one of the key servers is one that goes with the secret key I have, it is pretty difficult to prevent me from detecting a public-key substitution. And I can check even deeper than matching fingerprint reports. I think that is enough for two distant participants who are known to each other to find a way to confidentially exchange something private known only to the two of them as a way to confirm that their respective public keys are authentic and worthy of signing. It does depend on our actually being known to each other in a way that allows such a procedure to be contrived. I'm going to try that with a distant friend of mine. - Dennis -Original Message- From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Sent: Monday, October 15, 2012 11:22 To: Dennis E. Hamilton Cc: general@incubator.apache.org Subject: Re: key signing Dennis E. Hamilton wrote on Mon, Oct 15, 2012 at 11:07:56 -0700: https://people.apache.org/keys/committer/orcmid.asc. (I'm not sure where this is fetched from, so I'm not sure how counter-signed versions Currently keys.gnupg.net https://svn.apache.org/repos/asf/infrastructure/site/trunk/people/keys-fetch.py show up.) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Greg Stein wrote on 10/10/12 6:44 PM: I've read this entire thread (whew!), and would actually like to throw out a contrary position: No signed keys. +1 -- Peter Karman . http://peknet.com/ . pe...@peknet.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On 10.10.2012 00:01, Marvin Humphrey wrote: While this protocol does not rely heavily on validating government-issued IDs, the Debian guidelines quoted above point out that some people object to giving such IDs too much creedence: So instead of giving too much credence to government-issued IDs, you'd prefer to give credence to a service provided for free by a commercial entity with a conceivable interest in inserting backdoors in software or subverting trust in certain keys (a.k.a. Google), with the whole thing being archived in as system controlled by another commercial entity (a.k.a. YouTube, incidentally a.k.a. Google), with no public oversight of those archives. I'm sure you'd sue Google and win if they fake the archive. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On 11 Oct 2012, at 00:44, Greg Stein wrote: Please explain how keys are needed for this ASF release? Consumers are already told to verify the SHA1 and nothing more. I doubt any more is needed. SHA1 offers no more protection than a checksum against MITM attack. (assume secure Infrastructure) You have to extend that assumption not only to our infrastructure but to every proxy that might come between us and a user, and that might substitute a trojan along with the trojan's own SHA1. -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On 11 October 2012 02:39, Daniel Shahaf d...@daniel.shahaf.name wrote: Greg Stein wrote on Wed, Oct 10, 2012 at 21:31:30 -0400: Not too much. We still instruct users take the signatures and verify them against blah.apache.org/KEYS. John Blackhat could replace the signatures and install his entry into KEYS. If you use https://people.apache.org/keys/ instead of KEYS files in the dist/ tree, John would have to crack two machines rather than one. Last time I looked, the process downloads the key from a PGP server (which does not provide any auth at all) using the key id(s) in LDAP. I assume you mean John would have to obtain credentials to be able to alter the key id in the signer's LDAP record? AFAIK, this is the same LDAP that is used to authenticate SVN access (which is all that is needed to upload new archives and KEYS). Seems like a single point of failure to me - or maybe I am missing something here? /plug :-P - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Thu, Oct 11, 2012 at 9:01 AM, Nick Kew n...@apache.org wrote: You have to extend that assumption not only to our infrastructure but to every proxy that might come between us and a user, and that might substitute a trojan along with the trojan's own SHA1. The same reasoning holds for the .asc file. A MITM attack might involve a mirror replacing the release artefact, along with the .md5, .sha, and .asc files. If the user is only verifying against those files, then everything might look kushti. (Assuming they skip the step where they're supposed to import the KEYS file, or assuming someone replaced that too.) Which is why we link to the .md5, .sha, .asc, and KEYS files on our severs. Unless you're assuming a MITM along the request/response path to apache.org, in which case all bets are off anyway. No? -- NS
Re: key signing
On Thu, Oct 11, 2012 at 9:48 AM, sebb seb...@gmail.com wrote: On 11 October 2012 02:39, Daniel Shahaf d...@daniel.shahaf.name wrote: Greg Stein wrote on Wed, Oct 10, 2012 at 21:31:30 -0400: Not too much. We still instruct users take the signatures and verify them against blah.apache.org/KEYS. John Blackhat could replace the signatures and install his entry into KEYS. If you use https://people.apache.org/keys/ instead of KEYS files in the dist/ tree, John would have to crack two machines rather than one. Last time I looked, the process downloads the key from a PGP server (which does not provide any auth at all) using the key id(s) in LDAP. The recommended procedure is to ask the users to download the KEYS file directly from the root of the dist dir, and import all the keys directly from that. As far as I know. That's how we do it on CouchDB. I think httpd does that too. -- NS
Re: key signing
On Thu, Oct 11, 2012 at 10:57 AM, Noah Slater nsla...@tumbolia.org wrote: Which is why we link to the .md5, .sha, .asc, and KEYS files on our severs. Unless you're assuming a MITM along the request/response path to apache.org, in which case all bets are off anyway. No? Which is why I have my release vote messages include the .asc files in the actual vote. This way people can verify that the vote that is being carried out is done on the right artifacts including the correct .asc files. Perhaps I need to include the .asc contents in the release announcements as well (though that might be overkill). Martijn - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
sebb wrote on Thu, Oct 11, 2012 at 09:48:25 +0100: On 11 October 2012 02:39, Daniel Shahaf d...@daniel.shahaf.name wrote: Greg Stein wrote on Wed, Oct 10, 2012 at 21:31:30 -0400: Not too much. We still instruct users take the signatures and verify them against blah.apache.org/KEYS. John Blackhat could replace the signatures and install his entry into KEYS. If you use https://people.apache.org/keys/ instead of KEYS files in the dist/ tree, John would have to crack two machines rather than one. Last time I looked, the process downloads the key from a PGP server (which does not provide any auth at all) using the key id(s) in LDAP. I assume you mean John would have to obtain credentials to be able to alter the key id in the signer's LDAP record? AFAIK, this is the same LDAP that is used to authenticate SVN access (which is all that is needed to upload new archives and KEYS). Seems like a single point of failure to me - or maybe I am missing something here? LDAP is a single point of failure, but with that you can't forge anything without causing a post-commit email. /plug :-P - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On 11 Oct 2012, at 13:19, Benson Margulies wrote: Over and above that, we could then ask, 'how could we improve protection against most complex problems?' Now that's something the ASF might indeed be well-qualified to hack. Improved end-user tools (e.g. browser plugins) to take advantage of the PGP/WoT infrastructure. Including supplementary resources like Apache Keys. -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: key signing
+1 I'm assuming Benson means the digest (SHA1) by signature. Using those from the Apache site is probably the first-line for power users and about as much extra effort that can be expected. The use of download utilities that reliably check signatures from authentic sources is a small boost -- for power users. - Dennis The verification of the external signatures also on the Apache site is something that I believe is material only for review of the release candidate and also any subsequent forensics work if there is a problem. In all cases, the public-key cert should be obtained from the Apache site keys folder. The most-significant improvement in this, for binaries at least, is the use of embedded signatures that are verified as part of operating-system functions on the relevant platform. That's as low-friction as it gets and users don't have to take any special steps at all, other than pay attention to the warning dialogs that the platform coughs up. -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Thursday, October 11, 2012 05:20 To: general@incubator.apache.org Subject: Re: key signing Greg having more or less restated my opening position (how do we improve assurance for probable actual users), I'd throw in another bit. Threat analysis is all well and good, but it please don't forget the biggest principle here. If the assurance mechanism is so abstruse that users won't understand it, or so complex that they can't use it, then they won't, and they will be at the mercy of the dumbest possible attack. Before we worry about MITM, or subverted Apache infrastructure, I claim that we should be offering users a simple, easy-to-understand means of protecting against fraudulent packages. As per Greg, the signatures do that. As per me, unsigned keys verified against Apache infrastructure do that. Over and above that, we could then ask, 'how could we improve protection against most complex problems?' - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On 11 Oct 2012, at 09:57, Noah Slater wrote: On Thu, Oct 11, 2012 at 9:01 AM, Nick Kew n...@apache.org wrote: You have to extend that assumption not only to our infrastructure but to every proxy that might come between us and a user, and that might substitute a trojan along with the trojan's own SHA1. The same reasoning holds for the .asc file. Only if there are no WOT paths to improve confidence in it. And only if noone ever detects the imposter, which is a lot less likely with a trojan PGP key (someone in particular is being impersonated) than a checksum (owned by noone). -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: key signing
I see I committed the sin of using signature two different ways, below. I mean the file digest value (digital hash, SHA1) for what power users and appropriate downloader utilities check. I mean the external digital signature and the signers public-key cert in the Apache keys with regard to checking digital signatures on release candidates and in any subsequent forensic investigation/confirmation. - Dennis -Original Message- From: Dennis E. Hamilton [mailto:orc...@apache.org] Sent: Thursday, October 11, 2012 08:19 To: general@incubator.apache.org Subject: RE: key signing +1 I'm assuming Benson means the digest (SHA1) by signature. Using those from the Apache site is probably the first-line for power users and about as much extra effort that can be expected. The use of download utilities that reliably check signatures from authentic sources is a small boost -- for power users. - Dennis The verification of the external signatures also on the Apache site is something that I believe is material only for review of the release candidate and also any subsequent forensics work if there is a problem. In all cases, the public-key cert should be obtained from the Apache site keys folder. The most-significant improvement in this, for binaries at least, is the use of embedded signatures that are verified as part of operating-system functions on the relevant platform. That's as low-friction as it gets and users don't have to take any special steps at all, other than pay attention to the warning dialogs that the platform coughs up. -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Thursday, October 11, 2012 05:20 To: general@incubator.apache.org Subject: Re: key signing Greg having more or less restated my opening position (how do we improve assurance for probable actual users), I'd throw in another bit. Threat analysis is all well and good, but it please don't forget the biggest principle here. If the assurance mechanism is so abstruse that users won't understand it, or so complex that they can't use it, then they won't, and they will be at the mercy of the dumbest possible attack. Before we worry about MITM, or subverted Apache infrastructure, I claim that we should be offering users a simple, easy-to-understand means of protecting against fraudulent packages. As per Greg, the signatures do that. As per me, unsigned keys verified against Apache infrastructure do that. Over and above that, we could then ask, 'how could we improve protection against most complex problems?' - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: key signing
@Nick I don't understand the supposed attack vector concerning the file digests being of no value and the WoT being essential. - Dennis ANALYSIS So long as the digest value is obtained from a reliable read-only source, it doesn't matter where the file comes from, the digest can be verified. This will protect against and help detect a poisoned mirror site or a third-party redistribution that substitutes an inauthentic artifact. That is, in fact, a very big deal and it defends against exploits that happen too regularly. If the reliable read-only source is compromised, that means an adversary has managed to (1) replace the file in Apache custody, and (2) replace the digest that applies to that artifact. (Or just replace the digest and make the authentic file look bogus and the poisoned downloads look authentic.) If substitution of the file-digest pair is achievable, providing a different external signature can't be much harder, although the exploit might achieve the intended purpose without that. Introducing a verifiable external signature that finds a counterfeit public-key certificate on a key service may extend the ruse a little longer. The exploit continues until some Apache folk or security-proficient external party detect (1) the substitution or (2) a counterfeit external signature or (3) confirms that the external signature is not verifiable on the substituted file and digest pair. I don't see the WoT as much of a factor if this exploit occurs. It comes down to how quickly the exploit is detected, the damage detected, and a mitigation put in place. I assume that infrastructure defense-in-depth measures have to expose the fact of an exploit, even if an insider is involved. At the worst, it might be necessary to recall a release. This assumes that the exploit is by exploit against the read-only distribution material in Apache custody. If the exploit is by tampering with a release prior to its approval, that is an entirely different problem, since it means the digital artifacts have been approved as authentic. Even so, I think it is the trustworthiness committers, release managers, and PMC approval that matters here, not the WoT, and that is bolstered by the Apache Trust Chain. The WoT does not protect against someone subsequently being revealed to have committed a bad act. (The revocation of trust and how it is noticed is an aspect of WoT that I have not investigated.) -Original Message- From: Nick Kew [mailto:n...@webthing.com] Sent: Thursday, October 11, 2012 06:46 To: general@incubator.apache.org Subject: Re: key signing On 11 Oct 2012, at 09:57, Noah Slater wrote: On Thu, Oct 11, 2012 at 9:01 AM, Nick Kew n...@apache.org wrote: You have to extend that assumption not only to our infrastructure but to every proxy that might come between us and a user, and that might substitute a trojan along with the trojan's own SHA1. The same reasoning holds for the .asc file. Only if there are no WOT paths to improve confidence in it. And only if noone ever detects the imposter, which is a lot less likely with a trojan PGP key (someone in particular is being impersonated) than a checksum (owned by noone). -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On 11 Oct 2012, at 17:14, Dennis E. Hamilton wrote: @Nick I don't understand the supposed attack vector concerning the file digests being of no value and the WoT being essential. - Dennis ANALYSIS So long as the digest value is obtained from a reliable read-only source, it doesn't matter where the file comes from, the digest can be verified. This will protect against and help detect a poisoned mirror site or a third-party redistribution that substitutes an inauthentic artifact. That is, in fact, a very big deal and it defends against exploits that happen too regularly. In saying a reliable read-only source, you're glossing over the MITM. My browser may say foo.apache.org when in fact it's talking to my evil ISP's proxy. If the reliable read-only source is compromised, that means an adversary has managed to (1) replace the file in Apache custody, and (2) replace the digest that applies to that artifact. Yes, for those communicating directly with an apache server. We can improve the security of that using https, but that too is a weaker security model due not least to the variable quality of the CAs. (Or just replace the digest and make the authentic file look bogus and the poisoned downloads look authentic.) Funnily enough I diagnosed a rather similar issue for my mother only yesterday. A site at which she's shopped before had evidently been compromised, and the attacker had sent her email she took for genuine, while she was suspicious of a 'confirm your change of password' email that was almost certainly genuine (but useless). And the compromise had happened at least a month earlier, as evidenced by two monthly trojanised 'newsletter's from the attacker. Anecdotes aside ... If substitution of the file-digest pair is achievable, providing a different external signature can't be much harder, although the exploit might achieve the intended purpose without that. Introducing a verifiable external signature that finds a counterfeit public-key certificate on a key service may extend the ruse a little longer. A trojan PGP key is plausible. Trojanised signatures are possible, though the bar seems to me to be rising. But a trojanised chain of trust leading back to a trusted signature? That raises the bar a long, long way. And within the ASF we have a lot of WOT interconnectedness: to impersonate an ASF key you'd need in effect to impersonate a whole lot of us. It's a many-eyes scenario, and those eyes will tend to route to tech-savvy brains. I'm at an advantage: when I download an Apache bundle, I can generally trace a chain of trust back to myself. If I find something signed by Dennis E. Hamilton but without enough ASF sigs to establish a chain of trust back to myself, I *will* query it, so an imposter is going to have hijacked your ASF email if (s)he's going to intercept my query and prevent you or me raising the alarm. Add to that other checks (e.g. does the project have an IRC channel, how old is the key and does that check out, if nothing checks out then ask the project dev list). Multiply that by lots of other folks who check PGP keys carefully, and that's a much higher level of security than some mere checksum. The exploit continues until some Apache folk or security-proficient external party detect (1) the substitution or (2) a counterfeit external signature or (3) confirms that the external signature is not verifiable on the substituted file and digest pair. Not the signature . A whole lot of signatures. Each with a real person to notice something is wrong, unlike an unowned checksum. I don't see the WoT as much of a factor if this exploit occurs. It comes down to how quickly the exploit is detected, the damage detected, and a mitigation put in place. I assume that infrastructure defense-in-depth measures have to expose the fact of an exploit, even if an insider is involved. At the worst, it might be necessary to recall a release. This assumes that the exploit is by exploit against the read-only distribution material in Apache custody. If the exploit is by tampering with a release prior to its approval, that is an entirely different problem, Sure. If someone we elect as committer smuggles in a trojan, no amount of security after the event will help. That's a different issue to the one I thought we were talking about. -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Thu, Oct 11, 2012 at 12:00 AM, Branko Čibej br...@apache.org wrote: So instead of giving too much credence to government-issued IDs, you'd prefer to give credence to a service provided for free by a commercial entity with a conceivable interest in inserting backdoors in software or subverting trust in certain keys (a.k.a. Google), with the whole thing being archived in as system controlled by another commercial entity (a.k.a. YouTube, incidentally a.k.a. Google), with no public oversight of those archives. The beauty of multi-factor authentication is that any one factor may have weaknesses, so long as it remains infeasible to compromise all of them. Giving an unaccountable proprietary entity like Google a role is indeed a weakness, just as relying on fallible amateurs to detect potentially forged government-issued IDs is a weakness. In a layered system, neither weakness need be fatal. I'm sure you'd sue Google and win if they fake the archive. I'm confused as to what attack vector you're describing here. Since Google controls the only copies of the video, in theory they might photoshop its content to alter the appearance of one of the participants -- but that seems implausible because of technical challenges. It's possible Google could accidentally misplace some video content, though. In the sample/rough-draft protocol I described, the archived video serves two purposes: In the short term, it provides footage for third parties contacted out-of-band (via e.g. phone or email) to review and provide testimonials: Yes, that's my colleague Noah Slater, who I've known for 5 years. Should the video archive mysteriously vanish before that loop closes, key signing aborts and the system remains uncompromised. In the long term, the archived video serves to deter would-be identity spoofers by capturing their faces and voices for posterity. An attacker who has the ability to remove the video (conspirator, rogue employee, cracker who has compromised Google's servers or more likely the account hosting the video) would still have to overcome other obstacles -- establishing control over an ASF committer account, preventing third parties contacted out-of-band from raising red flags, etc. It seems to me that the potential dissappearance of archived video degrades deterrence by a small amount, but that so long as other factors retain their integrity, the degradation is nowhere near enough to bring down the system. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Wed, Oct 10, 2012 at 2:36 PM, Nick Kew n...@apache.org wrote: On 10 Oct 2012, at 17:04, Marvin Humphrey wrote: In my opinion, we have sufficient expertise here at the ASF to devise an authentication protocol whose reliability exceeds that of individuals participating unsupervised in a web of trust, particularly if the protocol were to incorporate archived video and auditing by a PMC. That may be, but I don't think general@incubator is the place to develop it. The Incubator is where the acute need exists, because we are bootstrapping entire communities where no one is linked into the web of trust. For existing projects, the longer they've been around, the more likely that a significant number of committers have attended an ApacheCon key-signing party or otherwise had an opportunity to get their keys signed. But here, we see new RMs all the time who are isolated. It would be nice if we had some systematic way of integrating them. In the absence of a formal protocol, suggesting that new RMs go find someone to sign their key is unsatisfying, since at least some of the time that's likely to mean email contact alone and potentially a tenuous relationship to the signer. The alternative of suggesting that new RMs with a release VOTE pending go find a local key-signing party to attend seems unrealistic. In my opinion, general@incubator is an appropriate venue to explore ways in which the system can be improved. That will necessarily mean talking about some implementation details because it would be silly to assess feasibility otherwise, but please note that the proposed protocol was labeled a rough draft. Maybe we can call it sample instead, implying the need to start over later -- it doesn't matter to me. I had always imagined that if the protocol were to move forward it would undergo a process of relentless scrutiny and refinement by interested parties outside the Incubator. The payoff is that with a protocol in place which enables us to establish identity to a high degree of certainty and add an individual to web of trust on a short turnaround, the Incubator need not approve another release signed by an RM who is not linked into the ASF web of trust. FWIW for myself I like to back WOT paths by checking manually, and feel best about it when I can identify a chain of trust involving only people I trust to be savvy enough not to sign keys willy-nilly. PGP/GPG support different levels of trust, so the model helps there. The PR challenge is a separate question. I will acknowlege that I have been taken aback by the extreme skepticism in what I view as a straightforward application of the principles of multi-factor authentication, faithful to the spirit and letter of the GnuPG docs. It pains me that the only outcome of this discussion may be that it gets even harder to make an incubating release. :( Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: key signing
@Marvin, Can you say more about Multi-factor? I know commonly-claimed schemes involve the same factor multiple times (e.g., more things that a party knows, like Aunt Gracie's dress size). I agree that confirming a picture ID (something the individual has) is another factor. What other factors are you thinking of? (I am not sure how many factors signings by others count as new factors.) - Dennis -Original Message- From: Marvin Humphrey [mailto:mar...@rectangular.com] Sent: Thursday, October 11, 2012 11:46 To: general@incubator.apache.org Subject: Re: key signing On Wed, Oct 10, 2012 at 2:36 PM, Nick Kew n...@apache.org wrote: On 10 Oct 2012, at 17:04, Marvin Humphrey wrote: In my opinion, we have sufficient expertise here at the ASF to devise an authentication protocol whose reliability exceeds that of individuals participating unsupervised in a web of trust, particularly if the protocol were to incorporate archived video and auditing by a PMC. That may be, but I don't think general@incubator is the place to develop it. The Incubator is where the acute need exists, because we are bootstrapping entire communities where no one is linked into the web of trust. For existing projects, the longer they've been around, the more likely that a significant number of committers have attended an ApacheCon key-signing party or otherwise had an opportunity to get their keys signed. But here, we see new RMs all the time who are isolated. It would be nice if we had some systematic way of integrating them. In the absence of a formal protocol, suggesting that new RMs go find someone to sign their key is unsatisfying, since at least some of the time that's likely to mean email contact alone and potentially a tenuous relationship to the signer. The alternative of suggesting that new RMs with a release VOTE pending go find a local key-signing party to attend seems unrealistic. In my opinion, general@incubator is an appropriate venue to explore ways in which the system can be improved. That will necessarily mean talking about some implementation details because it would be silly to assess feasibility otherwise, but please note that the proposed protocol was labeled a rough draft. Maybe we can call it sample instead, implying the need to start over later -- it doesn't matter to me. I had always imagined that if the protocol were to move forward it would undergo a process of relentless scrutiny and refinement by interested parties outside the Incubator. The payoff is that with a protocol in place which enables us to establish identity to a high degree of certainty and add an individual to web of trust on a short turnaround, the Incubator need not approve another release signed by an RM who is not linked into the ASF web of trust. FWIW for myself I like to back WOT paths by checking manually, and feel best about it when I can identify a chain of trust involving only people I trust to be savvy enough not to sign keys willy-nilly. PGP/GPG support different levels of trust, so the model helps there. The PR challenge is a separate question. I will acknowlege that I have been taken aback by the extreme skepticism in what I view as a straightforward application of the principles of multi-factor authentication, faithful to the spirit and letter of the GnuPG docs. It pains me that the only outcome of this discussion may be that it gets even harder to make an incubating release. :( Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Marvin Humphrey wrote on Thu, Oct 11, 2012 at 11:46:23 -0700: On Wed, Oct 10, 2012 at 2:36 PM, Nick Kew n...@apache.org wrote: On 10 Oct 2012, at 17:04, Marvin Humphrey wrote: In my opinion, we have sufficient expertise here at the ASF to devise an authentication protocol whose reliability exceeds that of individuals participating unsupervised in a web of trust, particularly if the protocol were to incorporate archived video and auditing by a PMC. That may be, but I don't think general@incubator is the place to develop it. The Incubator is where the acute need exists, because we are bootstrapping entire communities where no one is linked into the web of trust. For existing projects, the longer they've been around, the more likely that a significant number of committers have attended an ApacheCon key-signing party or otherwise had an opportunity to get their keys signed. But here, we see new RMs all the time who are isolated. It would be nice if we had some systematic way of integrating them. In the absence of a formal protocol, suggesting that new RMs go find someone to sign their key is unsatisfying, since at least some of the time that's likely to mean email contact alone and potentially a tenuous relationship to the signer. The alternative of suggesting that new RMs with a release VOTE pending go find a local key-signing party to attend seems unrealistic. No one said that a release need have only one signature... 1) RM prepares tarball, signs, uploads for voting 2) voting passes 3) mentor appends his signature to the .asc file 4) artifacts posted to dist/ That solves the problem for end users until the RM attends a keysigning party. Daniel (for reference, Subversion requires 3+3 signatures for every release) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Marvin Humphrey wrote on Thu, Oct 11, 2012 at 11:46:23 -0700: In my opinion, general@incubator is an appropriate venue to explore ways in which the system can be improved. That will necessarily mean talking about I am sure there are crypto minds in the ASF who aren't on general@incubator. some implementation details because it would be silly to assess feasibility otherwise, but please note that the proposed protocol was labeled a rough draft. Maybe we can call it sample instead, implying the need to start .. and if you said We need to design a protocol, and the usual reasons for not doing that do not apply, they are precisely the guys whose attention you'll need. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Thu, Oct 11, 2012 at 1:29 PM, Daniel Shahaf d...@daniel.shahaf.name wrote: 1) RM prepares tarball, signs, uploads for voting 2) voting passes 3) mentor appends his signature to the .asc file 4) artifacts posted to dist/ That solves the problem for end users until the RM attends a keysigning party. +1 Great solution. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Can you clarify? I understand that being able to speak to someone face to face, and seeing their mannerisms and expressions, allows you to understand them better. Some deep rooted human thing. But how does this impact security or trust, in the context of key signing? On Wed, Oct 10, 2012 at 4:00 AM, Ted Dunning ted.dunn...@gmail.com wrote: If you know the person, it adds something that you don't get. On Tue, Oct 9, 2012 at 3:40 PM, Noah Slater nsla...@tumbolia.org wrote: What, precisely, does a video call actually provide? The point of meeting in person is to verify photo IDs. Just talking to somebody with a face doesn't prove anybody. I am fairly certain that YOU have a face, and I have never even seen it. If all you're doing is having a chit chat and swapping key IDs, you may as well do that via IRC or email. Doing it with a video adds nothing, as far as I can see. It certainly does not establish identity. Beyond a person who says their name is Bob has a face which looks like [this]. Is that useful? I don't think so. On Tue, Oct 9, 2012 at 11:01 PM, Marvin Humphrey mar...@rectangular.com wrote: On Mon, Oct 8, 2012 at 2:24 PM, Noah Slater nsla...@tumbolia.org wrote: 1. The key owner convinces the signer that the identity in the UID is indeed their own identity by whatever evidence the signer is willing to accept as convincing. Usually this means the key owner must present a government issued ID with a picture and information that match up with the key owner. (Some signers know that government issued ID's are easily forged and that the trustability of the issuing authorities is often suspect and so they may require additional and/or alternative evidence of identity). 2. The key owner verifies that the fingerprint and the length of the key about to be signed is indeed their own. How would you do this via Skype? Here's a rough draft for a protocol: Several podling committers convene in a Google Plus Hangout with Hangouts On Air enabled (so that the video gets archived to YouTube). Everyone states their name and what they had for lunch, then reads their public key fingerprint aloud. The lunch items are combined into a key phrase. Participants then commit to a text file under ASF version control, contributing a few lines containing their name, their public key fingerprint and the key phrase -- linking together face and voice, public key fingerprint, ASF credentials and by extension, an iCLA. Optionally, the project is then discussed by the participants for some arbitrary length of time; the discussion of shared experience adds another layer of confidence that participants are who they say they are. Physical IDs are *not* shown during this session because the video is to be archived in a public location, but participants are encouraged to request such ids via private channels later. After the session ends, the archival video link is submitted to the podling's dev list, giving people the opportunity to initiate contact via email, phone or other channels with the committers in question -- or better yet their associates and colleagues, pointing to the video link and requesting confirmation of identity. Once a potential key-signer believes that a high degree of certainty has been established for a given candidate (it may make sense to codify some best practice guidelines), they sign the key and report to the dev list, documenting both what key was signed and what criteria they used when deciding to sign. ... While this protocol does not rely heavily on validating government-issued IDs, the Debian guidelines quoted above point out that some people object to giving such IDs too much creedence: (Some signers know that government issued ID's are easily forged and that the trustability of the issuing authorities is often suspect and so they may require additional and/or alternative evidence of identity). Instead, it relies on a layered approach a la multi-factor authentication. If we don't take this seriously, how can we expect other people to take our keys seriously? Since the Incubator PMC consistently approves releases signed by keys which are not connected to the web of trust, apparently we don't take the web of trust very seriously right now. ;) But seriously... I interpret take this seriously to mean that before signing the key, it is important to... 1. Establish the identity of the key owner to a high degree of certainty. 2. Establish the link between the key and the key owner to a high degree of certainty. The point is that the degree of certainty is independent of the means used to obtain that certainty -- and the GnuPG
Re: key signing
A different angle. Noah asks me to sign his key. Noah tells me that he's committed it to KEYS for CloudStack in svn revision 314159. I examine that revision and see that it was made by, indeed, noah's Apache ID, which is associated with a particular email address. I send email to secretary@, asking Can you confirm that nsla...@apache.org corresponds to a CLA signed by a person named Noah Slater? The secretary says yes. I then feel that it's perfectly reasonable to sign a key that has two things in it: the name Noah Slater and nsla...@apache.org, because if this process doesn't verify an adequate association, then no one can trust the Apache IP process, either, and which has the same signature as the one in SVN. What am I missing here that would be improved by an in-person examination of his, oh, passport? A risk of some baroque MITM attack on Apache's svn server? It seems to me that this highlights a global issue with the WoT: how can I know the standards and level of care of every link in a chain of trust from me to some other person? None of this, of course, changes my concern that the average Apache user isn't connected, but if the argument is persuasive it should unleash a positive avalanche of key signing. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On 10 Oct 2012, at 11:25, Benson Margulies wrote: I then feel that it's perfectly reasonable to sign a key that has two things in it: the name Noah Slater and nsla...@apache.org, because if this process doesn't verify an adequate association, then no one can trust the Apache IP process, either, and which has the same signature as the one in SVN. The apache process is satisfied with his identity. The apache process says so by publishing the key under his name at apache.org, thus establishing a certain level of trust. That most certainly doesn't mean I should sign the key: for me to do so based on hearsay (my own trust not in his key but in the apache process) just muddies the waters. The missing link is my ability to formalise my WoT level of trust (whatever it might be) in the apache process by signing a key labelled something like ASF committer enrolment process which in turn automatically signs everyone's keys. Were it not for the risk of rather serious misunderstanding, I should advocate such a key. -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Wed, Oct 10, 2012 at 6:52 AM, Nick Kew n...@apache.org wrote: On 10 Oct 2012, at 11:25, Benson Margulies wrote: I then feel that it's perfectly reasonable to sign a key that has two things in it: the name Noah Slater and nsla...@apache.org, because if this process doesn't verify an adequate association, then no one can trust the Apache IP process, either, and which has the same signature as the one in SVN. The apache process is satisfied with his identity. The apache process says so by publishing the key under his name at apache.org, thus establishing a certain level of trust. That most certainly doesn't mean I should sign the key: for me to do so based on hearsay (my own trust not in his key but in the apache process) just muddies the waters. Nick: On the one hand, how is trusting the Apache process better or worse than trusting the State of Massachusetts? Both offer an assertion of a relationship between someone and a legal identity. In the state of MA case, I'm matching a face to a piece of (forgeable) plastic. In the Apache case, I'm matching an email to the Apache process. In both cases, I could be the subject of a fraud: someone I 'know' via mailing list interactions shows up in person, shows me a driver's license, and satisfies me that he or she is the same person I 'know' online. Enter the mole. If the answer to this is that WoT is supposed to be based on some level of 'real personal trust' (the opposite, after a fashion, of a 'Facebook Friend'), then I shouldn't sign keys at signing parties, since there's just about no one at Apache whom I know well enough to meet the standard. And I feel reinforced in my original urge to write web pages around here that put the Apache process above the WoT. Ironically, 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. The missing link is my ability to formalise my WoT level of trust (whatever it might be) in the apache process by signing a key labelled something like ASF committer enrolment process which in turn automatically signs everyone's keys. Were it not for the risk of rather serious misunderstanding, I should advocate such a key. -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Comments: - For many people, ensuring that the human who holds a specific key is the same one who has been using the j...@doe.foo email address and the john...@apache.org SVN/GIT account over a period of time is what is most important. Less important is ensuring that that human's legal name is John Doe. I.e. what is often viewed as more important is the tie between a person's consistent past actions and their key, rather than a tie between their key and the name they are legally known as in some jurisdiction. Especially on the internet, it's hard to know if someone else is a dog or not. But it is possible to see a consistent pattern of activity over time that is directly associated with an Apache ID and email addresses. - The ASF's tie of legal identity to a committer ID and the Commonwealth of Massachusetts' (or other legal entities) tie of identity to a drivers license are very different things, both in terms of difficulty to forge, consequences of fraud, and purpose for being. In most cases, forging country identity cards is a crime, and actually takes some work. Forging identity on the Apache iCLA is merely a matter of an email address and a signature. More importantly, country identity cards have multiple reasons for (attempting to be) secure and reliable. The iCLA is primarily about ensuring that an IP that iCLA's signer grants to us is actually license-able under the AL. While we certainly hope that our contributors will be well behaved, honest, and secure in their work here, what's fundamental for each iCLA signer is that the ASF has the rights to ship their contributions in our products. - The WoT doesn't scale to normal end users. Remember, the majority of them have never been on the dev@ list - they just want to run our software in their enterprise. I dunno what to do about that, but it would be useful if we could at least explain what the WoT and signing releases does show to our users. - Shane On 10/10/2012 7:20 AM, Benson Margulies wrote: On Wed, Oct 10, 2012 at 6:52 AM, Nick Kew n...@apache.org wrote: On 10 Oct 2012, at 11:25, Benson Margulies wrote: I then feel that it's perfectly reasonable to sign a key that has two things in it: the name Noah Slater and nsla...@apache.org, because if this process doesn't verify an adequate association, then no one can trust the Apache IP process, either, and which has the same signature as the one in SVN. The apache process is satisfied with his identity. The apache process says so by publishing the key under his name at apache.org, thus establishing a certain level of trust. That most certainly doesn't mean I should sign the key: for me to do so based on hearsay (my own trust not in his key but in the apache process) just muddies the waters. Nick: On the one hand, how is trusting the Apache process better or worse than trusting the State of Massachusetts? Both offer an assertion of a relationship between someone and a legal identity. In the state of MA case, I'm matching a face to a piece of (forgeable) plastic. In the Apache case, I'm matching an email to the Apache process. In both cases, I could be the subject of a fraud: someone I 'know' via mailing list interactions shows up in person, shows me a driver's license, and satisfies me that he or she is the same person I 'know' online. Enter the mole. If the answer to this is that WoT is supposed to be based on some level of 'real personal trust' (the opposite, after a fashion, of a 'Facebook Friend'), then I shouldn't sign keys at signing parties, since there's just about no one at Apache whom I know well enough to meet the standard. And I feel reinforced in my original urge to write web pages around here that put the Apache process above the WoT. Ironically, 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. The missing link is my ability to formalise my WoT level of trust (whatever it might be) in the apache process by signing a key labelled something like ASF committer enrolment process which in turn automatically signs everyone's keys. Were it not for the risk of rather serious misunderstanding, I should advocate such a key. -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing - trust path check
Anyone interested in details of PGP signing and tracing trust paths at the ASF should say thank you to long-time member henkp who has done a ton of work documenting and verifying release signing and keys: https://people.apache.org/~henkp/trust/ - Shane On 10/8/2012 6:37 PM, Noah Slater wrote: Found one... Just poking around manually... J. Daniel Kulp dk...@apache.org http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x858FC4C4F43856A3 Signed by Carsten Ziegeler cziege...@apache.org http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x132E49D4E41EDC7E Signed by Marcus Crafter craft...@debian.org http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x394D2FE3C4C57B42 And all Debian folk are connected, as per my pervious email. :) There should be a tool for this! On Mon, Oct 8, 2012 at 11:23 PM, Benson Margulies bimargul...@gmail.comwrote: Let's try a little statistically-invalid experiment of sample size one. The last time I had a key signed at Apache, it was by Dan Kulp. Now, pretend that you are a suspicious user of one of the many Maven plugins releases that I RM. Can you reach Dan from yourself in the web? Is there anyone you, personally, trust who starts a chain that leads to him? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Sent from my iPhone On Oct 10, 2012, at 2:47 AM, Noah Slater nsla...@tumbolia.org wrote: Can you clarify? I understand that being able to speak to someone face to face, and seeing their mannerisms and expressions, allows you to understand them better. Some deep rooted human thing. But how does this impact security or trust, in the context of key signing? I have friends who live far away. I know them well. I don't know their key fingerprint. If we send emails or if we text back and forth I not clear that it is them. If I have a video conference and the hold up the fingerprint I know it is them. On Wed, Oct 10, 2012 at 4:00 AM, Ted Dunning ted.dunn...@gmail.com wrote: If you know the person, it adds something that you don't get. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On 10 October 2012 15:20, Ted Dunning ted.dunn...@gmail.com wrote: Sent from my iPhone On Oct 10, 2012, at 2:47 AM, Noah Slater nsla...@tumbolia.org wrote: Can you clarify? I understand that being able to speak to someone face to face, and seeing their mannerisms and expressions, allows you to understand them better. Some deep rooted human thing. But how does this impact security or trust, in the context of key signing? I have friends who live far away. I know them well. I don't know their key fingerprint. If we send emails or if we text back and forth I not clear that it is them. If I have a video conference and the hold up the fingerprint I know it is them. or someone with a very good disguise... and you don't rule out the man in the mask behind the camera holding the gun pointed at them to get them to hold up the masked man's fingerprint and not their own. Though face-to-face doesn't remove the masked man threats... it does make them harder (relying on threats to family/friends, etc) ;-) On Wed, Oct 10, 2012 at 4:00 AM, Ted Dunning ted.dunn...@gmail.com wrote: If you know the person, it adds something that you don't get. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On 10 Oct 2012, at 12:20, Benson Margulies wrote: Nick: On the one hand, how is trusting the Apache process better or worse than trusting the State of Massachusetts? When I sign a key I'm basing it on more information than that. Either it's a one-off, when I have additional knowledge of someone: e.g. a personal or working relationship. Or it's a keysigning party, when I'm one of many. In the latter case, if I'm signing keys at ApacheCon and someone I've never met identifies himself as Benson Margulies, I have not only the passport but a room full of Apache folks - some of whom surely know Benson Margulies well - to reassure me. -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Hi Benson, A different angle. Noah asks me to sign his key. Noah tells me that he's committed it to KEYS for CloudStack in svn revision 314159. I examine that revision and see that it was made by, indeed, noah's Apache ID, which is associated with a particular email address. I send email to secretary@, asking Can you confirm that nsla...@apache.org corresponds to a CLA signed by a person named Noah Slater? The secretary says yes. I then feel that it's perfectly reasonable to sign a key that has two things in it: the name Noah Slater and nsla...@apache.org, In this scenario, you assume: * that Noah's account is solely under his own control * that your mail ping pong with secretary is secure * that the ASF did verify Noah's identity correctly * in general, that the whole infrastructure used in this process is secure (trust root, no MITM, the usual stuff) The PGP/GPG WoT is generally built upon assuring the identity of a real person (normally this person's name is the name used in the key, but this is a point often discussed), and upon doing this personally, i.e. not relying on the assumption that others have done it correctly! It's *you* who is signing the key, stating that *you* can certify that this key belongs to that person, and that the person is the one he/she claims to be. After all, other users on the WoT will rely on this information. Signing pseudonym keys is a special thing, see [1] for example. It is important to mention that using a pseudonym doesn't mean that identity verification can't take place - these are two different things. because if this process doesn't verify an adequate association, then no one can trust the Apache IP process, either, and which has the same signature as the one in SVN. I don't remember what exactly I had to do, but AFAIR not as much that the ASF would be able to sign my real-name-key based on this information. Sad but true. What am I missing here that would be improved by an in-person examination of his, oh, passport? A risk of some baroque MITM attack on Apache's svn server? It seems to me that this highlights a global issue with the WoT: how can I know the standards and level of care of every link in a chain of trust from me to some other person? None of this, of course, changes my concern that the average Apache user isn't connected, but if the argument is persuasive it should unleash a positive avalanche of key signing. Of course, the WoT concept results in some effort for every participant. It's a decentralized concept, and this is one of its disadvantages. However, what would now be totally wrong IMO is, that some guys in the ASF redefine these rules in order to make the process of release signing more simple. In the WoT big picture, this would automatically mean that every key that is signed based on these weak rules would have to be marked as marginally trusted (if at all) by people who want to really follow the PGP/GPG WoT concept. I think there are the following basic questions: a) Which basic concept should be used at all? Is it a decentralized Web of Trust, or should a hierarchical Apache CA be established for code signing purposes? b) Should it be possible to contribute to ASF projects using a pseudonym, including code signing? Assuming WoT for a), since there is probably no suiting manpower available for running a CA. Assuming Yes for b) and proposing that there should be rules for pseudonym keys making it possible to distinguish them from real name keys (for example Superman (PSEUDONYM CODE SIGNING KEY) super...@apache.org). Furthermore proposing the following rules: * signing keys MUST be included in the KEYS file in the svn repository * signing keys SHOULD be signed by other ASF members and/or other people in order to integrate the key into a WoT. However, signing MUST take place following commonly known rules when it comes to verifying identity (TODO: maybe it's best to really specify these rules in detail, like many people out there already do in the PGP/GPG sections of their personal web pages). It's up to the key signer whether he wants to sign pseudonym keys (TODO: Which rules do apply to verify identity in this case?). * It's ok for unsigned keys to be used. In this case, a person verifying an artifact's signature would be relying solely on the assumption that the Apache infrastructure isn't compromised. My 2 cents so far. Regards Florian [1] http://lists.gnupg.org/pipermail/gnupg-users/2004-May/022553.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Wed, Oct 10, 2012 at 7:19 AM, Nick Kew n...@webthing.com wrote: On 10 Oct 2012, at 12:20, Benson Margulies wrote: Nick: On the one hand, how is trusting the Apache process better or worse than trusting the State of Massachusetts? When I sign a key I'm basing it on more information than that. Exactly -- certainty increases linearly the as the strength of any one factor improves, but increases exponentially with the addition of multiple factors. Weak: amateur inspection of photo ID Stronger, but depends on trust in third parties: amateur inspection of photo ID + third party testimonials Stronger still: amateur inspection of photo ID + third party testimonials + permanent archived video (to discourage impersonation) + verification of Apache credentials Either it's a one-off, when I have additional knowledge of someone: e.g. a personal or working relationship. Or it's a keysigning party, when I'm one of many. In the latter case, if I'm signing keys at ApacheCon and someone I've never met identifies himself as Benson Margulies, I have not only the passport but a room full of Apache folks - some of whom surely know Benson Margulies well - to reassure me. Protocols for key signing parties can be quite elaborate to ensure that each participant provides multiple factors: http://cryptnet.net/fdp/crypto/keysigning_party/en/keysigning_party.html Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Wed, Oct 10, 2012 at 8:11 AM, Florian Holeczek flor...@holeczek.de wrote: However, what would now be totally wrong IMO is, that some guys in the ASF redefine these rules in order to make the process of release signing more simple. In the WoT big picture, this would automatically mean that every key that is signed based on these weak rules would have to be marked as marginally trusted (if at all) by people who want to really follow the PGP/GPG WoT concept. In my opinion, we have sufficient expertise here at the ASF to devise an authentication protocol whose reliability exceeds that of individuals participating unsupervised in a web of trust, particularly if the protocol were to incorporate archived video and auditing by a PMC. That said, persuading others that no corners are being cut may be a more daunting challenge. :P Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: key signing
+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:bimargul...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: key signing
Just for completeness for building an understanding what I have been capitalizing as the Apache Trust Chain: 1. There must also be understanding of the cert expiration and cert revocation cases. 2. As a demonstration for how it all comes down to the Apache logon for committers, consider the way that an SSH certificate is established for a people.apache.org account. The initial login is with the Apache Name/ID credentials and the password that goes with the account. Only then can the user upload an SSH certificate to the appropriate location for a certificate-based SSH login. I'm not suggesting that is a particular weakness (although folks provide a fair amount of trust to their peers on people.apache.org). The point is that it also stems from the foundation of the Apache Trust Chain. And so do the authz record entries, of course. -Original Message- From: Dennis E. Hamilton [mailto:orc...@apache.org] Sent: Wednesday, October 10, 2012 09:28 To: general@incubator.apache.org Subject: RE: key signing [ ... ] 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:bimargul...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Hi Marvin, On Wed, Oct 10, 2012 at 8:11 AM, Florian Holeczek flor...@holeczek.de wrote: However, what would now be totally wrong IMO is, that some guys in the ASF redefine these rules in order to make the process of release signing more simple. In the WoT big picture, this would automatically mean that every key that is signed based on these weak rules would have to be marked as marginally trusted (if at all) by people who want to really follow the PGP/GPG WoT concept. In my opinion, we have sufficient expertise here at the ASF to devise an authentication protocol whose reliability exceeds that of individuals participating unsupervised in a web of trust, particularly if the protocol were to incorporate archived video and auditing by a PMC. that may well be. Having read most of the mails on this thread, I was kind of shocked by how carelessly some would sign a key though, too, and that's what I meant by weak rules. Defining a good key signing protocol containing multiple factors, like you've mentioned in a different mail on this thread, would certainly help here, that's true. Regards Florian - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Wed, Oct 10, 2012 at 3:20 PM, Ted Dunning ted.dunn...@gmail.com wrote: I have friends who live far away. I know them well. I don't know their key fingerprint. If we send emails or if we text back and forth I not clear that it is them. If I have a video conference and the hold up the fingerprint I know it is them. This is not an applicable user story for Apache, though. We're not all long distance pen palls who used to know each other in real life. As Shane points out, the important thing is that we can establish email and key ownership. I still contend that actually being able to say the person who controls this email and this key happens to have some ID proving their IRL identity. Perhaps that is not important for Apache. But for the WoT in general, it certainly seems to be the case. -- NS
Re: key signing
I've said it already in this thread, but I will say it one last time before I drop it. Archiving video provides zero benefits, beyond the human to human connection of seeing what somebody looks like. It provides no way to establish identity or ownership of email/keys that email does not already provide. Or perhaps email with a photograph of me included? On Wed, Oct 10, 2012 at 5:04 PM, Marvin Humphrey mar...@rectangular.comwrote: On Wed, Oct 10, 2012 at 8:11 AM, Florian Holeczek flor...@holeczek.de wrote: However, what would now be totally wrong IMO is, that some guys in the ASF redefine these rules in order to make the process of release signing more simple. In the WoT big picture, this would automatically mean that every key that is signed based on these weak rules would have to be marked as marginally trusted (if at all) by people who want to really follow the PGP/GPG WoT concept. In my opinion, we have sufficient expertise here at the ASF to devise an authentication protocol whose reliability exceeds that of individuals participating unsupervised in a web of trust, particularly if the protocol were to incorporate archived video and auditing by a PMC. That said, persuading others that no corners are being cut may be a more daunting challenge. :P Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- NS
Re: key signing
Just to be clear, I don't think I've ever signed a key in my life. In part, because this criteria seem impossibly mushy. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Most people develop their own key signing policy and publish it. Or organisations as a whole do, and ask their members to adhere to it. Something which we might want to consider formalising. On Wed, Oct 10, 2012 at 10:18 PM, Benson Margulies bimargul...@gmail.comwrote: Just to be clear, I don't think I've ever signed a key in my life. In part, because this criteria seem impossibly mushy. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- NS
Re: key signing - trust path check
This is awesome! Unfortunately I (61D50B88) am not in the strong set. Bummer. :( On Wed, Oct 10, 2012 at 2:43 PM, Shane Curcuru a...@shanecurcuru.org wrote: Anyone interested in details of PGP signing and tracing trust paths at the ASF should say thank you to long-time member henkp who has done a ton of work documenting and verifying release signing and keys: https://people.apache.org/~**henkp/trust/https://people.apache.org/~henkp/trust/ - Shane On 10/8/2012 6:37 PM, Noah Slater wrote: Found one... Just poking around manually... J. Daniel Kulp dk...@apache.org http://pgp.mit.edu:11371/pks/**lookup?op=vindexsearch=** 0x858FC4C4F43856A3http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x858FC4C4F43856A3 Signed by Carsten Ziegeler cziege...@apache.org http://pgp.mit.edu:11371/pks/**lookup?op=vindexsearch=** 0x132E49D4E41EDC7Ehttp://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x132E49D4E41EDC7E Signed by Marcus Crafter craft...@debian.org http://pgp.mit.edu:11371/pks/**lookup?op=vindexsearch=** 0x394D2FE3C4C57B42http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x394D2FE3C4C57B42 And all Debian folk are connected, as per my pervious email. :) There should be a tool for this! On Mon, Oct 8, 2012 at 11:23 PM, Benson Margulies bimargul...@gmail.com wrote: Let's try a little statistically-invalid experiment of sample size one. The last time I had a key signed at Apache, it was by Dan Kulp. Now, pretend that you are a suspicious user of one of the many Maven plugins releases that I RM. Can you reach Dan from yourself in the web? Is there anyone you, personally, trust who starts a chain that leads to him? --**--** - To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.orggeneral-unsubscr...@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.**orggeneral-h...@incubator.apache.org --**--**- To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.orggeneral-unsubscr...@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.**orggeneral-h...@incubator.apache.org -- NS
Re: key signing
On 10 Oct 2012, at 17:04, Marvin Humphrey wrote: In my opinion, we have sufficient expertise here at the ASF to devise an authentication protocol whose reliability exceeds that of individuals participating unsupervised in a web of trust, particularly if the protocol were to incorporate archived video and auditing by a PMC. That may be, but I don't think general@incubator is the place to develop it. FWIW for myself I like to back WOT paths by checking manually, and feel best about it when I can identify a chain of trust involving only people I trust to be savvy enough not to sign keys willy-nilly. PGP/GPG support different levels of trust, so the model helps there. -- Nick Kew - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
I've read this entire thread (whew!), and would actually like to throw out a contrary position: No signed keys. Consider: releases come from the ASF, not a person. The RM builds the release artifacts and checks them into version control along with hash checksums. Other PMC members validate the artifacts for release criteria and matching checksums, voting +1 via version control. All of the above is done via authenticated ASF accounts. The above establishes an ASF release. Please explain how keys are needed for this ASF release? Consumers are already told to verify the SHA1 and nothing more. I doubt any more is needed. (assume secure Infrastructure) Cheers, -g On Oct 5, 2012 5:04 AM, Benson Margulies bimargul...@gmail.com wrote: I'm offering this discussion here, but it might need to go elsewhere if it goes anywhere at all. It seems to me that the there is a gap in the incubation process, and I don't know how to fill it. As far as I can see, we don't do anything to facilitate or encourage getting PGP keys signed. We tell people to create a key and put it in the SVN 'keys' file. Key signing strikes me as a bit of a conundrum for us. In all other respects, we emphasize that anyone, anywhere, in any time zone, can be a full member of a community. However, key signing requires something else. [1] Generally, it requires a face-to-face interaction. It is perhaps interesting to note that the foundation accepts CLAs as legally binding without any face-to-face identity verification. If you send in a CLA with a signature, we believe it, and we believe that the email address you provide is, in fact, controlled by the legal person who signed the form. I wonder, then, if secretary@ should be willing to sign a key. Alternatively, since the chain is CLA - svn access - unsigned key in svn, perhaps all we really need is to document that a signature corresponding to a key in svn is really good enough, and users need not be concerned further. [1]: http://httpd.apache.org/dev/verification.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Oct 11, 2012, at 10:44 AM, Greg Stein gst...@gmail.com wrote: (assume secure Infrastructure) That's a pretty big assumption isn't it? There have been public instances where open source infrastructures have been hacked, and releases have been messed with. I think keys removes the need for the assumption. -- Ian Holsman i...@holsman.com.au http://doitwithdata.com.au PH: +61-400-988-964 Skype:iholsman - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Ian Holsman wrote on Thu, Oct 11, 2012 at 10:53:11 +1100: On Oct 11, 2012, at 10:44 AM, Greg Stein gst...@gmail.com wrote: (assume secure Infrastructure) That's a pretty big assumption isn't it? There have been public instances where open source infrastructures have been hacked, and releases have been messed with. I think keys removes the need for the assumption. Signatures also allow verifying whoever signed this tarball is the same person who signed the previous tarball. Hash functions don't do that. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Greg Stein wrote on Wed, Oct 10, 2012 at 19:44:30 -0400: I've read this entire thread (whew!), and would actually like to throw out a contrary position: No signed keys. Consider: releases come from the ASF, not a person. Therefore, releases should be signed by the ASF as an organisation, not by individual persons. Right? The RM builds the release artifacts and checks them into version control along with hash checksums. Other PMC members validate the artifacts for release criteria and matching checksums, voting +1 via version control. All of the above is done via authenticated ASF accounts. The above establishes an ASF release. Please explain how keys are needed for this ASF release? Consumers are already told to verify the SHA1 and nothing more. I doubt any more is needed. (assume secure Infrastructure) Cheers, -g Daniel (infra hat off, devil's advocate hat on) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Wed, Oct 10, 2012 at 9:10 PM, Daniel Shahaf d...@daniel.shahaf.name wrote: Greg Stein wrote on Wed, Oct 10, 2012 at 19:44:30 -0400: I've read this entire thread (whew!), and would actually like to throw out a contrary position: No signed keys. Consider: releases come from the ASF, not a person. Therefore, releases should be signed by the ASF as an organisation, not by individual persons. Right? I would be completely supportive of an Infra-managed private key for signing releases. My point is that our instructions to users don't really incorporoate the notions of keys, and (thus) provide near-zero utility. For such a long thread, for such little gain... my thought was toss the concept. throw out the keys. ... Daniel (infra hat off, devil's advocate hat on) hehe. And my devil's advocate is: keys provide no additional benefit for end users. demonstrate otherwise. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: key signing
There is value of the external signature for attesting something about the creation of the artifact. The digest simply demonstrates that the artifact is intact. I've already agreed that the signing of other people's certificate is not that valuable in the case of Apache releases. Because of the security of Apache credentials, confirming a certificate is easy: Import the certificate located on the Apache site into your favorite key (certificate) store. Send an encrypted message to the corresponding name@ apache.org. Have the recipient send the decrypted message back to you encrypted with your public key (also identified in the message, etc.) If the recipient doesn't receive it or can't return the decrypted message, don't trust the public key cert. You can probably indicate the key is trusted by you, locally, if the exercise succeeds. You don't have to do a WoT signing though. This is a pretty standard ceremony for an e-mail non-persona. - Dennis -Original Message- From: Greg Stein [mailto:gst...@gmail.com] Sent: Wednesday, October 10, 2012 16:45 To: general@incubator.apache.org Subject: Re: key signing I've read this entire thread (whew!), and would actually like to throw out a contrary position: No signed keys. Consider: releases come from the ASF, not a person. The RM builds the release artifacts and checks them into version control along with hash checksums. Other PMC members validate the artifacts for release criteria and matching checksums, voting +1 via version control. All of the above is done via authenticated ASF accounts. The above establishes an ASF release. Please explain how keys are needed for this ASF release? Consumers are already told to verify the SHA1 and nothing more. I doubt any more is needed. (assume secure Infrastructure) Cheers, -g [ ... ] - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Wed, Oct 10, 2012 at 7:53 PM, Ian Holsman i...@holsman.com.au wrote: On Oct 11, 2012, at 10:44 AM, Greg Stein gst...@gmail.com wrote: (assume secure Infrastructure) That's a pretty big assumption isn't it? Empirically, we've had break-ins, so we can assume it will happen again. But now you're talking that somebody has to change the svn/dist system to install new tarballs and new checksums. Without being noticed once control is regained. There have been public instances where open source infrastructures have been hacked, and releases have been messed with. I think keys removes the need for the assumption. Not too much. We still instruct users take the signatures and verify them against blah.apache.org/KEYS. John Blackhat could replace the signatures and install his entry into KEYS. I still see no need for key-based signing here :-) Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Greg Stein wrote on Wed, Oct 10, 2012 at 21:14:15 -0400: On Wed, Oct 10, 2012 at 9:10 PM, Daniel Shahaf d...@daniel.shahaf.name wrote: Greg Stein wrote on Wed, Oct 10, 2012 at 19:44:30 -0400: I've read this entire thread (whew!), and would actually like to throw out a contrary position: No signed keys. Consider: releases come from the ASF, not a person. Therefore, releases should be signed by the ASF as an organisation, not by individual persons. Right? I would be completely supportive of an Infra-managed private key for signing releases. My point is that our instructions to users don't really incorporoate the notions of keys, and (thus) provide near-zero utility. For such So, provide better instructions? a long thread, for such little gain... my thought was toss the concept. throw out the keys. ... Daniel (infra hat off, devil's advocate hat on) hehe. And my devil's advocate is: keys provide no additional benefit for end users. demonstrate otherwise. One benefit I named in my next-to-last message: upon a new release, users who downloaded the previous release and its signature can verify that the new release was signed by the same entity that signed the previous release. This binds releases to each another. Shane hinted at another: a person who signs a release using the same key he uses for day-to-day dev@ work links the release not to his legal identity but to his dev@ identity. This binds releases to people doing dev work. SHA-1 checksums don't provide any binding whatsoever, other than whoever generated the checksum was looking at the same file I am looking at. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Greg Stein wrote on Wed, Oct 10, 2012 at 21:31:30 -0400: Not too much. We still instruct users take the signatures and verify them against blah.apache.org/KEYS. John Blackhat could replace the signatures and install his entry into KEYS. If you use https://people.apache.org/keys/ instead of KEYS files in the dist/ tree, John would have to crack two machines rather than one. /plug :-P - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Wed, Oct 10, 2012 at 9:35 PM, Daniel Shahaf d...@daniel.shahaf.name wrote: Greg Stein wrote on Wed, Oct 10, 2012 at 21:14:15 -0400: ... My point is that our instructions to users don't really incorporoate the notions of keys, and (thus) provide near-zero utility. For such So, provide better instructions? That's the implication that I'm getting at... rip out all the key stuff, and just talk about the SHA1 checksums. ... One benefit I named in my next-to-last message: upon a new release, users who downloaded the previous release and its signature can verify that the new release was signed by the same entity that signed the previous release. This binds releases to each another. Shane hinted at another: a person who signs a release using the same key he uses for day-to-day dev@ work links the release not to his legal identity but to his dev@ identity. This binds releases to people doing dev work. SHA-1 checksums don't provide any binding whatsoever, other than whoever generated the checksum was looking at the same file I am looking at. I understand there is no binding. I'm only considering a binding against the ASF. It is residing on our infrastructure, its checksum matches, therefore it must be authentic. Does the extra glue really matter? Do we really need to figure out key signing parties? What are we truly getting out of this? I look at the glue of the committer's identifier. I'm posting to dev@ as gstein, and then I commit the tarball artifact as gstein. Binding is now complete. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Greg Stein wrote on Wed, Oct 10, 2012 at 21:40:18 -0400: On Wed, Oct 10, 2012 at 9:35 PM, Daniel Shahaf d...@daniel.shahaf.name wrote: Greg Stein wrote on Wed, Oct 10, 2012 at 21:14:15 -0400: ... My point is that our instructions to users don't really incorporoate the notions of keys, and (thus) provide near-zero utility. For such So, provide better instructions? That's the implication that I'm getting at... rip out all the key stuff, and just talk about the SHA1 checksums. Actually I meant instructions on verifying digital signatures. :-P - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Mon, Oct 8, 2012 at 2:24 PM, Noah Slater nsla...@tumbolia.org wrote: 1. The key owner convinces the signer that the identity in the UID is indeed their own identity by whatever evidence the signer is willing to accept as convincing. Usually this means the key owner must present a government issued ID with a picture and information that match up with the key owner. (Some signers know that government issued ID's are easily forged and that the trustability of the issuing authorities is often suspect and so they may require additional and/or alternative evidence of identity). 2. The key owner verifies that the fingerprint and the length of the key about to be signed is indeed their own. How would you do this via Skype? Here's a rough draft for a protocol: Several podling committers convene in a Google Plus Hangout with Hangouts On Air enabled (so that the video gets archived to YouTube). Everyone states their name and what they had for lunch, then reads their public key fingerprint aloud. The lunch items are combined into a key phrase. Participants then commit to a text file under ASF version control, contributing a few lines containing their name, their public key fingerprint and the key phrase -- linking together face and voice, public key fingerprint, ASF credentials and by extension, an iCLA. Optionally, the project is then discussed by the participants for some arbitrary length of time; the discussion of shared experience adds another layer of confidence that participants are who they say they are. Physical IDs are *not* shown during this session because the video is to be archived in a public location, but participants are encouraged to request such ids via private channels later. After the session ends, the archival video link is submitted to the podling's dev list, giving people the opportunity to initiate contact via email, phone or other channels with the committers in question -- or better yet their associates and colleagues, pointing to the video link and requesting confirmation of identity. Once a potential key-signer believes that a high degree of certainty has been established for a given candidate (it may make sense to codify some best practice guidelines), they sign the key and report to the dev list, documenting both what key was signed and what criteria they used when deciding to sign. ... While this protocol does not rely heavily on validating government-issued IDs, the Debian guidelines quoted above point out that some people object to giving such IDs too much creedence: (Some signers know that government issued ID's are easily forged and that the trustability of the issuing authorities is often suspect and so they may require additional and/or alternative evidence of identity). Instead, it relies on a layered approach a la multi-factor authentication. If we don't take this seriously, how can we expect other people to take our keys seriously? Since the Incubator PMC consistently approves releases signed by keys which are not connected to the web of trust, apparently we don't take the web of trust very seriously right now. ;) But seriously... I interpret take this seriously to mean that before signing the key, it is important to... 1. Establish the identity of the key owner to a high degree of certainty. 2. Establish the link between the key and the key owner to a high degree of certainty. The point is that the degree of certainty is independent of the means used to obtain that certainty -- and the GnuPG docs say as much. Face-to-face interaction is one good technique, but in my opiniion, the categorical dismissal of all other techniques hinders participation in the web of trust, thereby thinning our defense in depth against credential spoofing. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
What, precisely, does a video call actually provide? The point of meeting in person is to verify photo IDs. Just talking to somebody with a face doesn't prove anybody. I am fairly certain that YOU have a face, and I have never even seen it. If all you're doing is having a chit chat and swapping key IDs, you may as well do that via IRC or email. Doing it with a video adds nothing, as far as I can see. It certainly does not establish identity. Beyond a person who says their name is Bob has a face which looks like [this]. Is that useful? I don't think so. On Tue, Oct 9, 2012 at 11:01 PM, Marvin Humphrey mar...@rectangular.comwrote: On Mon, Oct 8, 2012 at 2:24 PM, Noah Slater nsla...@tumbolia.org wrote: 1. The key owner convinces the signer that the identity in the UID is indeed their own identity by whatever evidence the signer is willing to accept as convincing. Usually this means the key owner must present a government issued ID with a picture and information that match up with the key owner. (Some signers know that government issued ID's are easily forged and that the trustability of the issuing authorities is often suspect and so they may require additional and/or alternative evidence of identity). 2. The key owner verifies that the fingerprint and the length of the key about to be signed is indeed their own. How would you do this via Skype? Here's a rough draft for a protocol: Several podling committers convene in a Google Plus Hangout with Hangouts On Air enabled (so that the video gets archived to YouTube). Everyone states their name and what they had for lunch, then reads their public key fingerprint aloud. The lunch items are combined into a key phrase. Participants then commit to a text file under ASF version control, contributing a few lines containing their name, their public key fingerprint and the key phrase -- linking together face and voice, public key fingerprint, ASF credentials and by extension, an iCLA. Optionally, the project is then discussed by the participants for some arbitrary length of time; the discussion of shared experience adds another layer of confidence that participants are who they say they are. Physical IDs are *not* shown during this session because the video is to be archived in a public location, but participants are encouraged to request such ids via private channels later. After the session ends, the archival video link is submitted to the podling's dev list, giving people the opportunity to initiate contact via email, phone or other channels with the committers in question -- or better yet their associates and colleagues, pointing to the video link and requesting confirmation of identity. Once a potential key-signer believes that a high degree of certainty has been established for a given candidate (it may make sense to codify some best practice guidelines), they sign the key and report to the dev list, documenting both what key was signed and what criteria they used when deciding to sign. ... While this protocol does not rely heavily on validating government-issued IDs, the Debian guidelines quoted above point out that some people object to giving such IDs too much creedence: (Some signers know that government issued ID's are easily forged and that the trustability of the issuing authorities is often suspect and so they may require additional and/or alternative evidence of identity). Instead, it relies on a layered approach a la multi-factor authentication. If we don't take this seriously, how can we expect other people to take our keys seriously? Since the Incubator PMC consistently approves releases signed by keys which are not connected to the web of trust, apparently we don't take the web of trust very seriously right now. ;) But seriously... I interpret take this seriously to mean that before signing the key, it is important to... 1. Establish the identity of the key owner to a high degree of certainty. 2. Establish the link between the key and the key owner to a high degree of certainty. The point is that the degree of certainty is independent of the means used to obtain that certainty -- and the GnuPG docs say as much. Face-to-face interaction is one good technique, but in my opiniion, the categorical dismissal of all other techniques hinders participation in the web of trust, thereby thinning our defense in depth against credential spoofing. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- NS
Re: key signing
If you know the person, it adds something that you don't get. On Tue, Oct 9, 2012 at 3:40 PM, Noah Slater nsla...@tumbolia.org wrote: What, precisely, does a video call actually provide? The point of meeting in person is to verify photo IDs. Just talking to somebody with a face doesn't prove anybody. I am fairly certain that YOU have a face, and I have never even seen it. If all you're doing is having a chit chat and swapping key IDs, you may as well do that via IRC or email. Doing it with a video adds nothing, as far as I can see. It certainly does not establish identity. Beyond a person who says their name is Bob has a face which looks like [this]. Is that useful? I don't think so. On Tue, Oct 9, 2012 at 11:01 PM, Marvin Humphrey mar...@rectangular.com wrote: On Mon, Oct 8, 2012 at 2:24 PM, Noah Slater nsla...@tumbolia.org wrote: 1. The key owner convinces the signer that the identity in the UID is indeed their own identity by whatever evidence the signer is willing to accept as convincing. Usually this means the key owner must present a government issued ID with a picture and information that match up with the key owner. (Some signers know that government issued ID's are easily forged and that the trustability of the issuing authorities is often suspect and so they may require additional and/or alternative evidence of identity). 2. The key owner verifies that the fingerprint and the length of the key about to be signed is indeed their own. How would you do this via Skype? Here's a rough draft for a protocol: Several podling committers convene in a Google Plus Hangout with Hangouts On Air enabled (so that the video gets archived to YouTube). Everyone states their name and what they had for lunch, then reads their public key fingerprint aloud. The lunch items are combined into a key phrase. Participants then commit to a text file under ASF version control, contributing a few lines containing their name, their public key fingerprint and the key phrase -- linking together face and voice, public key fingerprint, ASF credentials and by extension, an iCLA. Optionally, the project is then discussed by the participants for some arbitrary length of time; the discussion of shared experience adds another layer of confidence that participants are who they say they are. Physical IDs are *not* shown during this session because the video is to be archived in a public location, but participants are encouraged to request such ids via private channels later. After the session ends, the archival video link is submitted to the podling's dev list, giving people the opportunity to initiate contact via email, phone or other channels with the committers in question -- or better yet their associates and colleagues, pointing to the video link and requesting confirmation of identity. Once a potential key-signer believes that a high degree of certainty has been established for a given candidate (it may make sense to codify some best practice guidelines), they sign the key and report to the dev list, documenting both what key was signed and what criteria they used when deciding to sign. ... While this protocol does not rely heavily on validating government-issued IDs, the Debian guidelines quoted above point out that some people object to giving such IDs too much creedence: (Some signers know that government issued ID's are easily forged and that the trustability of the issuing authorities is often suspect and so they may require additional and/or alternative evidence of identity). Instead, it relies on a layered approach a la multi-factor authentication. If we don't take this seriously, how can we expect other people to take our keys seriously? Since the Incubator PMC consistently approves releases signed by keys which are not connected to the web of trust, apparently we don't take the web of trust very seriously right now. ;) But seriously... I interpret take this seriously to mean that before signing the key, it is important to... 1. Establish the identity of the key owner to a high degree of certainty. 2. Establish the link between the key and the key owner to a high degree of certainty. The point is that the degree of certainty is independent of the means used to obtain that certainty -- and the GnuPG docs say as much. Face-to-face interaction is one good technique, but in my opiniion, the categorical dismissal of all other techniques hinders participation in the web of trust, thereby thinning our defense in depth against credential spoofing. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: key signing
-Original Message- From: Marvin Humphrey [mailto:mar...@rectangular.com] Sent: Friday, October 05, 2012 8:54 PM To: general@incubator.apache.org Subject: Re: key signing On Fri, Oct 5, 2012 at 8:55 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: It's good to recommend people to get their keys signed by someone in the Apache web of trust and I think we could do more in that area, Maybe if we didn't insist on face-to-face meetings we'd get better adoption rates. Apache dev docs: http://www.apache.org/dev/openpgp.html#wot-link-in How To Link Into A Public Web Of Trust In short, expect that: * this will involve a face-to-face meeting GnuPG docs: http://www.gnupg.org/gph/en/manual.html#AEN84 A key's fingerprint is verified with the key's owner. This may be done in person or over the phone or through any other means as long as you can guarantee that you are communicating with the key's true owner. +1. I think with technologies like Skype Google Hangout, we can get the same level of assurance of a person's identity as a physical key signing party. What if we held a regular Google Hangout Key Signing party? We can always ask participants to show IDs :) Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On 08.10.2012 13:44, Franklin, Matthew B. wrote: -Original Message- From: Marvin Humphrey [mailto:mar...@rectangular.com] Sent: Friday, October 05, 2012 8:54 PM To: general@incubator.apache.org Subject: Re: key signing On Fri, Oct 5, 2012 at 8:55 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: It's good to recommend people to get their keys signed by someone in the Apache web of trust and I think we could do more in that area, Maybe if we didn't insist on face-to-face meetings we'd get better adoption rates. Apache dev docs: http://www.apache.org/dev/openpgp.html#wot-link-in How To Link Into A Public Web Of Trust In short, expect that: * this will involve a face-to-face meeting GnuPG docs: http://www.gnupg.org/gph/en/manual.html#AEN84 A key's fingerprint is verified with the key's owner. This may be done in person or over the phone or through any other means as long as you can guarantee that you are communicating with the key's true owner. +1. I think with technologies like Skype Google Hangout, we can get the same level of assurance of a person's identity as a physical key signing party. What guarantee do you have that a particular Skype ID is whoever you think it is? None at all, unless the person involved looked at your Skype contact list and said, yeah, that's me. Likewise for Google Hangout. As long as they're doing that, they might as well verify the signature fingerprint in your PGP keyring. In this respect e-mail is just as secure, so why don't we all just sign keys because someone claiming to be from from Chad sent us a mail asking us for a signature? Really. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Mon, Oct 8, 2012 at 7:36 AM, Branko Čibej br...@apache.org wrote: What guarantee do you have that a particular Skype ID is whoever you think it is? None at all, unless the person involved looked at your Skype contact list and said, yeah, that's me. Likewise for Google Hangout. As long as they're doing that, they might as well verify the signature fingerprint in your PGP keyring. In this respect e-mail is just as secure, so why don't we all just sign keys because someone claiming to be from from Chad sent us a mail asking us for a signature? Really. Is it your position that this excerpt from the GnuPG docs is wrong? This may be done in person or over the phone or through any other means as long as you can guarantee that you are communicating with the key's true owner. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On 08.10.2012 17:43, Marvin Humphrey wrote: On Mon, Oct 8, 2012 at 7:36 AM, Branko Čibej br...@apache.org wrote: What guarantee do you have that a particular Skype ID is whoever you think it is? None at all, unless the person involved looked at your Skype contact list and said, yeah, that's me. Likewise for Google Hangout. As long as they're doing that, they might as well verify the signature fingerprint in your PGP keyring. In this respect e-mail is just as secure, so why don't we all just sign keys because someone claiming to be from from Chad sent us a mail asking us for a signature? Really. Is it your position that this excerpt from the GnuPG docs is wrong? This may be done in person or over the phone or through any other means as long as you can guarantee that you are communicating with the key's true owner. It says clearly, as long as you can guarantee that you are communicating with the key's true owner. Which was exactly my point. -- Brane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Mon, Oct 8, 2012 at 11:43 AM, Marvin Humphrey mar...@rectangular.com wrote: On Mon, Oct 8, 2012 at 7:36 AM, Branko Čibej br...@apache.org wrote: What guarantee do you have that a particular Skype ID is whoever you think it is? None at all, unless the person involved looked at your Skype contact list and said, yeah, that's me. Likewise for Google Hangout. As long as they're doing that, they might as well verify the signature fingerprint in your PGP keyring. In this respect e-mail is just as secure, so why don't we all just sign keys because someone claiming to be from from Chad sent us a mail asking us for a signature? Really. Is it your position that this excerpt from the GnuPG docs is wrong? This may be done in person or over the phone or through any other means as long as you can guarantee that you are communicating with the key's true owner. There's another side to this, which I would derisively label, 'so what'? How does it help a user to see that my key is signed by 27 of my fellow Apache contributors, if the user has never met any of us, and has never met anyone who has met any of us, etc, etc. In other words, the Web of Trust only helps users (very much) if they are active participants, and likely to have trust links that reach ASF release managers. In my opinion, that's vanishingly unlikely, and so the best we can do is to allow users to verify that the signature was, in fact, made by the 'Apache hat' that it claimed to be made by. Using the keys in KEYS, or the fingerprints from LDAP, seems the best they can do. Marvin Humphr - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: key signing
I don't understand what keys from LDAP are? Are these the same as keys whose fingerprints a ASF committer registers in their account or something else? - Dennis -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Monday, October 08, 2012 08:54 To: general@incubator.apache.org Subject: Re: key signing [ ... ] In my opinion, that's vanishingly unlikely, and so the best we can do is to allow users to verify that the signature was, in fact, made by the 'Apache hat' that it claimed to be made by. Using the keys in KEYS, or the fingerprints from LDAP, seems the best they can do. [ ... ] - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Mon, Oct 8, 2012 at 12:47 PM, Dennis E. Hamilton orc...@apache.org wrote: I don't understand what keys from LDAP are? Are these the same as keys whose fingerprints a ASF committer registers in their account or something else? Yes. Sorry for the foggy phraseology. - Dennis -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Monday, October 08, 2012 08:54 To: general@incubator.apache.org Subject: Re: key signing [ ... ] In my opinion, that's vanishingly unlikely, and so the best we can do is to allow users to verify that the signature was, in fact, made by the 'Apache hat' that it claimed to be made by. Using the keys in KEYS, or the fingerprints from LDAP, seems the best they can do. [ ... ] - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Mon, Oct 8, 2012 at 4:53 PM, Benson Margulies bimargul...@gmail.comwrote: On Mon, Oct 8, 2012 at 11:43 AM, Marvin Humphrey mar...@rectangular.com wrote: ... In this respect e-mail is just as secure, so why don't we all just sign keys because someone claiming to be from from Chad sent us a mail asking us for a signature? Really. Is it your position that this excerpt from the GnuPG docs is wrong? This may be done in person or over the phone or through any other means as long as you can guarantee that you are communicating with the key's true owner. There's another side to this, which I would derisively label, 'so what'? How does it help a user to see that my key is signed by 27 of my fellow Apache contributors, if the user has never met any of us, and has never met anyone who has met any of us, etc, etc. In other words, the Web of Trust only helps users (very much) if they are active participants, and likely to have trust links that reach ASF release managers. In my opinion, that's vanishingly unlikely, and so the best we can do is to allow users to verify that the signature was, in fact, made by the 'Apache hat' that it claimed to be made by. Using the keys in KEYS, or the fingerprints from LDAP, seems the best they can do. Folks who care about the Gnu web of trust will probably be hooked back into the Linux committers network. There are definitely connections from their to the Apache community. Thus, if the Apache community becomes completely connected from a trust perspective, it is likely that there will be a short path back to anybody connected into the Linux community. I could be just such a link. I had my (non-Apache) key signed at Buzzwords last year and if I were to use that key for Apache work, we would have the requisite link.
Re: key signing
On Mon, Oct 8, 2012 at 8:51 AM, Branko Čibej br...@apache.org wrote: It says clearly, as long as you can guarantee that you are communicating with the key's true owner. Which was exactly my point. I assert a virtual key-signing party protocol incorportating Google Plus Hangouts could offer comparable assurances to a face-to-face key signing party. I speculate that such a protocol would utilize the Hangouts On Air[1] feature which archives the hangout video directly to YouTube, along with possibly mailing list interaction and commits to ASF version control to achieve a layered approach a la multi-factor authentication. Arguably, having archived video would make the virtual protocol _stronger_ than face-to-face. Whether such an initiative would be worth the effort is a different question, but video conferencing should not be dismissed out-of-hand as a tool for helping to associate a key with the key's true owner. [1] http://www.google.com/+/learnmore/hangouts/onair.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Mon, Oct 8, 2012 at 7:46 PM, Marvin Humphrey mar...@rectangular.comwrote: On Mon, Oct 8, 2012 at 8:51 AM, Branko Čibej br...@apache.org wrote: It says clearly, as long as you can guarantee that you are communicating with the key's true owner. Which was exactly my point. I assert a virtual key-signing party protocol incorportating Google Plus Hangouts could offer comparable assurances to a face-to-face key signing party. I speculate that such a protocol would utilize the Hangouts On Air[1] feature which archives the hangout video directly to YouTube, along with possibly mailing list interaction and commits to ASF version control to achieve a layered approach a la multi-factor authentication. Arguably, having archived video would make the virtual protocol _stronger_ than face-to-face. Whether such an initiative would be worth the effort is a different question, but video conferencing should not be dismissed out-of-hand as a tool for helping to associate a key with the key's true owner. [1] http://www.google.com/+/learnmore/hangouts/onair.html I think that Branko may have been thinking text messages when the word skype came up. Video conferencing is at least as good as voice and, as you say, with archiving can be pretty powerful. To my mind, though, there is definitely something nice about having somebody's passport in your hand and pretending you know what to look for to spot a fake.
Re: key signing
On Mon, Oct 8, 2012 at 4:53 PM, Benson Margulies bimargul...@gmail.comwrote: There's another side to this, which I would derisively label, 'so what'? How does it help a user to see that my key is signed by 27 of my fellow Apache contributors, if the user has never met any of us, and has never met anyone who has met any of us, etc, etc. In other words, the Web of Trust only helps users (very much) if they are active participants, and likely to have trust links that reach ASF release managers. In my opinion, that's vanishingly unlikely, and so the best we can do is to allow users to verify that the signature was, in fact, made by the 'Apache hat' that it claimed to be made by. Using the keys in KEYS, or the fingerprints from LDAP, seems the best they can do. To me, this seems like an outright dismissal of the web of trust because it is unlikely. Which it is sure to be if everyone dismisses it. You're right in so much as not a lot of people care. But for the people that do care, it is very important, and works just great. (Note, I am not one of those people, though I am in the web of trust having been involved in Debian, which takes it very seriously.) If you are the sort of person who has a GPG key and get's it signed, then the chances are that you can establish trust with an RM that does the same. -- NS
Re: key signing
This is an important point. Debian has a complete toolset and guidelines for managing this. http://www.debian.org/events/keysigning To quote: People should only sign a key under at least two conditions: 1. The key owner convinces the signer that the identity in the UID is indeed their own identity by whatever evidence the signer is willing to accept as convincing. Usually this means the key owner must present a government issued ID with a picture and information that match up with the key owner. (Some signers know that government issued ID's are easily forged and that the trustability of the issuing authorities is often suspect and so they may require additional and/or alternative evidence of identity). 2. The key owner verifies that the fingerprint and the length of the key about to be signed is indeed their own. How would you do this via Skype? If we don't take this seriously, how can we expect other people to take our keys seriously? (Debian also has a few tools to help automate this stuff. See above link.) If we're going to adopt a key signing model, we should strongly consider basing it on Debian's. On Mon, Oct 8, 2012 at 9:45 PM, Ted Dunning ted.dunn...@gmail.com wrote: On Mon, Oct 8, 2012 at 7:46 PM, Marvin Humphrey mar...@rectangular.com wrote: On Mon, Oct 8, 2012 at 8:51 AM, Branko Čibej br...@apache.org wrote: It says clearly, as long as you can guarantee that you are communicating with the key's true owner. Which was exactly my point. I assert a virtual key-signing party protocol incorportating Google Plus Hangouts could offer comparable assurances to a face-to-face key signing party. I speculate that such a protocol would utilize the Hangouts On Air[1] feature which archives the hangout video directly to YouTube, along with possibly mailing list interaction and commits to ASF version control to achieve a layered approach a la multi-factor authentication. Arguably, having archived video would make the virtual protocol _stronger_ than face-to-face. Whether such an initiative would be worth the effort is a different question, but video conferencing should not be dismissed out-of-hand as a tool for helping to associate a key with the key's true owner. [1] http://www.google.com/+/learnmore/hangouts/onair.html I think that Branko may have been thinking text messages when the word skype came up. Video conferencing is at least as good as voice and, as you say, with archiving can be pretty powerful. To my mind, though, there is definitely something nice about having somebody's passport in your hand and pretending you know what to look for to spot a fake. -- NS
Re: key signing
On Mon, Oct 8, 2012 at 5:18 PM, Noah Slater nsla...@tumbolia.org wrote: On Mon, Oct 8, 2012 at 4:53 PM, Benson Margulies bimargul...@gmail.comwrote: There's another side to this, which I would derisively label, 'so what'? How does it help a user to see that my key is signed by 27 of my fellow Apache contributors, if the user has never met any of us, and has never met anyone who has met any of us, etc, etc. In other words, the Web of Trust only helps users (very much) if they are active participants, and likely to have trust links that reach ASF release managers. In my opinion, that's vanishingly unlikely, and so the best we can do is to allow users to verify that the signature was, in fact, made by the 'Apache hat' that it claimed to be made by. Using the keys in KEYS, or the fingerprints from LDAP, seems the best they can do. To me, this seems like an outright dismissal of the web of trust because it is unlikely. Which it is sure to be if everyone dismisses it. You're right in so much as not a lot of people care. But for the people that do care, it is very important, and works just great. (Note, I am not one of those people, though I am in the web of trust having been involved in Debian, which takes it very seriously.) If you are the sort of person who has a GPG key and get's it signed, then the chances are that you can establish trust with an RM that does the same. I've been watching PGP from its birth, and I've seen very little evidence of the web of trust growing from geeks like us to the sort of people who download and install Tomcat. If you can offer some counterevidence, I'm all eyes. My personal enthusiasm is for all Apache projects to share a clear recipe for their users to verify downloads. That recipe should work for *every user* and *every release manager*. -- NS - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Perhaps not Tomcat, but the entire Foundation and all of it's current and future projects should be under consideration here. The long and short of it is that key signing can't hurt. And a key signing guide certainly can't hurt. RMs should feel free to do this, if they are interested in it, and users who care about it can take advantage of it, if it interests them. I certainly wouldn't want to think that we mandate anything. (You know you can't be a Debian developer until you have your key signed by another Debian developer? That set me back months. I'm something of a recluse!) On Mon, Oct 8, 2012 at 10:37 PM, Benson Margulies bimargul...@gmail.comwrote: On Mon, Oct 8, 2012 at 5:18 PM, Noah Slater nsla...@tumbolia.org wrote: On Mon, Oct 8, 2012 at 4:53 PM, Benson Margulies bimargul...@gmail.com wrote: There's another side to this, which I would derisively label, 'so what'? How does it help a user to see that my key is signed by 27 of my fellow Apache contributors, if the user has never met any of us, and has never met anyone who has met any of us, etc, etc. In other words, the Web of Trust only helps users (very much) if they are active participants, and likely to have trust links that reach ASF release managers. In my opinion, that's vanishingly unlikely, and so the best we can do is to allow users to verify that the signature was, in fact, made by the 'Apache hat' that it claimed to be made by. Using the keys in KEYS, or the fingerprints from LDAP, seems the best they can do. To me, this seems like an outright dismissal of the web of trust because it is unlikely. Which it is sure to be if everyone dismisses it. You're right in so much as not a lot of people care. But for the people that do care, it is very important, and works just great. (Note, I am not one of those people, though I am in the web of trust having been involved in Debian, which takes it very seriously.) If you are the sort of person who has a GPG key and get's it signed, then the chances are that you can establish trust with an RM that does the same. I've been watching PGP from its birth, and I've seen very little evidence of the web of trust growing from geeks like us to the sort of people who download and install Tomcat. If you can offer some counterevidence, I'm all eyes. My personal enthusiasm is for all Apache projects to share a clear recipe for their users to verify downloads. That recipe should work for *every user* and *every release manager*. -- NS - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- NS
Re: key signing
Caveat: But I do think that if we do have a key signing guide (and I think we should) then it should be strict about our standards. (i.e. when and when not to sign somebody's key. Basic QA on what sort of trust we're trying to build here.) On Mon, Oct 8, 2012 at 11:15 PM, Noah Slater nsla...@tumbolia.org wrote: Perhaps not Tomcat, but the entire Foundation and all of it's current and future projects should be under consideration here. The long and short of it is that key signing can't hurt. And a key signing guide certainly can't hurt. RMs should feel free to do this, if they are interested in it, and users who care about it can take advantage of it, if it interests them. I certainly wouldn't want to think that we mandate anything. (You know you can't be a Debian developer until you have your key signed by another Debian developer? That set me back months. I'm something of a recluse!) On Mon, Oct 8, 2012 at 10:37 PM, Benson Margulies bimargul...@gmail.comwrote: On Mon, Oct 8, 2012 at 5:18 PM, Noah Slater nsla...@tumbolia.org wrote: On Mon, Oct 8, 2012 at 4:53 PM, Benson Margulies bimargul...@gmail.com wrote: There's another side to this, which I would derisively label, 'so what'? How does it help a user to see that my key is signed by 27 of my fellow Apache contributors, if the user has never met any of us, and has never met anyone who has met any of us, etc, etc. In other words, the Web of Trust only helps users (very much) if they are active participants, and likely to have trust links that reach ASF release managers. In my opinion, that's vanishingly unlikely, and so the best we can do is to allow users to verify that the signature was, in fact, made by the 'Apache hat' that it claimed to be made by. Using the keys in KEYS, or the fingerprints from LDAP, seems the best they can do. To me, this seems like an outright dismissal of the web of trust because it is unlikely. Which it is sure to be if everyone dismisses it. You're right in so much as not a lot of people care. But for the people that do care, it is very important, and works just great. (Note, I am not one of those people, though I am in the web of trust having been involved in Debian, which takes it very seriously.) If you are the sort of person who has a GPG key and get's it signed, then the chances are that you can establish trust with an RM that does the same. I've been watching PGP from its birth, and I've seen very little evidence of the web of trust growing from geeks like us to the sort of people who download and install Tomcat. If you can offer some counterevidence, I'm all eyes. My personal enthusiasm is for all Apache projects to share a clear recipe for their users to verify downloads. That recipe should work for *every user* and *every release manager*. -- NS - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- NS -- NS
Re: key signing
On Mon, Oct 8, 2012 at 6:15 PM, Noah Slater nsla...@tumbolia.org wrote: Perhaps not Tomcat, but the entire Foundation and all of it's current and future projects should be under consideration here. The long and short of it is that key signing can't hurt. And a key signing guide certainly can't hurt. RMs should feel free to do this, if they are interested in it, and users who care about it can take advantage of it, if it interests them. I certainly wouldn't want to think that we mandate anything. (You know you can't be a Debian developer until you have your key signed by another Debian developer? That set me back months. I'm something of a recluse!) I'm absolutely not opposed to key signing. I am somewhat opposed to presenting 'look at the signature(s)' as a very prominent verification options on a page aimed at users. I am very much in favor of streamlining and describing alternatives that avoid the need for the user to be a WoT participant, such as taking advantage of KEYS files and the like. On Mon, Oct 8, 2012 at 10:37 PM, Benson Margulies bimargul...@gmail.comwrote: On Mon, Oct 8, 2012 at 5:18 PM, Noah Slater nsla...@tumbolia.org wrote: On Mon, Oct 8, 2012 at 4:53 PM, Benson Margulies bimargul...@gmail.com wrote: There's another side to this, which I would derisively label, 'so what'? How does it help a user to see that my key is signed by 27 of my fellow Apache contributors, if the user has never met any of us, and has never met anyone who has met any of us, etc, etc. In other words, the Web of Trust only helps users (very much) if they are active participants, and likely to have trust links that reach ASF release managers. In my opinion, that's vanishingly unlikely, and so the best we can do is to allow users to verify that the signature was, in fact, made by the 'Apache hat' that it claimed to be made by. Using the keys in KEYS, or the fingerprints from LDAP, seems the best they can do. To me, this seems like an outright dismissal of the web of trust because it is unlikely. Which it is sure to be if everyone dismisses it. You're right in so much as not a lot of people care. But for the people that do care, it is very important, and works just great. (Note, I am not one of those people, though I am in the web of trust having been involved in Debian, which takes it very seriously.) If you are the sort of person who has a GPG key and get's it signed, then the chances are that you can establish trust with an RM that does the same. I've been watching PGP from its birth, and I've seen very little evidence of the web of trust growing from geeks like us to the sort of people who download and install Tomcat. If you can offer some counterevidence, I'm all eyes. My personal enthusiasm is for all Apache projects to share a clear recipe for their users to verify downloads. That recipe should work for *every user* and *every release manager*. -- NS - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- NS - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Let's try a little statistically-invalid experiment of sample size one. The last time I had a key signed at Apache, it was by Dan Kulp. Now, pretend that you are a suspicious user of one of the many Maven plugins releases that I RM. Can you reach Dan from yourself in the web? Is there anyone you, personally, trust who starts a chain that leads to him? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
I don't know how to check that. Heh. Would be interested in giving it a shot. Are there tools to look up graphs? On Mon, Oct 8, 2012 at 11:23 PM, Benson Margulies bimargul...@gmail.comwrote: Let's try a little statistically-invalid experiment of sample size one. The last time I had a key signed at Apache, it was by Dan Kulp. Now, pretend that you are a suspicious user of one of the many Maven plugins releases that I RM. Can you reach Dan from yourself in the web? Is there anyone you, personally, trust who starts a chain that leads to him? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- NS
Re: key signing
Found one... Just poking around manually... J. Daniel Kulp dk...@apache.org http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x858FC4C4F43856A3 Signed by Carsten Ziegeler cziege...@apache.org http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x132E49D4E41EDC7E Signed by Marcus Crafter craft...@debian.org http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x394D2FE3C4C57B42 And all Debian folk are connected, as per my pervious email. :) There should be a tool for this! On Mon, Oct 8, 2012 at 11:23 PM, Benson Margulies bimargul...@gmail.comwrote: Let's try a little statistically-invalid experiment of sample size one. The last time I had a key signed at Apache, it was by Dan Kulp. Now, pretend that you are a suspicious user of one of the many Maven plugins releases that I RM. Can you reach Dan from yourself in the web? Is there anyone you, personally, trust who starts a chain that leads to him? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- NS
Re: key signing - issues
On 10/5/2012 8:04 AM, Benson Margulies wrote:... As far as I can see, we don't do anything to facilitate or encourage getting PGP keys signed. We tell people to create a key and put it in the SVN 'keys' file. Key signing strikes me as a bit of a conundrum for us. In all other respects, we emphasize that anyone, anywhere, in any time zone, can be a full member of a community. However, key signing requires something else. [1] Generally, it requires a face-to-face interaction. This is fundamentally two separate issues: 1- Explaining the importance of the PGP Web Of Trust and how it relates to the security of downloads from Apache projects, both to our committers/contributors and to our users. While web of trust may be familiar to many of us, I don't think it's importance and details are familiar with many software users. This is an area that I'd support folks going off and JDFI by making patches against things like /dev/* and the incubator website, both for really clearly written how do I... steps, as well as why do I care things. And yes, putting in a big note about promoting keysignings at Apache-related events is key. Virtually every ApacheCon has had a keysigning party, and it is usually emailed to committers@... but sometimes not until the last minute. 8-) See also: http://wiki.apache.org/apachecon/PgpKeySigning 2- Better providing assurances to the users of Apache projects that the software they download is legitimate. This is a much bigger problem. It's great that we know that ApacheFoo-1.2.zip is the correct download, because we know what PGP is and know someone who knows someone who signed the Foo release manager's key. But that chain of information is actually very little use for the 99% of Apache software downloading human beings, who have no clue - nor do they particularly care - who we as individuals are. Fundamentally, the ASF does not really *directly* provide assurances to our users that their downloads are legitimate. Instead, we rely on the social contract that PMCs know how to run projects, and that they properly manage their release managers. It's the release managers who sign downloads as *individuals* that is the tie the actual end user has between the .zip/.tar.gz and the fact it came from our organization. A classic solution to this is as Benson suggests: have a role account that is specifically tied to the ASF as an organization that provides this link. I.e. signed .zip - RM key - secretary@ key - official ASF officer. This has been suggested a number of times before in several different contexts (PGP, Windows authentication, Java/JAR signing, etc.) and has never made real progress. Two key issues are: 2a- Organizational security and reputation. I.e. how do we both securely (really securely) store a secretary@ key, and how do we ensure we have policies that reliably ensure our release managers are properly following Foundation policies? That's a big organizational question the members and board would have to be comfortable with. 2b- Demonstration of need. The ASF is big enough that just neat ideas that are useful aren't necessarily enough to just make things happen. There needs to be a clearly expressed and specific need that an actual Apache project has now, before we will often have the organizational will and energy to make a concrete change. This one I think is hard to quantify, but to me at least, is hugely important. We provide software for the public good - often in very easy to use ways. But our security mechanism for validating downloads is *not* easy to understand or use. Given the importance of Apache software products in today's computer ecosystem - both traditional (running servers) and newer stuff (Apache OpenOffice anyone?) - personally I think it would be really nice to figure out how we can make it *easy* and *trustable* for end users to know they're getting the right software. Does that separation of two issues make sense? I'm not the infra/downloads/keys expert personally these days, so unfortunately I can't go lead this effort, but I do want to be sure we try to keep issues like this very clear, both to understand them, and to understand the specifics of what our actual Apache projects need (so that then the ASF as an organization can better decide how to help them). - Shane - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: key signing - issues
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:bimargul...@gmail.com] Sent: Sunday, October 07, 2012 08:32 To: general@incubator.apache.org 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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Benson Margulies wrote on Fri, Oct 05, 2012 at 08:04:04 -0400: Alternatively, since the chain is CLA - svn access - unsigned key in svn, perhaps all we really need is to document that a signature corresponding to a key in svn is really good enough, and users need not be concerned further. Downloading keys from https://www.apache.org/dist/ or https://people.apache.org/keys/ is good enough enough for users who trust root@ and Thawte. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Daniel Shahaf wrote on 05.10.2012 at 15:15: Benson Margulies wrote on Fri, Oct 05, 2012 at 08:04:04 -0400: Alternatively, since the chain is CLA - svn access - unsigned key in svn, perhaps all we really need is to document that a signature corresponding to a key in svn is really good enough, and users need not be concerned further. Downloading keys from https://www.apache.org/dist/ or https://people.apache.org/keys/ is good enough enough for users who trust root@ and Thawte. A few days ago, I've been learning from a mail on this list, that it was OK to participate in the Apache community using only a pseudonym. The question is, how far is this going? May releases be signed with keys belonging to a pseudonym? PGP/GPG's concept in general is that keys contain their owner's real name. If releases may be signed under pseudonyms, then, if I understood the Apache pseudonym rules right, the only one who would be able to sign such a key was secretary@, since it's the only one who knows the pseudonym's real identity. Regards Florian - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
HI, On Fri, Oct 5, 2012 at 3:15 PM, Daniel Shahaf d...@daniel.shahaf.name wrote: Downloading keys from https://www.apache.org/dist/ or https://people.apache.org/keys/ is good enough enough for users who trust root@ and Thawte. +1 It's good to recommend people to get their keys signed by someone in the Apache web of trust and I think we could do more in that area, but having a key available on an apache.org server seems like a good enough fallback until the key gets signed. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Hi Florian, On Oct 5, 2012, at 8:44 AM, Florian Holeczek wrote: if I understood the Apache pseudonym rules right, the only one who would be able to sign such a key was secretary@, since it's the only one who knows the pseudonym's real identity. The ICLA documents are available to all Apache Foundation Members. They are confidential but hundreds of people can view them. Craig Craig L Russell Secretary, Apache Software Foundation c...@apache.org http://db.apache.org/jdo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Craig L Russell wrote on Fri, Oct 05, 2012 at 08:59:26 -0700: Hi Florian, On Oct 5, 2012, at 8:44 AM, Florian Holeczek wrote: if I understood the Apache pseudonym rules right, the only one who would be able to sign such a key was secretary@, since it's the only one who knows the pseudonym's real identity. Not possible. There is no PGP key for secret...@apache.org (as a role identity). The ICLA documents are available to all Apache Foundation Members. They are confidential but hundreds of people can view them. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Fri, Oct 5, 2012 at 4:42 PM, Juan Pablo Santos Rodríguez juanpablo.san...@gmail.com wrote: Hi, picking up Benson's initial question, just my 2c: how about encouraging a key signing party (or something alike, but more informal and/or with fewer people) through general@i.a.o for every Apachecon, say 2-3 weeks before it starts? If there's something ongoing is easier to hop in than lurking for unaware committers in search of a key signing. At least, it should put in touch interested people. At the first and only Apachecon I attended, there was such a party. But I somehow completely missed the memo in advance, and so could not participate. Oh Secretary, why not create a 'role' PGP key and use it? br, juan pablo On Fri, Oct 5, 2012 at 6:06 PM, Daniel Shahaf d...@daniel.shahaf.namewrote: Craig L Russell wrote on Fri, Oct 05, 2012 at 08:59:26 -0700: Hi Florian, On Oct 5, 2012, at 8:44 AM, Florian Holeczek wrote: if I understood the Apache pseudonym rules right, the only one who would be able to sign such a key was secretary@, since it's the only one who knows the pseudonym's real identity. Not possible. There is no PGP key for secret...@apache.org (as a role identity). The ICLA documents are available to all Apache Foundation Members. They are confidential but hundreds of people can view them. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Benson Margulies wrote on Fri, Oct 05, 2012 at 17:12:27 -0400: Oh Secretary, why not create a 'role' PGP key and use it? Because it's harder to implement than to state, and no one has identified a need for it. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Hi Benson, On Oct 5, 2012, at 2:12 PM, Benson Margulies wrote: On Fri, Oct 5, 2012 at 4:42 PM, Juan Pablo Santos Rodríguez juanpablo.san...@gmail.com wrote: Hi, picking up Benson's initial question, just my 2c: how about encouraging a key signing party (or something alike, but more informal and/or with fewer people) through general@i.a.o for every Apachecon, say 2-3 weeks before it starts? If there's something ongoing is easier to hop in than lurking for unaware committers in search of a key signing. At least, it should put in touch interested people. At the first and only Apachecon I attended, there was such a party. But I somehow completely missed the memo in advance, and so could not participate. Oh Secretary, why not create a 'role' PGP key and use it? I think there is a terrible misunderstanding here. Keys are signed by people who personally and physically know the person whose key(s) they are signing. So without actually meeting people, I would not, should not, sign anyone's key. This is why we have key signing parties. I've attended many parties at Apachecons and have signed many keys. But my role as secretary is not at all related to key signing. Regards, Craig br, juan pablo On Fri, Oct 5, 2012 at 6:06 PM, Daniel Shahaf d...@daniel.shahaf.namewrote: Craig L Russell wrote on Fri, Oct 05, 2012 at 08:59:26 -0700: Hi Florian, On Oct 5, 2012, at 8:44 AM, Florian Holeczek wrote: if I understood the Apache pseudonym rules right, the only one who would be able to sign such a key was secretary@, since it's the only one who knows the pseudonym's real identity. Not possible. There is no PGP key for secret...@apache.org (as a role identity). The ICLA documents are available to all Apache Foundation Members. They are confidential but hundreds of people can view them. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Craig L Russell Architect, Oracle http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@oracle.com P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
Craig, I appreciate the general scheme of signing. It seems as if we have two approaches to key trust. One is the in-person web of trust, and the other is the CLA - account - key-in-ldap/svn. Given the Foundations' emphasis on geographic diversity, the later seems to me to be more appropriate. I was thinking about the idea that we might want to reflect this with via a key signature, but I can see that this might muddy some waters. --benson - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: key signing
On Fri, Oct 5, 2012 at 8:55 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: It's good to recommend people to get their keys signed by someone in the Apache web of trust and I think we could do more in that area, Maybe if we didn't insist on face-to-face meetings we'd get better adoption rates. Apache dev docs: http://www.apache.org/dev/openpgp.html#wot-link-in How To Link Into A Public Web Of Trust In short, expect that: * this will involve a face-to-face meeting GnuPG docs: http://www.gnupg.org/gph/en/manual.html#AEN84 A key's fingerprint is verified with the key's owner. This may be done in person or over the phone or through any other means as long as you can guarantee that you are communicating with the key's true owner. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Key signing for shindig packages.
On Sat, 2009-10-03 at 16:43 +0800, Niclas Hedhman wrote: On Sat, Oct 3, 2009 at 3:34 AM, Paul Lindner lind...@inuus.com wrote: Hi, Over in the shindig podling we've been working on our 1.1 release. During the voting process it was mentioned that my gpg key is not part of the apache web of trust. * We have the +1s for shindig-1.1-BETA3, does this signature problem disqualify the release? IMHO, No it doesn't. What you should ensure is that the key used for the signing is both committed to the SVN, uploaded to pgp.mit.edu (and other if possible) and that the finger print is published on the official website. * I'd appreciate any/all help getting my gpg key signed by the proper people so we can get a release out asap -- this 1.1 release has been a long time coming. Once we get over this hurdle we feel we'll be close to graduating. Cross-signing of keys should happen in person, where identity can be ensured. If there are people you know really well, a phone call where the other part can recognize your voice, preferably being the one calling you up on a well-known phone number, to transfer the fingerprint info... Ensure that some of you get to ApacheCon. I don't believe it is too far away from you. Worst case, you might be able to get some folks there to sign your key even if you don't attend the actual conference itself. Does it disqualify this release? No. The signed key is to validate authenticity of an Apache release. Right now, I'd say we're more concerned about the podling being able to produce decent releases. So long as the release has all the bits in the right places, that is enough. However, getting keys signed is a good thing to do in preparation for ongoing (esp post graduation) releases. Upayavira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Key signing for shindig packages.
On Sat, Oct 3, 2009 at 3:34 AM, Paul Lindner lind...@inuus.com wrote: Hi, Over in the shindig podling we've been working on our 1.1 release. During the voting process it was mentioned that my gpg key is not part of the apache web of trust. * We have the +1s for shindig-1.1-BETA3, does this signature problem disqualify the release? IMHO, No it doesn't. What you should ensure is that the key used for the signing is both committed to the SVN, uploaded to pgp.mit.edu (and other if possible) and that the finger print is published on the official website. * I'd appreciate any/all help getting my gpg key signed by the proper people so we can get a release out asap -- this 1.1 release has been a long time coming. Once we get over this hurdle we feel we'll be close to graduating. Cross-signing of keys should happen in person, where identity can be ensured. If there are people you know really well, a phone call where the other part can recognize your voice, preferably being the one calling you up on a well-known phone number, to transfer the fingerprint info... Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Key signing practicalities Was: status of PGP support in Maven
Hi Janne, I will be traveling to Helsinki within the next 6 months (probably). If you're on tripit you can watch for my trip (in case I forget for some reason to let you know). Craig On Sep 23, 2008, at 11:36 PM, Janne Jalkanen wrote: So you assume that that www.apache.org can not be hacked? What if a signing key *IS* in KEYS but not signed by anyone (because the developer has never attended an Apache key signing event)? Which reminds me - if one does not attend an Apache key signing event (which tend to be in faraway countries, traveling to which usually means parting with lots of cash), how *does* one get the key signed? Is there a regional list somewhere? Any people near Helsinki, Finland who are willing to have a coffee and sign my key? ;-) /Janne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: Key signing practicalities Was: status of PGP support in Maven
Hi, On Wed, Sep 24, 2008 at 8:36 AM, Janne Jalkanen [EMAIL PROTECTED] wrote: Any people near Helsinki, Finland who are willing to have a coffee and sign my key? ;-) I'll be in Helsinki for two weeks after the ApacheCon US. BR, Jukka Zitting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
