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 003: Timestamp aware merge strategy
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 003: Timestamp aware merge strategy
Matija Nalis edited this page 2025-11-04 05:35:56 +01:00
Table of Contents

See also #136 and #270

Motivation

Currently, when a keyserver receives an updated version of a public key, the component packets are simply concatenated and deduplicated. This means that the size of a key can only ever grow, and it is not generally possible for even the key owner to remove unwanted third-party signatures, resulting in a DoS vector.

It is generally accepted that a key owner should be able to control the form of their key that is returned from keyservers. This proposal attempts to address the issue entirely through internal changes to keyserver operation.

Examples of interactions

A key owner can update their public key by adding a new self-signature. If they submit this updated key to a modified keyserver, only the third-party sigs on the submitted copy of the key will be retained. This change will automatically propagate across all synchronising keyservers that implement the modified merge strategy, assuming that such servers form a connected graph.

Design

The keyserver merge strategy is changed to the following:

  1. Each key is examined to discover the timestamp of the most recent self-signature on that key.
  2. If the timestamps are identical, no further processing is performed and the version of the key currently on disk is retained.
  3. If the timestamps differ, the key with the older latest-timestamp is stripped of all its third-party sigs, after which the keys are merged.

If a direct revocation signature exists on the primary key, it is treated as more recent than any other self-signature. This is necessary so that escrowed revocations propagate as expected.

Out of scope

This proposal is compatible with first-party approved third-party certifications as described in the draft RFC and implemented in some client software. The difference is that 1pa3pc relies on an explicit statement by the key owner, whereas this proposal infers the same intent from the structure of the key with the latest self-signature. Since 1pa3pc is implemented by a self-sig this proposal would in most cases result in the same behaviour as 1pa3pc, even if 1pa3pc were not explicitly implemented.

Security considerations

It is possible in principle for a race condition to occur whereby different versions of the same key with the same latest timestamp are submitted to the keyserver network at similar times. This could be abused by an attacker to prevent the propagation of third-party sigs that the key owner intended to be distributed. If this were to occur, the key owner must add a new self-sig and republish in order to distribute the correct set of third-party sigs. Such an attack would be of limited use, and given the timescales involved is unlikely to be cost-effective.

Restricting the distribution of third-party sigs may also restrict the distribution of revocations of those sigs, which is undesirable. See HIP 4 for a possible solution (note that this concern also applies to 1pa3pc).

Compatibility

This will result in failure to recon completely with keyservers using a different merge strategy. It will therefore break compatibility with sks-keyserver and older versions of Hockeypuck. However, it should be noted that there is in principle no solution to the sig-spam problem that does not involve a breaking change of similar impact.

If implemented in combination with HIP 2, the above should effectively eliminate third-party sig spam, and if HIP 5 were also implemented, HIP 1 would be obsolete.

See also http://ru.iiec.unam.mx/5728/1/goodit.pdf