mirrors/hockeypuck
1
0
Fork 0
mirror of https://github.com/hockeypuck/hockeypuck.git synced 2025-12-17 08:55:43 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
Page: HIP 007: Recursive resolver
Pages
HIP 000: Hockeypuck Improvement Proposals HIP 001: [REVERTED] Regaining control over public key identity with authenticated key management HIP 002: SKS v2 protocol HIP 003: Timestamp aware merge strategy HIP 004: Third party revocation sig distribution HIP 005: Reliable personal data deletion using self signatures HIP 006: WKD support HIP 007: Recursive resolver HIP 008: Out of Band Email Ownership Proof HIP 009: Management Interface HIP 010: Internal rate limiting support HIP 011: Merge ptree into pghkp HIP 012: Define and use JSON‐LD schemas HIP 013: In‐Band Metadata Sync Using Trust Packets Home Migrating from SKS‐keyserver to Hockeypuck Semantic Versioning Policy Upgrading docker‐compose standalone deployment from 2.1 to 2.2
2 HIP 007: Recursive resolver
Andrew Gallagher edited this page 2025-04-24 10:24:22 +01:00
Table of Contents

We wish to allow site admins to run a private hockeypuck service for their users without having to peer with public servers. We also would like to be able to find keys that have not been directly published on the SKS keyserver network. This can be done if we implement a recursive resolver (caching proxy) along the lines of DNS.

Motivation

With the breakdown of sync, and the proliferation of keystore models, publishing a key is no longer a sufficient guarantee of visibility:

  • WKD is controlled by the domain owner and is not suitable for, or not available to, all users
  • keys.openpgp.org does not serve third-party signatures, and does not federate
  • keys.mailvelope.com, api.protonmail.ch, etc. are service-provider specific and don't federate
  • keyserver.ubuntu.com no longer federates with other SKS servers

In addition, users may not wish to disclose their interest in a given key to the chosen keystore provider of their recipient. A (trusted) recursive resolver would provide an extra layer of anonymity in such cases.

Examples of interactions

  • A user who searches for a key that is not in a recursive keyserver's database should have their query proxied to other keystores.
  • A key published to a recursive keyserver should (optionally) be published to other keystores.

Design

A recursive keyserver MAY implement the following:

  • If there is no result for a client query in the local database, the query should be forwarded to a configurable list of upstream keystores
  • The proxied query should contain a query parameter to prevent looping
  • Any results obtained should be returned to the client, and added to a local cache
  • The cache should be refreshed via a parcimonie algorithm, and eventually expired
  • If a "preferred keyserver" subpacket exists, it should be polled for updates
  • The provenance of a cached key should be displayed in the index view

A recursive keyserver MAY also implement the following:

  • Whenever a key is uploaded to the keyserver, it is forwarded to a configurable list of downstream keystores

The downstream list will in general be different from the list of upstream keystores

Out of scope

Long-term storage of recursively-obtained data.

Security and privacy considerations

Scraping keys from other keystores and storing them indefinitely may violate terms of service and data protection norms. A time-limited cache mitigates this concern by acting as a proxy rather than a republisher.

Compatibility

This functionality could be implemented as a standalone product, with a hockeypuck server as an upstream and/or downstream keystore, however this would be more complex to deploy, particularly for small operators.