| Internet-Draft | OpenPGP 1PA3PC | September 2024 |
| Gillmor | Expires 10 March 2025 | [Page] |
An OpenPGP certificate can grow in size without bound when third-party certifications are included. This document describes a way for the owner of the certificate to explicitly approve of specific third-party certifications, so that relying parties can safely prune the certificate of any unapproved certifications.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://dkg.gitlab.io/openpgp-1pa3pc/. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-dkg-openpgp-1pa3pc/.¶
Discussion of this document takes place on the OpenPGP Working Group mailing list (mailto:[email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/openpgp/. Subscribe at https://www.ietf.org/mailman/listinfo/openpgp/.¶
Source for this draft and an issue tracker can be found at https://gitlab.com/dkg/openpgp-1pa3pc.¶
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 https://datatracker.ietf.org/drafts/current/.¶
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 10 March 2025.¶
Copyright (c) 2024 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 (https://trustee.ietf.org/license-info) 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
In some cases, it is useful to have a third-party certification over an identity in an OpenPGP certificate. However, if an OpenPGP certificate simply merges in all third-party certifications, the certificate can grow in size to the point where it is impossible to use or transfer. See, for example, the discussion about "certificate flooding" in Section 2.1 of [I-D.dkg-openpgp-abuse-resistant-keystore].¶
If the owner of an OpenPGP certificate (the "keyholder") wants their own certificate to be usable by others, they can explicitly indicate which third-party certifications they approve of, and implicitly decline the rest.¶
The term "OpenPGP Certificate" is used in this document interchangeably with "OpenPGP Transferable Public Key", as defined in Section 10.1 of [RFC9580].¶
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.¶
This specification defines a new signature type, a new signature subpacket type, and extends the structure of an OpenPGP certificate.¶
This document defines a new key signature type used only in OpenPGP certificates known as a Certification Approval Key Signature. The Signature type ID is 0x16.¶
This signature is issued by the primary key over itself and its User ID (or User Attribute). It MUST contain exactly three subpackets in its hashed subpackets:¶
a "Signature Creation Time" subpacket (Section 5.2.3.11 of [RFC9580])¶
an Issuer Fingerprint subpacket (see Section 5.2.3.35 of [RFC9580])¶
an "Approved Certifications" subpacket (see Section 2.2)¶
This type of key signature does not replace or override any standard certification (0x10-0x13).¶
Only the most recent self-signed Certification Approval Key Signature is valid for any given <key,userid> pair. If more than one valid, self-signed Certification Approval Key Signature is present with the same Signature Creation Time, the set of approvals should be treated as the union of all "Approved Certifications" subpackets from all such signatures with the same timestamp.¶
An Approval Key Signature is computed over a hash of data in the same way as a Certification Signature. That is, the following items are concatenated into the hash function before signing:¶
This document defines a new signature subpacket named Approved Certifications. Its contents are N octets of certification digests (see more below).¶
This subpacket MUST only appear as a hashed subpacket of an self-signed Certification Approval Key Signature (see Section 2.1). It has no meaning in any other signature type. It is used by the primary key to approve of a set of third-party certifications over the associated User ID or User Attribute. This enables the holder of an OpenPGP primary key to mark specific third-party certifications as re-distributable with the rest of the Transferable Public Key (see the "No-modify" flag in Section 5.2.3.25 of [RFC9580]). Implementations MUST include exactly one Approved Certifications subpacket in any generated Certification Approval Key Signature.¶
The contents of the subpacket consists of a series of digests using the same hash algorithm used by the signature itself. Each digest is made over one third-party signature (any Certification, i.e., signature types 0x10-0x13) that covers the same Primary Key and User ID (or User Attribute). For example, an Certification Approval Key Signature made by key X over User ID U using hash algorithm SHA256 might contain an Approved Certifications subpacket of 192 octets (6*32 octets) covering six third-party certification Signatures over <X,U>. They SHOULD be ordered by binary hash value from low to high (e.g., a hash with hexadecimal value 037a… precedes a hash with value 0392…, etc). The length of this subpacket MUST be an integer multiple of the length of the hash algorithm used for the enclosing Certification Approval Key Signature.¶
The listed digests MUST be calculated over the third-party certification's Signature packet in a process similar to the digest used for a "Third-Party Confirmation signature" (described in Section 5.2.4 of [RFC9580]), but without a trailer. The data hashed starts with the salt (v6 certifications only), followed by the octet 0x88, followed by the four-octet length of the Signature, and then the body of the Signature packet. (Note that this is a Legacy Format packet header for a Signature packet with the length-of-length field set to zero.) The unhashed subpacket data of the Signature packet being hashed is not included in the hash, and the unhashed subpacket data length value is set to zero.¶
If an implementation encounters more than one such subpacket in an Certification Approval Key Signature, it MUST treat it as a single Approved Certifications subpacket containing the union of all hashes.¶
The Approved Certifications subpacket in the most recent self-signed Certification Approval Key Signature over a given User ID supersedes all Approved Certifications subpackets from any previous Certification Approval Key Signature. However, note that if more than one Certification Approval Key Signature packets have the same (most recent) Signature Creation Time subpacket, implementations MUST consider the union of the Approved Certifications of all Certification Approval Key Signatures. This allows the keyholder to approve of more third-party certifications than could fit in a single Certification Approval Key Signature.¶
Note that Certification Revocation Signatures are not relevant for Certification Approval Key Signatures. To rescind all approvals, the primary key holder needs only to publish a more recent Certification Approval Key Signature with an empty Approved Certifications subpacket.¶
The Certification Approval Key Signature appears in an OpenPGP certificate after a User ID or User Attribute packet, mixed in with the certifications that cover that User ID or User Attribute packet.¶
FIXME: test that these do not break existing implementations by causing them to reject a certificate that they otherwise would have accepted. If they do, then we might consider placing this signature in an unhashed Embedded Signature subpacket in the User ID's self-sig.¶
The inclusion of a digest in an Approved Certifications subpacket in a valid, most-recent self-signed Certification Approval Key Signature which matches a specific third-party certification is an indication that the keyholder approves of the third-party certification.¶
There is no need to approve of self-signed certifications. Since they are already made by the primary key, self-signed certifications are implicitly approved.¶
A verifier might observe an approved digest that does not correspond to any Certification that the verifier is aware of. This is normal, because not everyone is guaranteed to have the exact same set of third-party certifications for any given OpenPGP certificate. In such cases, the verifier should ignore the non-matching digest, but MUST NOT ignore other digests in the list of Approved Certifications.¶
This section describes some possible steps for generating and using Approved Certifications.¶
Alice has a new OpenPGP certificate with primary key K, and wants to publish Bob's certification over her User ID in that certificate.¶
Alice sends Bob her certificate, asking for his certification.
Bob performs his normal verification that the User ID and K do indeed belong to Alice, and then creates a certification over her User ID, adding it to the certificate.¶
Bob then sends the augmented certificate back to Alice. Alice reviews the added certification, and decides that she likes it.¶
She chooses a strong hash algorithm H and uses it to compute the digest of Bob's certification.
She places that digest into an Approved Certifications subpacket S.
She also creates a Signature Creation Time subpacket C containing the current timestamp, and an Issuer Fingerprint subpacket F containing the fingerprint of K.¶
Alice places subpackets F, C, and S into an Certification Approval Key Signature packet, and signs it with K using hash algorithm H.¶
If a keyholder Alice has already approved of third-party certifications from Bob and Carol and she wants to additionally approve a certification from David, she should issue a new Certification Approval Key Signature (with a more recent Signature Creation timestamp) that contains an Approved Certifications subpacket covering all three third-party certifications.¶
If she later decides that she does not want Carol's certification to be redistributed with her certificate, Alice can issue a new Certification Approval Key Signature (again, with a more recent Signature Creation timestamp) that contains an Approved Certifications subpacket covering only the certifications from Bob and David.¶
If an abuse-resistant keystore (e.g., an OpenPGP keyserver) receives an OpenPGP certificate for redistribution, it SHOULD strip away all unapproved third-party certifications before redistributing the certificate.¶
If such a keystore receives an updated copy of the certificate which includes a newer Certification Approval Key Signature, it should merge the certificate update with its existing copy of the certificate, and re-apply the new list of approved digests by stripping away all certifications which do not match the new list.¶
This document is intended to make an OpenPGP certificate more manageable by the keyholder.¶
A flooded certificate is difficult or impossible to redistribute, which means that peers of the keyholder cannot easily fetch the certificate, resulting in inability to encrypt messages to or verify signatures from that certificate. An unredistributable certificate can also make it difficult or impossible to transmit revocation, expiration, key rotation, or preference changes associated with the certificate, which interferes with certificate maintenance necessary to securely use OpenPGP.¶
The mechanisms described in this document defend against certificate flooding attacks by enabling certificate redistributors (e.g., keyserver networks or other "keystores") to limit the contents of a certificate to only those elements which the keyholder explicitly approves of and wants included in the certificate.¶
IANA is asked to register multiple objects in the OpenPGP protocol group.¶
The Signature Types registry should add a row with signature type 0x16, Name "Certification Approval Key Signature", and Reference pointing to Section 2.1 in this document.¶
The Signature Subpacket Types registry row with Type 37 should be update with Description "Approved Certifications", and Reference pointing to Section 2.2 in this document.¶
FIXME: Can all of the plausible workflows described in this document be done with the Stateless OpenPGP Interface? Definitely not right now. What is missing?¶
FIXME: This document should include a certificate with third-party certifications, some of which are approved, and others of which are not approved. It should also show the same certificate, but pruned to remove all non-approved third-party certifications.¶
RFC Editor Note: Please delete this section before publication.¶
FIXME: enumerate existing implementations.¶
Demi Marie Obenour, Heiko Stamer, Jan Zerebecki, Justus Winter, Neal Walfield, Orie Steele, Vincent Breitmoser, and others all contributed to specifying and defining this mechanism.¶
RFC Editor Note: Please delete this section before publication.¶
Change terminology from "attest" to "approve"¶