key question

[MFPA]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Saturday 13 March 2010 at 11:15:32 AM, in
<mid:4B9B73D4.4090305 at gmail.com>, Paul Richard Ramer wrote:


> The issue of law is not "an integral part of the
> answer" to the question of what should be.  It is an
> integral part of the answer to what is.

I see what you mean, but I would say it is integral to both.



> If I were to ask you whether every day should be like
> Christmas, you would likely respond that every day
> couldn't be like Christmas.  Sure, every day couldn't
> be like Christmas, because of the way people are, but
> that doesn't mean that that is the way things ought to
> be.

Although it isn't really that simple. For example in the UK, the vast
majority of shops are closed on Christmas day and most people don't go
to work (except for essential services, hospitality, and the few
shops/petrol stations that are open). Whether people ought to be
"wage-slaves," giving up most of their time to their "master" in
return for barely enough to live on, is another question.



> The reason I wanted you to discuss what you believe
> without regard to the law is because the law is just
> another man's opinion.  I was asking for only yours.

Fair enough. I think I gave both.



>>> For the record, I don't believe that the key holder
>>> should upload the key if the key's originator doesn't
>>> want

>> Seeing as we are framing this in terms of "rights," do
>> you believe the holder has a right to upload in these
>> circumstances but "should not" exercise that right?

> It depends.  Are we talking about ethical rights or
> lawful rights.

> I think the key holder has the ethical and lawful
> rights to use and distribute the key if the key's
> originator doesn't forbid him.  If the keyholder is
> forbidden, he has the lawful right, but not an ethical
> right.

Yes, assuming the key showed no personal information. Depending on the
jurisdiction and the circumstances, the key holder *might not* have
the lawful right to distribute the key originator's personal
information.



> But the key holder shouldn't have to ask the originator
> what he may do with the key.  The key holder should, by
> default, have freedom.

Why? The personal information in the key UIDs is that of the
originator, not the holder. If the key reveals no personal
information, then I agree.



> But if the originator doesn't want his key disseminated, he should
> say so.

If the key reveals no personal information, then I agree. But why
would the holder need to be told the originator doesn't want his
personal information circulated without his permission?



> And by the way, I apply this rule to me.

Which rule? You've already stated that you don't believe the holder
should upload the key if the originator doesn't want, so presumably
you mean that you would tell somebody if you didn't want them to pass
on or upload a key you created?



>>> But I don't believe the originator has a /right/ to
>>> prevent the key holder from sharing it.

>> Morally and ethically, I disagree. To use an example
>> with phone numbers: say I had a personal friend who
>> was an insurance broker with a teenaged daughter and
>> elderly parents. I would suggest it's perfectly in
>> order for me to pass to a third party my mate's
>> business number. I definitely have no moral or ethical
>> right to pass on his daughter's or parent's numbers or
>> his personal number. Some would argue he has a right
>> to give me a good beating if I did.

> So a buddy's business number is public information, and
> you can share it if you like.  But a /public/ key,
> which by default is considered publicly shareable
> information, isn't.

What do you mean "by default?" As far as I know the "public" in
"public key" simply refers to the fact that it *can* be made public
without compromising the security of the encryption or digital
signatures. That does *not* mean that the personal information usually
included in key UIDs for ease of use is publicly shareable.



> I get it!  So it goes like this.  A business telephone
> number is considered by most to be shareable, and
> because of that, it is ethically shareable.  A public
> key is considered by most to be shareable, and because
> of that, it isn't ethically shareable.

A business telephone number *is* considered by most to be ethically
shareable. Key UIDs often contain personal contact details and/or
aliases. Other people's personal contact details are *not* considered
by most to be ethically shareable, and certainly not ethically
publishable.



> Interesting.  "... [C]urrently has no means ...."
> Sounds like you may want some delicious DRM.

Nothing drastic enough for most to consider it DRM, IMHO. It would be
enough for me if keyservers honoured the no-modify flag (with suitable
originator-verification and appropriate measures when synchronising)
subject to the exception you mentioned previously where somebody
revokes a signature they previously placed on that key. Those who
desired that anybody could freely upload their keys to servers would
simply unset the no-modify flag.



> I can't speak for other people, but I can for me.  Take
> a look at the UIDs on my key, which is
> 0xC7C66ADF3DB6D884.  And also, take a look at my master
> key 0x2188A92DF05045C2 that I signed the other key
> with.

> Each of those e-mail addresses on my keys are ones that
> were already associated with my real name.  I had given
> each of those addresses to family, friends, associates,
> businesses, or a combination of them.  Not one of those
> accounts had given me any anonymity, and each had been
> shared outside of people I knew personally.

> By uploading a key with those addresses on it, does
> that mean I gave up privacy that I already had?  No.

It looks to me as if the answer is "yes." Unless each person who had
one of your email addresses already knew the other addresses before
seeing them on your key, they now have extra information about you.
And the addresses have jumped from "shared outside of people [you]
knew personally" to published in a universally-accessible location.
However minor/negligible or unimportant you may consider it, that's a
reduction in privacy.


> I only made it possible for people to now communicate with me with
> more privacy than they could have had before.

And probably shared more of your email addresses with each person than
they had before.



> I wanted to use PGP within my existing situation.

Horses for courses, as they say. I know several people who give a
unique email address to each contact. In their situation, it would be
inappropriate to publish (or even circulate) a key containing all
their email addresses, unless the addresses could be hashed in the
UIDs.



> If in the future I want to go underground with a
> pseudonymous identity, then I will create a PGP key
> specifically for it.

And in that eventuality, do you see the attraction of optionally
hashing email addresses and names in UIDs, so that somebody who
knows your email address can find your key but somebody who
inspects your key gains no information about you from it?



> Or if I  would like to have a
> pseudonymous identity as well my real identity,  then I
> would have a separate key and identity that I would
> protect.

That would be a bit of a bind if you felt that everybody you gave the
pseudonymous key to would need *telling* not to circulate or publish
it without checking with you first.



> We all want an amount of anonymity and privacy.  But we
> each want a different level of it.

For some people, that amount could effectively be "none" judging by
their profile and postings on the likes of Facebook.



> I believe that many
> of us on this mailing list want to use cryptography in
> association with our real identities. Others don't.

You find both camps on this list and elsewhere.



> They prefer anonymity.

Or using a pseudonym, which is not the same thing as anonymity.



> I like anonymity, and I want it for most of my use of
> the Internet. But when I post to this mailing list or
> use those e-mail accounts listed on my public keys, I
> want to associate them with my real identity.

Mine varies between fairly random usernames, MFPA if the site doesn't
insist on something longer, and just a couple of things where I use my
real name.



>>> So if the key holder can't ethically (not talking
>>> about physically) share the key or modify it, then
>>> what "rights" does the key holder have?

>> Any use whatsoever that in no way compromises the
>> privacy of the originator's personal information.

> That is to say none.  Well, other than the fact that he
> can encrypt a message to the originator's key and use
> it in accordance with the key owner's wishes.

The function of the public key is to encrypt messages and to
authenticate/verify digital signatures. Other than that, what do you
believe the holder has a "right" to do with a key without referring to
the originator? (Yes, it can also carry signatures from other people's
keys attesting to their belief in the claimed identity of the
originator, but this would usually have involved some contact with the
originator.)



> Hansen said it best, "DRM of the honor system."

DRM, in the generally accepted use of the term, is all about greed.
And sometimes about copyright or licensing. That is a completely
different objective from wishing to keep the key originator's personal
information private. DRM usually relies on some measure of
intentionally crippling a device or application. Asking somebody
before passing on their personal information cripples nothing. Being
unable to *upload* somebody else's key to a server would cripple
nothing: you already have the key. An option to hash names and email
addresses in UIDs would cripple nothing if the plaintext name or email
address could still be used to locate the key on the server.

IMHO, the only connection between the two is semantic: the keys are
stored in a digital form and we have been discussing what "rights" the
key holder has in respect of the key originator's personal
information.



>> I believe anybody with my details should be able to
>> fetch my key from a server, but looking at my key
>> should give them no extra personal information about
>> me.

> Private dissemination within a public venue.

I don't know why, but that simple phrase suggests to me that you think
it would be a bad thing.



>>> You shouldn't assail the public keyservers.

>> My intention was merely to challenge the statement
>> "it's a good idea to upload your key to a keyserver,"
>> since I had seen such sentiments expressed without
>> qualification various places previously but had always
>> seen more good reasons against than in favour. I got
>> into a much longer (and more interesting) discussion
>> than expected.

> /My way is true and holy.  Follow in my foot steps./

That's similar to my impression of the statement I was challenging.



> I think that you are wrong, because you seem to insist
> that others must do as you do. It would be equally
> wrong for me to insist that others must do as I do.

Have I "insisted on" anything beyond the basic courtesy of obtaining
consent before passing on other people's personal information?



> You and I have different goals--remember that.

We definitely have different thoughts on what information we wish to
put on public record on a keyserver.



> The user's purpose is what matters.  What does he want
> to accomplish? Is it only secrecy of his messages?
> Anonymity?  Who is he communicating with?  What would
> meet his needs?

> It is questions like these that must first be answered.
> Because they define the purpose.  If these questions
> aren't answered, either consciously or unconsciously,
> then user has failed before he has started.

> Why?  Because it is like traveling without first
> determining a destination.  When purpose is defined, it
> is the director of action. The user must yield to
> purpose if he is to succeed.  Then he must let purpose
> to choose the path.

Very eloquently put.



>>> You should be calling for an additional kind of
>>> keyserver to fill the niche of people like you.

>> I think it would work better if the option of
>> increased privacy could be integrated into the
>> mainstream servers.

> It's unlikely to happen.  You are more likely to have
> the existing keyservers integrate the functionality
> that you want if you first create a special keyserver
> for your niche, and then, if it is popular enough, talk
> them into integrating it.

I would have to persuade somebody with the appropriate skills.
Presumably the hashed name or email address option in the UID would be
the easier bit to implement, since a nil return on a search would
simply require hashing the search string (with whatever standard hash
function has been predetermined) and trying again. Honouring
keyserver-no-modify would require much more in-depth consideration,
such as how best to authenticate, signature revocations, and
sending/receiving updates through synchronisation with other servers.



> That way you can have the kind of keyserver that you
> want, now, rather than waiting years to, hopefully,
> succeed in changing the existing keyservers.

I read at http://www.imc.org/ietf-openpgp/mail-archive/msg34233.html
that the SKS keyservers didnt exist when rfc2440 was published
(including defining the no-modify flag). I wonder if
keyserver-no-modify has been neglected by the keyservers for technical
reasons, or was just too low down a list of priorities? (I googled but
couldn't find anything on this question.)



- --
Best regards

MFPA                    mailto:expires2010 at ymail.com

Oven mitt: A partially charred grease stain that fits over the hand.
-----BEGIN PGP SIGNATURE-----

iQCVAwUBS5vwCKipC46tDG5pAQqkPgP+N2zYUSupAQMSiZGVwuTUQMeZSgmjnKuK
zoSOKrZxPMzYyE3DXOiwTt2Pn3SI86NgbBzUPld+IlCRb/m/up+UMXJ+QdX5NHIJ
lTAP2tPtVvzsghMv+C+PvI2+6K3llVVqPfslVK8twH75nHdyBe4L73VfxJVt/J13
mRQYKMQ3BNM=
=Ff19
-----END PGP SIGNATURE-----