Subject: Preferred Key Server subpacket in non-self-signature?

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 28 Apr 2009 10:31:57 -0400

I'm trying to understand the preferred key server subpacket [0] and how
one might reasonably respect it in an implementation without causing
potential for things that are the OpenPGP equivalent of "web bugs", but
while still keeping it useful.

While looking into this, it occured to me that the RFC doesn't
explicitly say that the Preferred Key Server subpacket must only reside
on a self-signature.  So, what would it mean if the Preferred Key Server
subpacket was included in a third-party certification?

For example, Alice has an OpenPGP with her User ID "Alice".  Bob meets
Alice, checks fingerprints, and certifies her User ID with a signature
type 0x10.  But his signature contains a Preferred Key Server sub-packet
that points back to http://bob.example.org/alice

Carol imports Alice's key, but wants to be sure that she has the latest
updates, revocations, and so forth, so she asks her OpenPGP client
(which defaults to using pool.sks-keyservers.net) to refresh from the
keyservers.  What should Carol's OpenPGP client do in this case?

What about in the case where the Preferred Key Server subpacket is on
Alice's self-sig?  What about two different Preferred Key Server
subpackets (one from Alice, one from Bob)?

	--dkg

http://tools.ietf.org/html/rfc4880#section-5.2.3.18

---

From: David Shaw <[email-masked]>
Date: Tue, 28 Apr 2009 11:50:48 -0400

> subpacket was included in a third-party certification?

I would say it means "Here is how the person who issued that  
certification wants you to get his key".  The same thing applies if  
the preferred keyserver packet was included on a regular data  
signature (which GPG supports, by the way).

> keyservers.  What should Carol's OpenPGP client do in this case?

Her choice, really.  Bob has made a statement that he provides his key  
at a particular address.  It's up to Carol (or Carol's client) to  
decide if she wants to respect that.  She may have reasons (web bug  
behavior) not to follow Bob's statement.  If Bob doesn't put his key  
on keyservers (good luck to Bob, there), then there may be no other  
way to get the key other than following Bob's statement.  Depending on  
how Carol is calculating the validity of Alice's key, Carol may not  
need Bob's key at all - after all Bob is just another signature on  
Alice's key.  Unless Carol is doing some sort of trust calculation,  
and her trust path to Alice runs through Bob, Bob's signature is not  
really relevant here.

> subpackets (one from Alice, one from Bob)?

If there is a preferred keyserver subpacket on Alice's self-sig, then  
it was issued by Alice, and the recipient can either follow it or not,  
as they like.  I'm not sure I follow where Bob's subpacket comes in  
here.

David

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 28 Apr 2009 12:30:02 -0400

On 04/28/2009 11:50 AM, David Shaw wrote:
> certification wants you to get his key".  The same thing applies if the
> preferred keyserver packet was included on a regular data signature
> (which GPG supports, by the way).

Ah, ok.  I was thinking it would refer to where to fetch updates for
that particular signature, not for the key.  The section reads:

   This is a URI of a key server that the key holder prefers be used for
   updates.  Note that keys with multiple User IDs can have a preferred
   key server for each User ID.  Note also that since this is a URI, the
   key server can actually be a copy of the key retrieved by ftp, http,
   finger, etc.

"used for updates" was unclear to me because i was thinking that it
meant "to get updates about this signature" rather than "to get updates
about the signer's key".

Is there a way for the issuer of a signature to provide a place where
updates to the signature itself (e.g. revocations, or re-certifications)
would be published?

I understand that the global keyserver network is normally what you'd
use.  But i'm trying to work through the context of an organization who
wants to also publish all their signature revocations in a known,
canonical location (including the revocations of certifications of
third-party keys).  Maybe this use case is misguided or irrelevant,
though.  Is it?

> Unless
> Carol is doing some sort of trust calculation, and her trust path to
> Alice runs through Bob, Bob's signature is not really relevant here.
>  [...]
> If there is a preferred keyserver subpacket on Alice's self-sig, then it
> was issued by Alice, and the recipient can either follow it or not, as
> they like.  I'm not sure I follow where Bob's subpacket comes in here.

OK, my scenario implicitly presumed that Carol trusts Bob to make good
certifications, but doesn't know Alice.  I should have spelled that out
in the first place.

While Alice's key/userID has been certified by Bob, Carol wants to make
sure that Bob hasn't revoked his certification on Alice's key (and maybe
she's concerned that her keyserver is somehow compromised and not
producing the correct revocation certificates, or Bob doesn't want to or
can't publish his revocation to the public keyservers).

The more i think about this, the more the answer seems to be that Bob
should run his own keyserver and publish everything there first.  But i
don't see a way that Bob can indicate "check for revocations and
re-certifications at hkp://foo.example.net".  This seems like another
opportunity for "web bugs"-style shenanigans, though.

	--dkg