hagrid-keyserver--hagrid/dist/templates/about/api.html.hbs

{{#> layout }}
<div class="about">
    <center><h2><a href="/about">About</a> | <a href="/about/usage">Usage</a> | <a href="/about/faq">FAQ</a> | <a href="/about/privacy">Privacy Policy</a> | API</h2></center>

  <p>
    Hagrid implements both the legacy HKP interface, as well as our
    native interface, VKS.
  </p>

  <h2>Verifying Keyserver (VKS) Interface</h2>

  <p>Hagrid has its own URL scheme to fetch keys.</p>

  <ul>
    <li>
      <tt>GET /vks/v1/by-fingerprint/&lt;FINGERPRINT&gt;</tt>
      <p>
        Retrieves the key with the given <tt>Fingerprint</tt>.
        The <tt>Fingerprint</tt> may refer to the primary key, or any subkey.
        Hexadecimal digits MUST be uppercase,
        and MUST NOT be prefixed with <code>0x</code>.
        The returned key is ASCII Armored, and has a content-type of <code>application/pgp-keys</code>.
      </p>
    </li>

    <li>
      <tt>GET /vks/v1/by-keyid/&lt;KEY-ID&gt;</tt>
      <p>
        Retrieves the key with the given long <tt>KeyID</tt>.
        The <tt>KeyID</tt> may refer to the primary key, or any subkey.
        Hexadecimal digits MUST be uppercase,
        and MUST NOT be prefixed with <code>0x</code>.
        The returned key is ASCII Armored, and has a content-type of <code>application/pgp-keys</code>.
      </p>
    </li>

    <li>
      <tt>GET /vks/v1/by-email/&lt;URI-ENCODED EMAIL-ADDRESS&gt;</tt>
      <p>
        Retrieves the key with the given <tt>E-Mail Address</tt>.
        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 <code>application/pgp-keys</code>.
      </p>
    </li>

    <li>
      <tt>POST /vks/v1/upload</tt>
      <p>
        A single key may be submitted using a POST request to <tt>/vks/v1/upload</tt>.
        The body of the request must be <code>application/json</code>.
        The JSON data must contain a single field <code>keytext</code>,
        which must contain the keys to submit.
        The value of <code>keytext</code> can be formatted in standard OpenPGP ASCII Armor, or base64.
      </p>

      <p>
        The returned JSON data
        contains the fields <code>token</code>, <code>key_fpr</code>,
        and <code>status</code>.
        The <code>token</code> field contains an opaque value,
        which can be used to perform <tt>request-verify</tt> requests
        (see below).
        The <code>key_fpr</code> field contains the fingerprint of the uploaded primary key.
        The <code>status</code> token contains a map of email addresses
        contained in the key, with one of the values
        <code>unpublished</code>,
        <code>published</code>,
        <code>revoked</code>, or
        <code>pending</code>,
        indicating the status of this e-mail address.
      </p>

      <div class="example">
        <div>
          Example request:
          <pre>
{
  "keytext": "&lt;ASCII ARMORED KEY&gt;"
}
          </pre>
        </div>
        <div>
          Example response:
          <pre>
{
  "key_fpr": "&lt;FINGERPRINT&gt;"
  "status": {
    "address@example.org": "unpublished"
  },
  "token": "..."
}
          </pre>
        </div>
      </div>
    </li>

    <li>
      <tt>POST /vks/v1/request-verify</tt>
      <p>
        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.
      </p>
      <p>
        The call must include the opaque <code>token</code> value
        (obtained via <tt>/vks/v1/upload</tt>)
        and an <code>addresses</code> field,
        which is a list of e-mail addresses (not full User IDs)
        to request verification mails for.
        It can optionally include a <code>locale</code> 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 <tt>/vks/v1/upload</tt> endpoint,
        with addresses marked as <code>pending</code> where a verification email
        has been sent.
      </p>

      <div class="example">
        <div>
          Example request:
          <pre>
{
  "token": "...",
  "addresses": [
    "address@example.org"
  ]
  "locale": [ "de_CH", "de_DE" ]
}
          </pre>
        </div>
        <div>
          Example response:
          <pre>
{
  "key_fpr": "&lt;FINGERPRINT&gt;"
  "status": {
    "address@example.org": "pending"
  },
  "token": "..."
}
          </pre>
        <div>
        </div>
      </div>
    </li>
  </ul>

  <h2>HTTP Keyserver Protocol (HKP) Interface</h2>
  <p>
    Hagrid implements a subset of
    the <a href="https://tools.ietf.org/html/draft-shaw-openpgp-hkp-00">HKP</a>
    protocol so that tools like GnuPG and OpenKeychain can use it
    without modification.
  </p>

  <ul>
    <li>
      <tt>GET /pks/lookup?op=get&amp;options=mr&amp;search=&lt;QUERY&gt;</tt>

      <p>Returns an ASCII Armored key matching the query.  Query may be:</p>

      <ul>
        <li>An exact email address query of the form <code>localpart@example.org</code>.</li>
        <li>
          A hexadecimal representation of a long <tt>KeyID</tt> of either a primary
          key, or a subkey (<code>069C0C348DD82C19</code>, optionally prefixed by <code>0x</code>).
        </li>
        <li>
          A hexadecimal representation of a <tt>Fingerprint</tt> of either a primary
          key, or a subkey (<code>8E8C33FA4626337976D97978069C0C348DD82C19</code>,
          optionally prefixed by <code>0x</code>).
        </li>
      </ul>

      <p>
        Note that while the hexadecimal digits may use either case, using
        upper case letters is slightly more efficient with Hagrid.
      </p>
    </li>

    <li>
      <tt>GET /pks/lookup?op=index&amp;options=mr&amp;search=&lt;QUERY&gt;</tt>
      <p>
        Returns
        a <a href="https://tools.ietf.org/html/draft-shaw-openpgp-hkp-00#section-5.2">machine-readable
        list</a> of keys matching the query.  Query may have the forms
        detailed above.  Hagrid always returns either one or no keys at
        all.
      </p>
    </li>

    <li>
      <tt>POST /pks/add</tt>

      <p>
        Keys may be submitted using a POST request to <tt>/pks/add</tt>,
        the body of the request being
        a <code>application/x-www-form-urlencoded</code> query.
        <code>keytext</code> 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 <tt>/vks/v1/upload</tt> endpoint
        must be used instead.
      </p>
    </li>
  </ul>

  <h4>Limitations</h4>

  <p>
    By design, Hagrid does not implement the full HKP protocol.  The specific
    limitations are:
  </p>

  <ul>
    <li>No support for <code>op=vindex</code>,</li>
    <li>only exact matches for user IDs are returned (i.e. <code>exact=on</code> is
      always assumed),</li>
    <li>the <code>fingerprint</code> variable is ignored,</li>
    <li>the <code>nm</code> option is ignored,</li>
    <li><code>op=index</code> returns either one or no keys,</li>
    <li>uploads are restricted to 1 MiB,</li>
    <li>all packets that aren't public keys, user IDs or signatures are filtered out.</li>
  </ul>

</div>
{{/layout}}