Penguin
Blame: PGPGlobalDirectory
EditPageHistoryDiffInfoLikePages
Annotated edit history of PGPGlobalDirectory version 30, including all changes. View license author blame.
Rev Author # Line
27 StuartYeates 1 An [OpenPGP] [KeyServer] run by the [PGPCorporation].
2
3 ''Note that the behaviour of the beta has changed over the course of the last weeks and that at least a couple of these appear to no longer apply''
4
5 Good points
6 # Having a convenient place to lookup current, valid keys is a great
7
8 A list of issues includes:
9 # When viewed as a [RobotCA] the [PGPGlobalDirectory] is signifcantly weaker than other [RobotCA]s in that it sends verifications unencrypted and unsigned.
10 # The server strips signatures from keys not registered with it. ''Signatures are now reported in the web interface but not included in the download (20/Dec/2004 StuartYeates).''
11 # The server strips revocations from keys and thus happily serves revoked keys sans revocation. ''The server now correctly refuses to upload revoked keys. (7/Jan/2005 StuartYeates).''
12 # The server does not appear to provide any method of viewing signatures on the keys it serves.
13 # The key used to sign keys is not itself viewable through the server. ''This appears to now be fixed (20/Dec/2004 StuartYeates).''
14 # Signatures and keys published on other key servers do not appear to migrate to the [PGPGlobalDirectory], and visa versa.
15 # Server asks users to sign the directory verification key without any independent verification.
16 # Signatures issued by the [PGPGlobalDirectory] do not use a policy URL.
17 # Older versions of [OpenPGP] keys (V3 and previous) are not supported, though this can be regarded as a feature due to various weaknesses with V3 keys.
18 # Access to a single email account given in a uid for a key permits the key to be removed for email addresses in all uids, without contacting the other email addresses.
19 # There appears to be a bug which occurs when a key with multiple uids/emails is replaced with one with a single uid/email which is in turn replaced with the original key. Verification messages are sent to the multiple emails, but only the verification that goes to the email address that was on the single uid/email actually works. The others get a message aobut the verification timing out. ''This appears to now be fixed (20/Dec/2004 StuartYeates).''
20 # The timing out of verifications is worrying given the message "No further messages regarding the PGP Global Directory will be sent to this email address unless you choose to participate by providing a verification response to this email." That appears in the verification email. It suggests that if the verification email is lost or times out then the email address is effectly barred from using the keyserver there after. ''This now appears to be fixed (20/Dec/2004 StuartYeates).''
21 # When it believes a key no longer matches an email address [PGPGlobalDirectory] should issue a revocation for the signature (as well as removing the key).
22 # [PGPGlobalDirectory] should not multiply sign the same key within a short space of time, as it currently does if a user switches rapidly between two of more keys for an email address. Multiple signing may be acceptable if the current signature is about to expire or has expired (the current signature expiry is set so short it is hard to tell whether this is kicking in already).
23 # [PGPGlobalDirectory] actively discourages users' self-eductaion about security, [PGP] and [OpenPGP] in general.
24 # For an approach that is so keen on expiring keys and signatures, it seems odd that the directory verification key does not have an expiry date set.
25 # It is not clear whether mirroring, syncing or other facilities are going to be avaliable so that institutions concerned about keyserver requests going outside their intranet can establish a local copy, as they can with other keyserver solutions. ''There are reports that submitting keys to the old PGP servers results in confirmation emails being sent to users through the beta, but I've been unable to reproduce this (20/Dec/2004 StuartYeates).''
28 IanMcDonald 26 # Searching for a name requires the exact name. "Stuart A Yeates", "Stuart A. Yeates" and "Stuart Andrew Yeates" are considered unrelated names and there is no way to search using a substring. ''This is only true when searching through the web interface. It is not true when searching via GnuPG or the PGPKeys GUI. In these cases (which are actually LDAP searches), substring searches are available. (22/Dec/2004 David Shaw).'' ''This is requires upgrading to the new [GnuPG] 1.5 release (7/Jan/2005 StuartYeates).''
27 StuartYeates 27 # The system is unnecessarily incompatible with existing search tools and systems, particularly with respect to searching for keys.
30 StuartYeates 28 # The system make no attempt to recieve key revocations from other key servers (such as the subkeys network, which is very widely used), and when you upload a new revoked version of a listed key it refuses to update it with the revoked key, but DOESN'T REMOVE THE LISTED KEY EVEN WHEN IT HAS SEEN A GOOD REVOCATION CERT FOR IT.
27 StuartYeates 29
30 See: https://keyserver-beta.pgp.com/
31
32 There is a critique (in German) at: http://www.heise.de/security/news/meldung/54375
33
34 There is a discussion (in English) at: http://lists.gnupg.org/pipermail/gnupg-users/2004-December/thread.html#23841
35
36 To see what a key sign by this looks like, see http://pgpkeys.pca.dfn.de:11371/pks/lookup?search=0x8836C97C&fingerprint=on&op=vindex Notice in particular the many signatures with short expiry dates with new signatures automatically issued a day before the old signature expires.
37
38 !!These guys sent me an email, what do I do?
39
40 This is probably the result of someone sending your key to the old pgp keyserver (think <code>gpg --keyserver keyserver.pgp.com --send ....</code>). If you intend to regularly communicate with PGP users in the commercial world you best bet is probably to get on the key server. It's really your personal choice. The email sent by PGP times out very quickly, so you may have to use the web interface.
41
42 !!And the Verification Key?
43
44 "After downloading, import the Verification Key into your PGP software. Then, sign the key with your key and mark it as Trusted. Please see the documentation for your PGP software for specific instructions on trusting a key."
45
46 Yes, this is indeed exceptionally evil. I (StuartYeates) strongly advise against signing this key. At the time of writing the key has garnered more than 200 signatures, so maybe it's going to prove an effective tool for determining a set of PGP users whose signatures can't be trusted in the WebOfTrust. Note that there is a particularly damaging asymmetry in signing this key, because while the PGP system is issuing very short term signatures, most of the signatures it receives have indefinite duration.