On 04/28/2009 11:50 AM, David Shaw wrote:
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).
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,
"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?
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.
Description: OpenPGP digital signature