-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi
On Wednesday 2 March 2011 at 8:27:50 PM, in <mid:4d6ea846.4080...@sixdemonbag.org>, Robert J. Hansen wrote: > The analogy continues to break down. "Binding," in the > context of the analogy, means "if someone breaks this > instruction, they will be hurt." Maybe the government > will start a criminal prosecution, maybe you have > recourse in a civil lawsuit, but ... ultimately, "if > someone breaks this instruction, they will be hurt." > Okay, fine: who are you electing to be the > hurt-inflicter for the OpenPGP community? And in the > absence of a designated hurt-inflicter, how can there > be a "binding instruction"? You are going off at a tangent. The mechanism for preventing the phone number being obtainable from a query of the phone book or directory enquiry services is not relevant; just the fact that it can easily be done. Consider these scenarios:- 1. I have a phone number that you don't know. This phone number is listed in the phone book and at directory enquiries. It is trivial for you to obtain the number. 2. I have a phone number that you don't know. This phone number is not listed in the phone book or at directory enquiries. It is harder for you to obtain the number. A parallel exists with:- 3. I have email addresses that you don't know. These email addresses are readable from my key's user IDs. It is trivial for you to obtain these email addresses. 4. I have email addresses that you don't know. These email addresses are not readable from my key's user IDs. It is harder for you to obtain these email addresses. "This phone number is not listed in the phone book or at directory enquiries" is easily achieved by being ex-directory; this does not affect the usefulness of my telephone service. It is only easy because the appropriate mechanism has been put in place to achieve it. "These email addresses are not readable from my key's user IDs" is easily achieved by simply not including them in the user IDs. This is easy because the user ID field is free-text and doesn't have to be Name (Comment) <email address>. This adversely affects the usefulness of my key, since MUAs commonly rely on the email address in the user ID for key selection. Hashed user IDs are a possible alternative mechanism to achieve "these email addresses are not readable from my key's user IDs" that could have less of an adverse affect on key usefulness. > The analogy you're drawing is appealing at first > glance, but the more I look at it the more it breaks > down. I said "in this respect the two are similar." You appear to be saying "they are not similar because in these other respects they are different." >> It is also much easier to create new email addresses >> than it is to change phone numbers. > I would *far* rather change my phone number than change > my email address. Probably a total of 50 people have > my phone number: if I change it, big deal. If I change > my email address, I'd probably need to inform upwards > of a thousand people of the change. A good point well made. I was comparing the effort involved in actually creating a new email address (a few seconds to a couple of minutes at the keyboard) to the effort involved in actually getting the phone company to change a phone number (ringing the phone company, navigating their stupid menu system, eventually getting through to a customer service agent in foreign parts who barely speaks English, trying to make them understand, discussing the reasons why they should provide the number change - such as nuisance phone calls you have been receiving, wait for the change to happen, chase up the billing errors, etc.). - -- Best regards MFPA mailto:expires2...@ymail.com Never lean forward to push an invisible object. -----BEGIN PGP SIGNATURE----- iQE7BAEBCgClBQJNbtQRnhSAAAAAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pARsD/1iG sr2ROg6NOqTJDhasftiQwXYZ9YiEFK4TacuT1TIl8MRYynMJU35EgqioWvh3B3LJ Mfqaqvff9OlK8wyrmbQ585USxmXYf7aDtsfI3tqzrvgoYIMpl/iLRxpN4JGwSpv1 D2r2jlIHUq1LehNUYjbl0DGR+1kishfWhAHkxiSO =euzF -----END PGP SIGNATURE----- _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users