{{#> layout }}
Hagrid implements both the legacy HKP interface, as well as our native interface, VKS.
Hagrid has its own URL scheme to fetch keys.
Retrieves the key with the given Fingerprint.
The Fingerprint may refer to the primary key, or any subkey.
Hexadecimal digits MUST be uppercase,
and MUST NOT be prefixed with 0x
.
The returned key is ASCII Armored, and has a content-type of application/pgp-keys
.
Retrieves the key with the given long KeyID.
The KeyID may refer to the primary key, or any subkey.
Hexadecimal digits MUST be uppercase,
and MUST NOT be prefixed with 0x
.
The returned key is ASCII Armored, and has a content-type of application/pgp-keys
.
Retrieves the key with the given E-Mail Address.
Only exact matches are accepted.
Lookup by e-mail address requires opt-in by the key's owner.
The returned key is ASCII Armored, and has a content-type of application/pgp-keys
.
A single key may be submitted using a POST request to /vks/v1/upload.
The body of the request must be application/json
.
The JSON data must contain a single field keytext
,
which must contain the keys to submit.
The value of keytext
can be formatted in standard OpenPGP ASCII Armor, or base64.
The returned JSON data
contains the fields token
, key_fpr
,
and status
.
The token
field contains an opaque value,
which can be used to perform request-verify requests
(see below).
The key_fpr
field contains the fingerprint of the uploaded primary key.
The status
token contains a map of email addresses
contained in the key, with one of the values
unpublished
,
published
,
revoked
, or
pending
,
indicating the status of this e-mail address.
{ "keytext": "<ASCII ARMORED KEY>" }
{ "key_fpr": "<FINGERPRINT>" "status": { "address@example.org": "unpublished" }, "token": "..." }
A key that has been uploaded can be made discoverable by one or more of its e-mail addresses by proving ownership of the address via a verification e-mail. This endpoint requests verification for one or more e-mail addresses.
The body of the request must be application/json
.
The JSON data must include the opaque token
value
(obtained via /vks/v1/upload)
and an addresses
field,
which is a list of e-mail addresses (not full User IDs)
to request verification mails for.
It can optionally include a locale
field,
which is list of locales,
ordered by preference,
which to use for the verification e-mail.
The reply will be the same as for the /vks/v1/upload endpoint,
with addresses marked as pending
where a verification email
has been sent.
{ "token": "...", "addresses": [ "address@example.org" ] "locale": [ "de_CH", "de_DE" ] }
{ "key_fpr": "<FINGERPRINT>" "status": { "address@example.org": "pending" }, "token": "..." }
Hagrid implements a subset of the HKP protocol so that tools like GnuPG and OpenKeychain can use it without modification.
Returns an ASCII Armored key matching the query. Query may be:
localpart@example.org
.069C0C348DD82C19
, optionally prefixed by 0x
).
8E8C33FA4626337976D97978069C0C348DD82C19
,
optionally prefixed by 0x
).
Note that while the hexadecimal digits may use either case, using upper case letters is slightly more efficient with Hagrid.
Returns a machine-readable list of keys matching the query. Query may have the forms detailed above. Hagrid always returns either one or no keys at all.
Keys may be submitted using a POST request to /pks/add,
the body of the request being
a application/x-www-form-urlencoded
query.
keytext
must be the keys to submit,
which must be ASCII Armored.
More than one key may be submitted in one request.
For verification of e-mail addresses,
the /vks/v1/upload endpoint
must be used instead.
By design, Hagrid does not implement the full HKP protocol. The specific limitations are:
op=vindex
,exact=on
is
always assumed),fingerprint
variable is ignored,nm
option is ignored,op=index
returns either one or no keys,