Seeking clarification with a few GPG concepts

[MFPA]

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

Hi


On Wednesday 13 August 2014 at 9:44:59 AM, in
<mid:20140813084459.90FB42073E at smtp.hushmail.com>, pzeudo at hushmail.com
wrote:


> she issues adduid to add "Alice <uid2 at company.com>",
> her company mailing address. After some time, she
> leaves the company, invalidating her email address.
> Consequently, she revokes her UID uid2 at company.com and
> sends her updated public key to everyone she's in
> contact with. Then, for some reason, Alice joins
> aforementioned company again, re-gaining control of her
> mail address uid2 at company.com. Can she add a new UID of
> the same name "Alice <uid2 at company.com>" to her gpg key
> again?

Yes, she can.



> I understand that she would not be able to
> re-use signatures she collected on her "old" UID on her
> "new" one, but would have to start building trust from
> scratch. But still, is it possible to do so, or would
> the revocation of the "old" uid2 also immediately apply
> to the "new" uid2?

The revocation is a signature over the specific uid (or uids) that
were selected when the "revuid" command was issued. And, as you say,
she would not be able to re-use signatures she collected on her "old"
UID2 on her "new" one.




> Second, if her notebook subordinate key can
> sign/decrypt for both UIDs, and someone sends a mail to
> uid1 at alice.com, which pubic key does he encrypt the
> message with? I assume the sender, by default, would
> simulatenously use all encryption keys (master or
> subordinate) he knows of, so that the message can be
> decrypted with any one private key. Is that the case?
> Can the sender choose to only encrypt using one of the
> keys, e.g. to make sure Alice doesn't read the message
> on her phone, but waits until she gets home to her
> notebook (in case the sender considers it more
> trustworthy, and the sender knows how the keys are
> associated with Alice's machines)?

Alice would need to come to a specific arrangement with the sender for
that to be possible. In general, if Alice has shared multiple
encryption keys with the same email address in the uids, the sender
might encrypt to any one of them (or any subset).



> What happens if a subordinate key of mine expires? Can
> I just generate a new one and let people know? Or would
> I also have lost trust/signatures of my identities
> gathered in the past?


What do you mean by a "subordinate key?" A subkey? Or another,
completely unrelated key?

In either case, one option is to simply edit the expiry date and keep
the existing key.

In the case of a subkey, allowing it to expire and creating a new one
makes no difference to the existing signatures.

If you just mean another, unrelated key, switch to a new key and the
new one starts without a collection of signatures.



> Phrased differently, if Bob
> signes Alice's UID X, what does he sign exactly?

Are you asking just the meaning, or what the signature is calculated
over?



> Just
> that he trusts UID X belongs to the name and address
> given in UID X, and that UID X is associated with
> Alice's master key, or does Bob's signature also say
> something about subordinate keys of Alice's gpg key
> and/or other UIDs of Alice which Bob did not intend to
> verify?

The trite answer is Bob's signature means whatever Bob wants it to
mean. He might even publish a key signing policy to tell people what
he means. Put "key signing policy" (without the quotes) into your
favourite search engine to see some examples.

Typically, Bob's signature might mean Bob asserts:-

(1)        that Alice is known by the name she claims in the UID (or
           has documentation that Bob trusts that supports her claim to that name)

(2)        that Alice has control of (or at least access to) any email
           address contained in that uid

(3)        that Alice has control of the corresponding private key
           (can read a message encrypted to that key and can produce a
           signature using that key).

Bob's signature says nothing about any UIDs other that the one(s) that
Bob has signed.

As to "subordinate keys." If you mean subkeys, they are part of
Alice's key. See (3) above.



> Finally, I am wondering how I should organise my UIDs.
> I could either have one gpg key and add each UID to
> that one, or I could have multiple seperate gpg keys,
> one for each UID.

Or some identities on one key together, plus some other identities on
their own keys.



> The latter approach seems more
> flexible to me, in terms of choosing how much
> information I want to disclose to recipients of my gpg
> keys,

Yes. But also more effort for you. And if people know more than one of
your identities, slightly more effort for them.



> and, depending on the answers to the questions
> above, also in terms of control I have over how my keys
> are used.

Once you have given somebody else a copy of your public key, do you
have *any* control over how they use it?



> Does having all UIDs in one gpg key have any
> advantages, except for being easier to organise for me
> and for people who want to sign my identities?

Not that I am aware of.



> Would it
> be considered strange, or even rude of some sort, if I
> asked someone to sign a number of identities of mine
> scattered across multiple gpg keys, instead of just
> handing them one gpg key and asking them to sign UIDs
> x, y and z?

I'll leave that one to somebody who has chosen to participate in the
web of trust. There are several such people who contribute to this
list. (-;



> I know these are a lot of questions, but I honestly
> couldn't find satisfactory answers in the documentation
> or using search engines. I would be very grateful if
> you could attempt to enlighten me. :)

I have attempted to help. I'm sure somebody more knowledgeable will be
along shortly.



- --
Best regards

MFPA                    mailto:2014-667rhzu3dc-lists-groups at riseup.net

I don't suffer from insanity I enjoy every minute of it.
-----BEGIN PGP SIGNATURE-----

iPQEAQEKAF4FAlPr0/1XFIAAAAAALgAgaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl
bnBncC5maWZ0aGhvcnNlbWFuLm5ldEJBMjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0
N0VDQTAzAAoJEKipC46tDG5pD+oD/RPr5b3ySOD4OlN9GG3HKTM7/vAY6aNVevv7
ONp2v9FtN0eyraFj5lV+5IBhFVjmASgLZKOBqT+tlC59KN9sRNEum8cnQnaZLd+q
uV248/SRCmMvARU971BzZuSck2sUgI5JYe65eihP8CTh5cHRX+BDoJPeo2ooncUQ
a2ul39JY
=NDWI
-----END PGP SIGNATURE-----