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 006: WKD support
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
HIP 006: WKD support
Andrew Gallagher edited this page 2025-03-28 15:27:58 +00:00
Table of Contents

(Note that this may no longer be required if we are migrating to HKP-based key discovery, as per the latest HKP draft)

If Hockeypuck exposed a WKD endpoint, domain owners could use hockeypuck instead of other WKD implementations that lack sufficient features.

Motivation

Other solutions for managing WKD lack features:

  • hagrid does not serve third-party signatures
  • gnupg-wks-server does not make it easy for admins to publish keys on behalf of users, and is not well supported by clients
  • openpgpkey-control does not allow users to publish their own keys

Examples of interactions

  • A key owner would publish their key via HKPS as normal
  • A client would request a key via WKD, and hockeypuck would serve the key material from its own database (if sufficient conditions were met, see below)

Design

A domain owner could configure WKD support for her domain, in which case hockeypuck would:

  1. accept WKD requests on the /.well-known/openpgpkey/$DOMAIN/hu/ endpoint
  2. discard the file part and process the query string ?l=$LOCALPART
  3. perform a userID lookup for $LOCALPART@$DOMAIN
  4. strip all userIDs apart from the one in the query
  5. restrict the results to those matching one or more validation filters
  6. restrict the results to those matching one or more protocol filters
  7. sort the results
  8. serve the results in binary format

Initially, there would be only one validation filter:

  • the userID has a valid third-party signature made by a trusted key (must be given as a fingerprint, and defaults to the server contact)

This could be extended in the future to include other validation methods such as email challenge/response.

Initially, there would be two protocol filters:

  • the key is revoked
  • the key is the most recently-created currently-valid one in the list of results

These could be relaxed if a future version of WKD allowed for more than one non-revoked key to be returned.

Results should be sorted so that the non-revoked key appears first.

Out of scope

  • We don't want to support WKD lookups for arbitrary domains, like KOO; only support for admin-controlled domains will be implemented.

Security considerations

WKD is generally given a higher trust value than HKPS, since it is assumed that the WKD domain admin has control over which keys are published. We must therefore ensure that nothing is served via WKD without a suitable validation, e.g.:

  • UserID certification signature by a trusted party
  • submission or update via access-controlled admin interface
  • email challenge/response

Compatibility

  • No changes to existing behaviour are required.
  • The WKD endpoint should conform to the current WKD draft.