openpgp D. Gillmor
Internet-Draft ACLU
Intended status: Informational April 04, 2019
Expires: October 6, 2019

Abuse-Resistant OpenPGP Keystores


OpenPGP transferable public keys are composite certificates, made up of primary keys, user IDs, identity certifications (“signature packets”), subkeys, and so on. They are often assembled by merging multiple certificates that all share the same primary key, and distributed in public keystores.

Unfortunately, since any third-party can add certifications with any content to any OpenPGP certificate, the assembled/merged form of a certificate can become unwieldy or undistributable.

This draft documents techniques that an archive of OpenPGP certificates can use to mitigate the impact of these third-party certificate flooding attacks.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on October 6, 2019.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

1.1. Requirements Language

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.2. Terminology

2. Problem Statement

Many public keystores (including both the [SKS] keyserver network and [MAILVELOPE-KEYSERVER]) allow anyone to attach arbitrary data (in the form of third-party certifications) to any certificate, bloating that certificate to the point of being impossible to effectively retrieve. For example, some OpenPGP implementations simply refuse to process certificates larger than a certain size.

This kind of Denial-of-Service attack makes it possible to make someone else’s certificate unretrievable from the keystore, preventing certificate discovery. It also makes it possible to swamp a certificate that has been revoked, preventing certificate update, potentially leaving the client of the keystore with the compromised certificate in an unrevoked state locally.

Additionally, even without malice, OpenPGP certificates can potentially grow without bound.

The rest of this document describes some mitigations that can be used by keystores that are concerned about these problems but want to continue to offer some level of service for certificate discovery, certificate update, or certificate validation.

3. Simple Mitigations

These steps can be taken by any keystore that wants to avoid obviously malicious abuse. They can be implemented on receipt of any new packet, and are based strictly on the structure of the packet itself.

3.1. Limited Packet Sizes

While [RFC4880] permits OpenPGP packet sizes of arbitrary length, OpenPGP certificates rarely need to be so large. An abuse-resistant keystore SHOULD reject any OpenPGP packet larger than 8383 octets. (This cutoff is chosen because it guarantees that the packet size can be represented as a one- or two-octet [RFC4880] “New Format Packet Length”, but it could be reduced further)

This may cause problems for user attribute packets that contain large images, but it’s not clear that these images are concretely useful in any context. Some keystores MAY extend this limit for user attribute packets specifically, but SHOULD NOT allow even user attributes packets larger than 65536 octets.

3.2. Strict User IDs

[RFC4880] indicates that User IDs are expected to be UTF-8 strings. An abuse-resistant keystore MUST reject any user ID that is not valid UTF-8.

Some abuse-resistant keystores MAY only accept User IDs that meet even stricter conventions, such as an [RFC5322] name-addr or addr-spec, or a URL like “ssh://”.

As simple text strings, User IDs don’t need to be nearly as long as any other packets. An abuse-resistant keystore SHOULD reject any user ID packet larger than 1024 octets.

3.3. Drop or Standardize Unhashed Subpackets

[RFC4880] signature packets contain an “unhashed” block of subpackets. These subpackets are not covered by any cryptographic signature, so they are ripe for abuse.

An abuse-resistant keysetore SHOULD strip out all unhashed subpackets.

Note that some certifications only identify the issuer of the certification by an unhashed Issuer ID subpacket. If a certification’s hashed subpacket section has no Issuer ID or Issuer Fingerprint (see [I-D.ietf-openpgp-rfc4880bis]) subpacket, then an abuse-resistant keystore that has cryptographically validated the certification SHOULD make the unhashed subpackets contain only a single subpacket. That subpacket should be of type Issuer Fingerprint, and should contain the fingerprint of the issuer.

A special exception may be made for unhashed subpackets in a third-party certification that contain attestations from the certificate’s primary key as described in Section 6.

3.4. Drop User Attributes

Due to size concerns, some abuse-resistant keystores MAY choose to ignore user attribute packets entirely, as well as any certifications that cover them.

3.5. Drop Non-exportable Certifications

An abuse-resistant keystore MUST NOT accept any certification that has the “Exportable Certification” subpacket present and set to 0. While most keystore clients will not upload these “local” certifications anyway, a reasonable public keystore that wants to minimize data has no business storing or distributing these certifications.

3.6. Accept Only Cryptographically-verifiable Certifications

An abuse-resistant keystore that is capable of doing cryptographic validation MAY decide to reject certifications that it cannot cryptographically validate.

This may mean that the keystore rejects some packets while it is unaware of the public key of the issuer of the packet.

3.7. Accept Only Profiled Certifications

An aggressively abuse-resistant keystore MAY decide to only accept certifications that meet a specific profile. For example, it MAY reject certifications with unknown subpacket types, unknown notations, or certain combinations of subpackets. This can help to minimize the amount of room for garbage data uploads.

Any abuse-resistant keystore that adopts such a strict posture should clearly document what its expected certificate profile is, and should have a plan for how to extend the profile if new types of certification appear that it wants to be able to distribute.

4. Contextual Mitigations

The following mitigations may cause some packets to be dropped after the keystore receives new information, or as time passes. This is entirely reasonable for some keystores, but it may be surprising for any keystore that expects to be append-only (for example, some keyserver synchronization techniques may expect this property to hold).

Note also that many of these mitigations depend on cryptographic validation.

A keystore that needs to be append-only, or which cannot perform cryptographic validation MAY omit these mitigations.

Note that [GnuPG] anticipates some of these suggestions with its “clean” subcommand, which is documented as:

Compact  (by  removing all signatures except the selfsig)
any user ID that is no longer usable  (e.g.  revoked,  or
expired). Then, remove any signatures that are not usable
by the trust calculations.   Specifically,  this  removes
any  signature that does not validate, any signature that
is superseded by a later signature,  revoked  signatures,
and signatures issued by keys that are not present on the

4.1. Drop Superseded Signatures

An abuse-resistant keystore SHOULD drop all signature packets that are explicitly superseded. For example, there’s no reason to retain or distribute a self-sig by key K over User ID U from 2017 if the keystore have a cryptographically-valid self-sig over <K,U> from 2019.

Note that this covers both certifications and signatures over subkeys, as both of these kinds of signature packets may be superseded.

Getting this right requires a nuanced understanding of subtleties in [RFC4880] related to timing and revocation.

4.2. Drop Expired Signatures

If a signature packet is known to only be valid in the past, there is no reason to distribute it further. An abuse-resistant keystore with access to a functionally real-time clock SHOULD drop all certifications and subkey signature packets with an expiration date in the past.

Note that this assumes that the keystore and its clients all have roughly-synchronized clocks. If that is not the case, then there will be many other problems!

4.3. Drop Dangling User IDs, User Attributes, and Subkeys

If enough signature packets are dropped, it’s possible that some of the things that those signature packets cover are no longer valid.

An abuse-resistant keystore which has dropped all certifications that cover a User ID SHOULD also drop the User ID packet.

Note that a User ID that becomes invalid due to revocation MUST NOT be dropped, because the User ID’s revocation signature itself remains valid, and needs to be distributed.

A primary key with no User IDs and no subkeys and no revocations MAY itself also be removed from distribution, though note that the removal of a primary key may make it impossible to cryptographically validate other certifications held by the keystore.

4.4. Drop All Other Elements of a Directly-Revoked Certificate

If the primary key of a certiifcate is revoked via a direct key signature, an abuse-resistant keystore SHOULD drop all the rest of the associated data (user IDs, user attributes, and subkeys, and all attendant certifications and subkey signatures). This defends against an adversary who compromises a primary key and tries to flood the certificate to hide the revocation.

Note that the direct key revocation signature MUST NOT be dropped.

In the event that an abuse-resistant keystore is flooded with direct key revocation signatures, it should retain the strongest, earliest revocation.

In particular, if any of the revocation signatures has a “Reason for Revocation” of “Key material has been compromised”, the keystore SHOULD retain the earliest such revocation signature (by signature creation date).

If none have “Key material has been compromised”, but some have “No reason specified”, or lack a “Reason for Revocation” entirely, then the keystore SHOULD retain the earliest such revocation signature.

Otherwise, the abuse-resistant keystore SHOULD retain the earliest direct key revocation signature it has seen.

If any of the date comparisons results in a tie between two revocation signatures of the same severity, an abuse-resistant keystore SHOULD retain the signature that sorts earliest based on a binary string comparison of the signature packet itself.

4.5. Implicit Expiration Date

A particularly aggressive abuse-resistant keystore MAY choose an implicit expiration date for all signature packets. For example, a signature packet that claims no expiration could be treated by the keystore as expiring 3 years after issuance.

FIXME: it’s not clear what should happen with signature packets marked with an explicit expiration that is longer than implicit maximum. Should it be capped to the implicit date, or accepted?

Warning: This idea is pretty radical, and it’s not clear what it would do to an ecosystem that depends on such a keystore. It probably needs more thinking.

5. First-party-only Keystores

In addition to all of the mitigations above, some keystores may resist abuse by declining to carry third-party certifications entirely.

A first-party-only keystore only accepts and distributes cryptographically-valid first-party certifications. Given a primary key that the keystore understands, it will only attach user IDs that have a valid self-sig, and will only accept and re-distribute subkeys that are also cryptographically valid (including requiring cross-sigs for signing-capable subkeys as recommended in [RFC4880]).

This effectively solves the problem of abusive bloating attacks on any certificate, because the only party who can make a certificate overly large is the holder of the secret corresponding to the primary key itself.

However, first-party-only keystores also introduce new problems, for those people who rely on the keystore for discovery of third-party certifications. Section 6 attempts to address this lack.

6. First-party-attested Third-party Certifications

We can augment a first-party-only keystore to allow it to distribute third-party certifications as long as the first-party has signed off on the specific third-party certification.

An abuse-resistant keystore SHOULD only accept a third-party certification if it meets the following criteria:

What this means is that a third-party certificate will only be accepted/distributed by the keystore if:

FIXME: it’s not clear whether the “ksok” notification is necessary – it’s in place to avoid some accidental confusion with any other use of the Third-Party Confirmation signature packet type, but the author does not know of any such use that might collide.

6.1. Key Server Preferences “No-modify”

[RFC4880] section (“Key Server Preferences”) defines a “No-modify” bit. That bit has never been respected by any keyserver implementation that the author is aware of. This section effectively asks an abuse-resistant keystore to treat that bit as always set, whether it is present in the certificate or not.

6.2. Client Interactions

The multi-stage layer of creating such an attestation (certificate creation by the first-party, certification by the third-party, attestation by the first-party, then handoff to the keystore) may represent a usability obstacle to a user who needs a third-party-certified OpenPGP certificate.

No current OpenPGP client can easily create the attestions described in this section. More implementation work needs to be done to make it easy (and understandable) for a user to perform this kind of attestation.

7. Side Effects and Ecosystem Impacts

7.1. Designated Revoker

A first-party-only keystore might decline to distribute revocations made by the designated revoker. This is a risk to certificate-holder who depend on this mechanism. Perhaps this document should be amended to include these

7.2. Certification-capable Subkeys

Much of this discussion assumes that primary keys are the only certification-capable keys in the OpenPGP ecosystem. Some proposals have been put forward that assume that subkeys can be marked as certification-capable. If subkeys are certification-capable, then much of the reasoning in this draft becomes much more complex, as subkeys themselves can be revoked by their primary key without invalidating the key material itself. That is, a subkey can be both valid (in one context) and invalid (in another context) at the same time. So questions about what data can be dropped are much fuzzier.

The author of this draft recommends not considering any subkeys to be certification-capable to avoid this headache.

8. Security Considerations

These mitigations defend individual OpenPGP certificates against bloating attacks. They collectively reduce the amount of data that such a keystore needs to track over time, but given the near-infinite space of possible OpenPGP keys that can be generated, the keystore in aggregate can still be made to grow without bound. This document proposes no clear measures to defend against such a denial of service attack against the keystore itself.

Section 7.1 describes a potentially

TODO (more security considerations)

9. Privacy Considerations

Public OpenPGP keystores often distribute names or e-mail addresses of people. Some people do not want their names or e-mail addresses distributed in a public keystore, or may change their minds about it at some point. Append-only keystores are particularly problematic in that regard. The mitigation in Section 4.4 can help such users strip their details from keys that they control. However, if an OpenPGP certificate with their details is uploaded to a keystore, but is not under their control, it’s unclear what mechanisms can be used to remove the certificate that couldn’t also be exploited to take down an otherwise valid certificate.

Third-party certifications effectively map out some sort of social graph. While the certifications basically only assert a binding between user IDs, the parties those user IDs represent in the real world, and cryptographic key material, those connections may be potentially sensitive, and users may not want to see these maps built.

TODO (more privacy considerations)

10. User Considerations

Section 6.2 describes some outstanding work that needs to be done to help users understand how to produce and distribute a third-party-certified OpenPGP certificate to an abuse-resistant keystore.

11. IANA Considerations

This document asks IANA to register the “ksok” notation name in the OpenPGP Notation IETF namespace, with a reference to this document, as defined in Section 6.

12. Document Considerations

[ RFC Editor: please remove this section before publication ]

This document is currently edited as markdown. Minor editorial changes can be suggested via merge requests at or by e-mail to the author. Please direct all significant commentary to the public IETF OpenPGP mailing list:

13. References

13.1. Normative References

[I-D.ietf-openpgp-rfc4880bis] Koch, W., carlson, b., Tse, R. and D. Atkins, "OpenPGP Message Format", Internet-Draft draft-ietf-openpgp-rfc4880bis-06, November 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D. and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

13.2. Informative References

[GnuPG] Koch, W., "Using the GNU Privacy Guard", n.d..
[I-D.koch-openpgp-webkey-service] Koch, W., "OpenPGP Web Key Directory", Internet-Draft draft-koch-openpgp-webkey-service-07, November 2018.
[] Shaw, D., "The OpenPGP HTTP Keyserver Protocol (HKP)", Internet-Draft draft-shaw-openpgp-hkp-00, March 2003.
[MAILVELOPE-KEYSERVER] Oberndörfer, T., "Mailvelope Keyserver", n.d..
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008.
[RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP", RFC 7929, DOI 10.17487/RFC7929, August 2016.
[SKS] Pennock, P., "SKS Keyserver Documentation", March 2018.

Author's Address

Daniel Kahn Gillmor American Civil Liberties Union 125 Broad St. New York, NY, 10004 USA EMail: