summaryrefslogtreecommitdiffstats
path: root/doc/KEYSERVER
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-07 16:14:06 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-07 16:14:06 +0000
commiteee068778cb28ecf3c14e1bf843a95547d72c42d (patch)
tree0e07b30ddc5ea579d682d5dbe57998200d1c9ab7 /doc/KEYSERVER
parentInitial commit. (diff)
downloadgnupg2-eee068778cb28ecf3c14e1bf843a95547d72c42d.tar.xz
gnupg2-eee068778cb28ecf3c14e1bf843a95547d72c42d.zip
Adding upstream version 2.2.40.upstream/2.2.40upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'doc/KEYSERVER')
-rw-r--r--doc/KEYSERVER83
1 files changed, 83 insertions, 0 deletions
diff --git a/doc/KEYSERVER b/doc/KEYSERVER
new file mode 100644
index 0000000..f63200a
--- /dev/null
+++ b/doc/KEYSERVER
@@ -0,0 +1,83 @@
+Format of keyserver colon listings
+==================================
+
+David Shaw <dshaw@jabberwocky.com>
+
+The machine readable response begins with an optional information
+line:
+
+info:<version>:<count>
+
+<version> = this is the version of this protocol. Currently, this is
+ the number 1.
+
+<count> = the number of keys returned in this response. Note this is
+ the number of keys, and not the number of lines returned.
+ It should match the number of "pub:" lines returned.
+
+If this optional line is not included, or the version information is
+not supplied, the version number is assumed to be 1.
+
+The key listings are made up of several lines per key. The first line
+is for the primary key:
+
+pub:<fingerprint>:<algo>:<keylen>:<creationdate>:<expirationdate>:<flags>
+
+<fingerprint> = this is either the fingerprint or the keyid of the
+ key. Either the 16-digit or 8-digit keyids are
+ acceptable, but obviously the fingerprint is best.
+ Since it is not possible to calculate the keyid from a
+ V3 key fingerprint, for V3 keys this should be either
+ the 16-digit or 8-digit keyid only.
+
+<algo> = the algorithm number from RFC-2440. (i.e. 1==RSA, 17==DSA,
+ etc).
+
+<keylen> = the key length (i.e. 1024, 2048, 4096, etc.)
+
+<creationdate> = creation date of the key in standard RFC-2440 form
+ (i.e. number of seconds since 1/1/1970 UTC time)
+
+<expirationdate> = expiration date of the key in standard RFC-2440
+ form (i.e. number of seconds since 1/1/1970 UTC time)
+
+<flags> = letter codes to indicate details of the key, if any. Flags
+ may be in any order.
+
+ r == revoked
+ d == disabled
+ e == expired
+
+Following the "pub" line are one or more "uid" lines to indicate user
+IDs on the key:
+
+uid:<escaped uid string>:<creationdate>:<expirationdate>:<flags>
+
+<escaped uid string> == the user ID string, with HTTP %-escaping for
+ anything that isn't 7-bit safe as well as for
+ the ":" character. Any other characters may
+ be escaped, as desired.
+
+creationdate, expirationdate, and flags mean the same here as before.
+The information is taken from the self-sig, if any, and applies to the
+user ID in question, and not to the key as a whole.
+
+Details:
+
+* All characters except for the <escaped uid string> are
+ case-insensitive.
+
+* Obviously, on a keyserver without integrated crypto, many of the
+ items given here are not fully trustworthy until the key is
+ downloaded and signatures checked. For example, the information
+ that a key is flagged "r" for revoked should be treated as
+ untrustworthy information until the key is checked on the client
+ side.
+
+* Empty fields are allowed. For example, a key with no expiration
+ date would have the <expirationdate> field empty. Also, a keyserver
+ that does not track a particular piece of information may leave that
+ field empty as well. I expect that the creation and expiration
+ dates for user IDs will be left empty in current keyservers. Colons
+ for empty fields on the end of each line may be left off, if
+ desired.