]> American Civil Liberties Union

dkg@fifthhorseman.net

merlinux gmbh

holger@merlinux.eu

n0 Inc.

me@dignifiedquire.com

int openpgp Internet-Draft This document describes the "Autocrypt v2 Certificate", a standard structure for an OpenPGP certificate for Internet messaging. It offers defense against store-now-decrypt-later attacks from quantum computers through post-quantum hybrid cryptography. It also enables reliable deletion ("Forward Secrecy") of received messages even when adversaries capture encrypted messages in transit and later compromise the user's message archive and secret keys. The design uses deterministically ratcheted rotating encryption subkeys with predictable expiration combined with coordinated secret key material destruction. This document also describes the structure, use, and maintenance of the OpenPGP Transferable Secret Key that corresponds with the Autocrypt v2 Certificate. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the OpenPGP Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction An OpenPGP certificate can be structured in a bewildering variety of ways. The "Autocrypt v2 Certificate" is a modern OpenPGP structure that aims toward robustness, cryptographic resilience, and straightforward deployment in the Internet messaging context. An OpenPGP implementation that produces and can handle certificates and secret keys structured in this way can provide the user with reasonable protection against a variety of plausible attacks, while slotting cleanly into existing mechanisms for end-to-end cryptographically protected email and other messaging systems. This mechanism also enables an archiving messenger to support robust deletion of a received message in a way that the deleted message will not be recoverable, even by an adversary who can capture messages in transit, and later compromises the user's message archive and secret keys.

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 when, and only when, they appear in all capitals, as shown here.

Terminology "OpenPGP certificate" or just "certificate" refers to an OpenPGP Transferable Public Key (see ). This specification distinguishes between outgoing certificates as distributed by the keyholder, with a fixed structure and size, and incoming certificates as received and stored by a peer. This specification does not prescribe any particular mechanism for how certificates are transferred between parties. "Transferable Secret Key" or just "TSK" refers to an OpenPGP Transferable Secret Key (see ). "Component key" refers to a single cryptographic object found within an OpenPGP certificate. A certificate's primary key is a "component key", and any subkey in the certificate is also a "component key". "Keyholder" is the party that has legitimate access to the secret key material corresponding to the component keys in a certificate. The keyholder can sign messages that can be verified with the certificate, decrypt messages that were encrypted to the certificate, and update the certificate itself over time. "User Messaging Agent" or UMA refers to a program used to compose, send, receive, and render messages. This term is similar to "Mail User Agent" (MUA), but the variation in naming emphasizes that Autocrypt v2 certificates do not prescribe a specific transport mechanism nor do they prescribe a particular message content format. A Keyholder may have one or more UMAs that share access to the same secret key material, messaging inbox, and other account details. "Peer" means a party who communicates with the keyholder via messages, as well as potentially with other peers. The peer does not have access to the keyholder's asymmetric secret key material, but typically has access to a copy of each message exchanged between the peer and keyholder. "Reliable Deletion" refers to the property that enables a keyholder to render a message unrecoverable after deletion, even if an attacker has archived all messages in transit and subsequently obtains the keyholder's secret key material and message archive. Reliable deletion therefore requires the destruction of both secret key material and message cleartext. This property is commonly referred to as "Forward Secrecy"; however, this specification uses the term "Reliable Deletion" to emphasize the keyholder's ability to permanently delete messages.

Goals A certificate following this specification has the following goals: Post-quantum confidentiality. It should defend against a store-now-decrypt-later attack from a cryptographically relevant quantum computer. Size matters. When network conditions are constrained by limited bandwidth, high latency, or intermittent connectivity, there often is a heightened need for encryption with reliably deletable messages. To preserve availability under such conditions, the size of cryptographic material should be minimized and it should be possible to include transmission of a few dozen certificates in a single message without impairing common messaging infrastructure. Computational resources matter. It should be possible to promptly encrypt a single message to up to a few dozen of these certificates with low-powered devices. The same hardware should be able to quickly and cheaply verify a signature from one of these certificates. And with access to the corresponding secret keys, it should be inexpensive to decrypt a message encrypted to one, or to sign a message with one. Reliable deletion. The keyholder should be able to robustly and permanently delete an encrypted message received some time in the past, rendering it unrecoverable even to a powerful attacker in the future (see ). No network synchronization needed. The keyholder should be able to encrypt and decrypt messages with local key material only, without requiring network synchronization between their own devices or with peers. To the extent that a keyholder has multiple UMAs of their own, each UMA should be able to operate independently with no ongoing network synchronization between them beyond the initial configuration. Backward compatibility. It must be possible for a keyholder with an Autocrypt v1 key to sign a message that is encrypted to an Autocrypt v2 certificate, and vice versa. It must also be possible to encrypt a message to a mixed group of Autocrypt v1 and v2 certificates (though such a message may not meet the "Reliable deletion" goal). Drop-in OpenPGP replacement for existing peers. The keyholder might need to update their OpenPGP implementation, UMA(s), and regular workflow to use the secret key material to meet these goals successfully. But a peer whose UMA supports Autocrypt v1.1 already only needs to update their OpenPGP implementation in order to interoperate. Minimize unnecessary metadata. A certificate of this form need not leak information that the keyholder might consider sensitive. There is no intent to forbid inclusion of sensitive information if the keyholder desires, but the standard certificate should be suitably generic.

Non-Goals This specification does not attempt to accommodate all possible scenarios that might occur with OpenPGP, email, or other messaging systems. The following concerns are explicitly not in-scope for this specification: No support for legacy OpenPGP clients. The keyholder needs to use an up-to-date OpenPGP implementation, and expects their peers to do the same. There is no attempt at backward compatibility for a peer with a legacy OpenPGP implementation. No in-cert human-readable identifiers. There is no attempt to store a “real name" or other human-readable identity information in the certificate. If human-readable identity information is to be associated with the certificate, it is expected to be supplied elsewhere, such as with a local petname system, or some external cryptographic bindings. No in-cert transport-layer addressing. There is no attempt to bind transport-layer routing information (e.g., email addresses) to the certificate. Information about how to get an encrypted message to the keyholder is presumed to be transmitted via some other channel, such as the Autocrypt header field. No defense against quantum impersonation. While the certificate is designed to defend against store-now-decrypt-later attacks, it does not defend against an adversary with a cryptographically relevant quantum computer that breaks the signing key and updates the certificate in order to compromise future messages encrypted to the certificate. Such an attacker must expose themselves to the peer at least (putting the attacker at risk due to visibility), and these attacks cannot take place retroactively. No transitioning from old certs. There is no specific support for transitioning older or alternative OpenPGP certificate formats to the structure defined in this specification. Such a migration path may be defined in future specifications, but this document is limited to new adopters going forward. No certificate discovery and no refresh. This specification does not define a mechanism to request a refreshed certificate from a peer. Reliable message deletion depends on timely updates of each correspondent's certificate, but imposing a particular mechanism is unlikely to accommodate the constraints of diverse messaging implementations. That said, this specification does not preclude the use of discovery or refresh mechanisms. No coordinated deletion of messages. This specification addresses unilateral deletability, protecting against a future attacker who compromises the keyholder's UMA or secret key storage. Messages are typically stored in multiple locations, across peers, devices, and UMAs. Guaranteeing deletion of all copies of a message, including through negotiated “disappearing messages” mechanisms, is outside the scope of this draft. No post-compromise security. Some messaging schemes attempt to defend against an attacker who has compromised the user's secret key material at some point in the past, typically by regularly mixing new entropy into the secret key material and coordinating those updates across the user's shared devices. This specification does not defend against such an attacker. In the case of past key compromise, the user may need to move to an entirely new certificate.

Certificate Structure An Autocrypt v2 certificate is composed of a specific sequence of version 6 OpenPGP packets. The precise requirements for these packets including algorithm IDs, key flags, and binding signatures are detailed in .

Encryption subkey rotation The expiring encryption subkey is rotated on a regular schedule. The window of subkey validity (from creation and binding to expiration) is known as max_rd. When the current subkey has only min_rd time left until expiration, the keyholder adds a new rotating subkey. A rotating subkey N+1 is created exactly at min_rd away from the end of the validity window of rotating subkey N. By convention, max_rd is 10 days (864000 seconds), and min_rd is 5 days (432000 seconds). See for the formal definition and concrete guidance about min_rd and max_rd. In order for the keyholder to use the same TSK across multiple UMAs without explicit network coordination, the values of min_rd and max_rd MUST be known to the keyholder's UMAs. See for more information. This arrangement means the validity window of each subsequent rotating subkey overlaps with the validity window of the prior rotating subkey. See for more discussion about temporal layout of subkey validity windows.

Fixed Creation Timestamp The primary public key and fallback encryption subkey use a fixed, well-known key creation timestamp of 0x6a44587f (1782863999 seconds past the UNIX epoch, which is 2026-06-30T23:59:59Z). This document refers to this special timestamp as T_ac2. The direct key signature over the primary key and the subkey binding signature for the fallback encryption subkey will initially be T_ac2, but MAY be any later time. This allows the keyholder to offer revised metadata in these signatures in a way that a peer can determine which collection of metadata is more recent. This fixed creation timestamp offers two advantages: it avoids publishing the creation time of the primary key (and fallback key), which otherwise would leak unnecessarily, and it offers a reasonably distinct signal that the secret key in question follows this specification, so it can be safely rotated. Historical note: T_ac2 was chosen as the last timestamp congruent with the publication date of in UTC.

Packet Composition An outbound certificate consists of the following six packets: A. "Primary" Public Key Packet (packet type ID 6), version 6, public key algorithm Ed25519 (algorithm ID 27), creation time T_ac2 B. Direct Key Signature (packet type ID 2), version 6, signature type 0x1f, hashed subpackets include: signature creation time (T_ac2 or later) key flags: certify, sign issuer fingerprint (fingerprint of A) features: SEIPDv2 preferred AEAD ciphersuites: AES-256+OCB ## TBD: do we need this? no expiration subpacket C. "Fallback" Public Subkey Packet (packet type 14), version 6, public key algorithm ML-KEM-768+X25519 (algorithm ID 35) (see ), creation time T_ac2 D. Subkey binding signature (packet type ID 2), version 6, signature type 0x18, hashed subpackets include: signature creation time (T_ac2 or later) key flags: encrypt to storage, encrypt to comms issuer fingerprint (fingerprint of A) no expiration subpacket E. "Rotating" Public Subkey Packet (packet type 14), version 6, public key algorithm ML-KEM-768+X25519 (algorithm ID 35) (see ), creation time T_ac2 or later F. Subkey binding signature (packet type ID 2), version 6, signature type 0x18, containing exactly the following four hashed subpackets, in the order listed: signature creation time (same as creation time of E), critical key expiration time: max_rd (by convention, 10 days = 864000 seconds), critical key flags: only encrypt to comms is set, critical issuer fingerprint (fingerprint of A), not critical

Certificate Size An outbound certificate is 2938 octets in binary form. A certificate for a peer should be merged into the locally cached certificate which may thus contain multiple rotating subkeys and grow accordingly.

Use of OpenPGP format OpenPGP has two different packet framing formats: the "OpenPGP format" () and the "Legacy format" (). Autocrypt v2 certificates and TSKs use only the OpenPGP format. This is particularly relevant for the deterministic ratcheting step described in because that step needs a canonical octet-string representation of several OpenPGP packets.

Identifying an Autocrypt v2 Transferable Secret Key Peers interacting with an Autocrypt v2 certificate do not need to identify it as an Autocrypt v2 certificate at all. They simply need to apply common OpenPGP semantics to the certificate. However, all UMAs operated by the keyholder need to identify an Autocrypt v2 Transferable Secret Key (TSK) in order to perform aligned key ratcheting and achieve reliable deletion for the keyholder.

Identification By TSK Structure A Transferable Secret Key (TSK) is identified as an Autocrypt v2 TSK if its internal structure corresponds to the packets defined in . The keyholder's UMA must recognize this structure to perform the aligned key ratcheting necessary for reliable deletion. In particular, a AC2 TSK detection algorithm can simply confirm that the following predicates are all true: The input is is a well-formed v6 TSK. The primary key is Ed25519. The primary key does not expire. The primary key is marked with a direct key signature that confirms it is capable of handling SEIPD v2. The primary key creation time is 0x6a44587f (2026-06-30T23:59:59Z) It has a ML-KEM-768+X25519 subkey (the "fallback" subkey) which meets all of the following conditions: The fallback subkey is created at the same time as the primary key. The fallback subkey is marked for encryption for communication and storage. The fallback subkey does not expire. The fallback subkey creation time is 0x6a44587f (2026-06-30T23:59:59Z) It has at least one ML-KEM-768+X25519 subkey ("rotating" subkey) whose binding signature matches the canonical list of subpackets in Packet F of .

Determining min_rd and max_rd The subkey rotation cadence is derived from the Key Expiration Time subpacket () found in Packet F of . By definition, the value of the Key Expiration Time subpacket (which is measured as an integer number of seconds) is max_rd. The default value for max_rd is 864000 seconds. max_rd represents the maximum remaining validity duration that a peer might find in a keyholder's certificate, which occurs if the peer retrieves a copy immediately after a new subkey is created. min_rd is derived from max_rd. By convention, min_rd is half of max_rd. In particular, when max_rd is the default value of 864000 seconds, min_rd is 432000 seconds. min_rd represents the minimum remaining validity duration that a peer is guaranteed to find in a keyholder's certificate at any time, provided the keyholder is following the standard rotation schedule. This worst case occurs when the peer retrieves the certificate just before the next subkey rotation. It is the "floor" of the validity window available to a peer. Anyone designing a similar system with a different ratcheting cadence where min_rd that is anything other than half of max_rd MUST explicitly coordinate min_rd somehow with all other UMAs and MUST set max_rd to something other than 864000.

Reliable Deletion Strategy An Autocrypt v2 certificate evolves over time, as new rotating encryption subkeys are added to it. It also sees older rotating encryption subkeys expire and potentially be removed. This requires reasonable behavior by the keyholder and their peers.

Keyholder Certificate and Secret Key Management The keyholder must update the certificate regularly by ratcheting its secret key material forward to a new subkey. Since the ratchet is deterministic, based on time and the old key material, and the ratcheting schedule is standardized, each UMA that the keyholder uses will ratchet forward in the same way, without needing any additional network coordination.

Subkey Ratchet Each successive encryption-capable subkey is derived deterministically from the subkey before it. This section describes how to derive the secret key material and a deterministic subkey binding signature for the new encryption-capable subkey based on the following values: secret_key, the Transferable Secret Key to be ratcheted. start, the creation timestamp for the new subkey, represented as a number of seconds elapsed since 1970-01-01T00:00:00Z, as a big-endian, 32-bit unsigned integer. Note that both start, and the non-secret parts of secret_key (that is, secret_key with get_public() applied to all its Secret Key packets) are publicly visible. The ratchet function relies on several deterministic subfunctions: get_primary_key(TSK) -> K takes a Transferable Secret Key and returns the Secret Key packet of its primary key. get_last_rotating_subkey(TSK) -> (K, sbs) takes a Transferable Secret Key and returns the Secret Subkey packet and corresponding Subkey Binding Signature packet of the latest-expiring subkey that has the canonical list of subpackets described in Packet F of . extract_secret_key_material(K) -> M retrieves 96 octets of secret key material M from an OpenPGP ML-KEM-768+X25519 secret key packet K. The octets of M are structured exactly as they are on the wire. (32 octets of X25519 key material + a 64 octet seed of ML-KEM-768). get_public(K) -> P takes an OpenPGP Secret Key (or Subkey) packet and produces the corresponding OpenPGP Public Key (or Subkey) packet in OpenPGP format. make_secret_subkey(M,T) -> K takes 96 octets of secret key material M and OpenPGP timestamp T and produces a ML-KEM-768+X25519 secret subkey packet with creation time T. normalize_x25519_scalar(M) -> M takes 96 octets of OpenPGP ML-KEM-768+X25519 secret key material, and normalizes the first 32 octets, which are an X25519 secret key. The full 96 octets are returned after normalization. Normalization clears the three least-significant bits of the first octet, clears the most-significant bit of the 32nd octet, and sets the second-most-significant bit of the 32nd octet, as described in decodeScalar25519 in . get_expiration_duration(S) -> secs takes a Signature packet with a hashed Key Expiration subpacket and returns the contents of the hashed Key Expiration subpacket, represented as four octets, interpretable as a big-endian unsigned integer number of seconds. bind_subkey(P,K,T,subp,salt) -> S takes primary Ed25519 secret key P, public subkey K, timestamp T, an ordered list of OpenPGP signature subpackets subp, and a 16-octet salt, and produces an OpenPGP v6 Subkey Binding Signature S using an Ed25519 signature. Ed25519 signatures are deterministic as described in . The next secret subkey and subkey binding signature are derived via using SHA2-512, with the following construction, where || represents concatenation:

(next_secret_subkey, subkey_binding_sig): primary_key = get_primary_key(secret_key) (base_subkey, oldsbs) = get_last_rotating_subkey(secret_key) max_rd = get_expiration_duration(oldsbs) salt = start || get_public(base_key) info = "Autocrypt_v2_ratchet" || get_public(primary_key) || max_rd IKM = extract_secret_key_material(base_key) IKM = normalize_x25519_scalar(IKM) L = 160 ks = HKDF_SHA2_512(salt, info, IKM, L) bssalt = SHA2_512(ks[0:64])[0:16] new_secret = normalize_x25519_scalar(ks[64:160]) new_subkey = make_secret_subkey(new_secret, start) subpackets = [ sig_creation=start, key_expiration=max_rd, key_flags=EncryptComms, issuer_fingerprint=primary_key.fingerprint ] binding_sig = bind_subkey(primary_key, get_public(new_subkey), subpackets, bssalt) return (new_subkey, binding_sig) ]]>

The "Autocrypt_v2_ratchet" string is 20 octets as represented in US-ASCII.

Note that a UMA without access to the secret key material of the primary key can still use parts of AC2_Ratchet to derive the new secret key subkey without producing the subkey binding signature. Such a UMA would be able to decrypt incoming new messages.

AC2_Ratchet Diagram The core of the algorithm above can be visualized as follows:

Ratcheting Schedule This section describes a straightforward algorithm for a keyholder's UMA to decide when to create a new encryption-capable subkey. A UMA can execute this algorithm at any time, and SHOULD execute it in at least two specific cases: When preparing to extract an OpenPGP certificate for publication or transmission to a peer, and When receiving an encrypted message that is encrypted to a key that the implementation does not know about. In this case, to account for minor clock skew between a keyholder's own devices, a UMA MAY allow a small lookahead (e.g., several minutes) when checking if it is time to ratchet forward to a new subkey. Note that this algorithm is specifically about new subkey creation. Please see for recommendations about subkey destruction. Knowing when to produce a new secret subkey requires knowledge of four distinct values. All timestamps referenced here are values computed in the OpenPGP standard, that is, as an integer number of seconds elapsed since 1970-01-01T00:00:00Z. Two values are taken from the Autocrypt v2 TSK: base_start, the creation timestamp of the most recent rotating subkey. max_rd, the number of seconds that the rotating subkey will expire. One value is derived from the above: min_rd is typically half of max_rd (see ) And a final value is taken from general consensus: now, the current "wall-clock" timestamp. Add new rotating subkeys with the following routine: If now < base_start, abort. (something is probably wrong with the system clock or the secret key material) Let next_start be base_start + max_rd - min_rd. If now < next_start, terminate successfully (no need to ratchet). Generate new secret subkey next_key, using key material deterministically derived from the certificate's primary key, the most recent rotating secret subkey, max_rd, and next_start. Bind next_key as an encryption-capable subkey, using a deterministic subkey binding signature packet. next_key's creation timestamp (and the subkey binding signature) is next_start. See for how to deterministically derive the new secret key and subkey binding signature. Restart this process, using the new subkey. Note that the recursive nature of the above scheduler may end up generating multiple secret subkeys if the device has been offline for a long time.

Custom Ratcheting Schedules While this specification defines a 10-day validity window with a 50% overlap as the standard convention, a system could be designed with a different rotation window or a different overlap algorithm. Such a system MUST guarantee that all the keyholder's own UMAs follow an identical adjusted rotation schedules and key destruction logic in order to maintain synchronization. A peer receiving an incoming certificate produced under a custom schedule does not need to be aware of the keyholder's specific rotation logic. Because these certificates adhere to standard OpenPGP structures, the peer will properly handle them by merging the new subkeys into their local cache using standard OpenPGP semantics (see ). As long as the primary key remains constant, the peer's UMA will simply see a sequence of valid encryption subkeys and can continue to encrypt messages following the logic described in .

Timing of Secret Key Destruction To achieve reliable deletion, a keyholder SHOULD destroy the secret key material for a rotating encryption subkey as soon as it is no longer required for decryption. Because message delivery is not instantaneous, a subkey should be retained for a grace period beyond its validity window. This document refers to this grace period as max_latency. max_latency accounts for the maximum expected transit time of the underlying transport mechanism. For example, a max_latency of 10 days (864000 seconds) is reasonable for Internet mail, as it is double the maximum delivery timeout (see ). The destruction process is tied to the successful retrieval and processing of messages. A UMA SHOULD follow this routine: Track Transport Endpoints: For every transport endpoint associated with a certificate, the UMA maintains a last_checked timestamp and an expected maximum delivery max_latency. Determine the Safety Horizon: The UMA calculates an oldest_update timestamp, which is the minimum value of (last_checked - max_latency) across all associated transport endpoints. Destroy Expired Material: Any rotating secret subkey with an expiration time earlier than the oldest_update is destroyed. In cases of persistent transport unreachability, a UMA must balance the need for decryption with the goal of reliable deletion. If a transport endpoint remains inaccessible for a prolonged period, the UMA SHOULD eventually disassociate that endpoint from the certificate. Failing to do so would prevent oldest_update from advancing, indefinitely stalling key destruction and widening the window of recoverability (see ). Once the UMA gives up on fetching messages from an inaccessible transport, it can proceed with the standard destruction of the corresponding secret key material.

Autocrypt v2 TSK and Certificate Timeline The following diagram illustrates the timeline for evolution of an Autocrypt v2 TSK and Cert.

Receiving and Merging Certificates An outbound Autocrypt v2 certificate always has the same primary key, but new encryption-capable subkeys appear on a regular basis. A peer UMA that encounters a certificate SHOULD merge the known subkeys into the locally cached certificate, using a mechanism like sop merge-certs (). A peer that replaces but does not merge certificates may end up encrypting a message to a subkey with a wider window of recoverability than necessary.

Minimization and pruning of Autocrypt v2 certificates To ensure good data hygiene and minimize storage use, implementations should regularly prune Autocrypt v2 certificates, for example when merging incoming certificates. According to the ratcheting schedule algorithm (), a merged Autocrypt v2 certificate typically can contain at most two valid rotating subkeys at any given time. Because expired subkeys can no longer be used for encryption, it is RECOMMENDED that implementations drop all expired encryption subkeys (and their corresponding subkey binding signatures) from certificates on a continuous basis. This maintenance strategy keeps the certificate size minimal while allowing communication with reliable deletion. Note that deletion of secret key material (as opposed to the public key material in certificates) happens at a different cadence, see .

Encrypting to an Autocrypt v2 Certificate When encrypting a message to an Autocrypt v2 certificate, the peer should encrypt the message to only one of the encryption-capable subkeys. If any rotating encryption subkey is valid, the peer MUST NOT encrypt to the fallback encryption subkey. If no rotating encryption subkey is valid, and the peer has no way to update the certificate, the peer MAY encrypt the message to the fallback encryption subkey. If more than one rotating encryption subkey is currently valid, the peer SHOULD encrypt to the valid rotating encryption subkey with the nearest expiration date. This hastens the time when the message becomes reliably deletable.

Message Deletion When a message is to be deleted, the UMA MUST delete all known copies of the message, as well as any set-aside session keys. It MUST also remove traces of the message from any index it may have created, as indexing tends to create an equivalent copy of the indexed content. The message will be unrecoverable by the adversary once the rotating subkey's secret key material has been destroyed (see ).

Keyholder Processing of Encrypted Messages To facilitate robust deletion of some messages while retaining the ability to read others from its archive, a UMA needs to plan how to process a message upon ingestion. When the keyholder first receives an encrypted message, their UMA typically places the message in an archive visible to the UMA. If the archive contains only the original ciphertext as received, then the message will be useless in the archive when the rotating subkey's secret key material is destroyed (see ). The goal is to have the message available in the archive when access is desired, and to be able to safely remove it from the archive when deletion is desired. There are at least three sensible ways to handle the message so that it can be deleted safely in the future: Archiving cleartext Stashing session keys Re-encrypting

Archiving Cleartext The simplest model is that the keyholder's UMA retains the cleartext of each message, entirely discarding the in-transit form. The UMA can re-visit the content of such a message trivially, regardless of whether the asymmetric secret key used for decryption has been destroyed or not. This approach presumes that the message archive is not typically accessible to the adversary.

Stashing Session Keys In this approach, the keyholder's UMA retains the in-transit form of the message, but associates the OpenPGP session key of the encrypted content with the message. For example, the UMA could store the session keys in a separate look-aside table, indexed by Message-ID. In this case, the UMA can access the cleartext of the message by decrypting it with the set-aside session key, even when the asymmetric secret key has been destroyed. This approach can be used where the adversary has regular access to the archive, effectively treating the archive as though it were as at-risk as the message in transit. But the area where the session keys are stored MUST NOT be typically accessible to the adversary. If message cleartext is indexed, the session key storage MUST be at least as secure from the adversary as the message index.

Re-Encrypting Finally, if the UMA retains some other long-term secret key for archival access, it can process each message by re-encrypting it to the long-term archival key. This can be done either by prepending each OpenPGP Encrypted Message with a new Public Key Encrypted Session Key (PKESK) packet (See ) that contains the existing message's session key, or by unwrapping the SEIPD packet entirely, and re-encrypting it to the long-term archival key. This approach presumes that the message archive is not typically accessible to the adversary. If the archive were regularly accessible to the adversary, the adversary could store the re-encrypted message before deletion. Then, during the compromise of the user's long-term key, the adversary could unlock their copy of the previously deleted message.

Summary of Message Processing Strategies Archiving Strategy raw message retained? simple indexing OpenPGP packet handling Deletable if adversary can access archive Archived Cleartext N Y N N Stashed Session Key Y N N Y Re-encrypted Message N N Y N

Security Considerations See the discussion of quantum impersonation in . A message encrypted to the long-term fallback encryption subkey can not be reliably deleted, because an adversary who captures the message and in the future exfiltrates the keyholder's secret key material will be able to decrypt their stored copy of the message.

Reliable Deletion Threat Model The threat model for reliable deletion of messages has three core expectations: The adversary has access to any message in transit, and can retain the in-transit form of each message indefinitely. At some point in the future, the adversary can compromise the keyholder's UMA to be able to get access to their secret key material. The archive maintained by the keyholder's UMA is subject to the same level of threat as the keyholder's secret key storage. The goal for the keyholder is that when the adversary compromises either the keyholder's archive or the keyholder's secret key material (or both), any message that has been deleted by the keyholder is in fact unrecoverable by the adversary.

The Cleartext Is The Targeted Asset Some "Forward Secrecy" schemes emphasize key ephemerality so heavily that they lose track of the adversary's goal. This document uses the "Reliable Deletion" framing because the adversary wants to compromise the confidentiality of the message itself, which means the key is only an intermediate target. Many UMAs are effectively systems both for messaging and for archiving. For archiving UMAs, exfiltration of the archive is often as easy as (or even easier than) exfiltration of the secret key. This means that confidentiality protection needs to consider being able to delete the message cleartext from the archive as well as the relevant secret key material.

Key Destruction: Time-based vs. Message-based Automated encryption key destruction is a necessary component to achieving reliable deletion. There are two main approaches to scheduling key destruction: time-based and message-based. Some messaging protocols (e.g., ) ratchet keys on every message (or nearly every message). This message-based key destruction schedule gives a narrower window of temporal availability for each key, and fewer messages are encrypted to each key. The time-based approach used in this specification is simpler and relies primarily on all UMAs controlled by a single keyholder to have a shared sense of the global clock. While the temporal window of key availability is often wider in the time-based approach, its simplicity means much less inter-client coordination. And the narrower temporal window of key validity offered by the message-based approach is often not the limiting factor in the temporal window of message recoverability (see .

The Window of Recoverability Any message system offering reliable deletion has a frame of time during which the message cannot be robustly deleted because it can be recovered by an attacker. For example, in a scheme where each message is encrypted to its own unique key, if one of the recipients of the message has not yet received the message, a copy of that key must be available on the lagging recipient's device. An adversary who is capable of: capturing a copy of the message in transit, and preventing its delivery to one of the recipients, and compromising the recipient's device will be able to recover the message cleartext even if all other parties involved with the message have deleted it long ago. Realistically, a message is only deleted once every cleartext copy of it has been destroyed, and every system with access to the message's secret key has destroyed the secret key. At a minimum, a message that is in flight is not yet deletable, and for a message sent to a group, message deletion is only as robust as the slowest, most detached and uncoordinated member of the group. Automated message deletion policies (such as "disappearing messages" functionality common in many messenger apps) can assist in message deletion, but they are similarly bound by the duration of secret key retention. Schemes with rapid key rotation tend to need more complex internal state, and are more likely to result in unreadable messages. For initial messages, these schemes might require all parties to a communication to be online at the same time, or require any offline participants to distribute some introductory key material ("prekeys") to a reliably online third party. A "prekey" scheme is itself at risk of attacks that can cause initial messages to lose the desired deletability property, or can expose additional metadata to an attacker (see, for example, ). This document accepts a wider window of message recovery (at most 20 days, by default) which lets implementers avoid the need for any network synchronization between the keyholder's UMAs. This tradeoff provides a decentralized and robust way to achieve reliable deletion.

System Clock Reliance A wrong system clock can have security implications for a system interacting with Autocrypt v2 keys and certificates. A UMA should confirm that its system clock is within a reasonable range of the global consensus on what time it is. There are at least four possible security- and usability-relevant failures that could happen as a result of a broken system clock: With a system clock set too far in the past, a UMA might encrypt a message to an actually-expired encryption subkey. If the recipient has already destroyed their secret key material according to schedule, such a message would be undecryptable. With a system clock set too far in the future, a UMA might decide that no rotating encryption subkey is available for a peer, and therefore encrypt a message to the fallback encryption key, thereby losing the reliable deletion property for that message. With a system clock set too far in the future, the UMA of a keyholder with an Autocrypt v2 secret key might ratchet their secret key very far forward and destroy secret key material that is still being used to encrypt messages to them. This would render all incoming messages undecryptable. With minor clock skew (on the order of minutes) between multiple devices of a single keyholder, one device might ratchet "ahead" of another. If the lagging device receives a message encrypted to a subkey it has not yet generated, it may experience a transient decryption failure until its local clock reaches the rotation threshold. To mitigate this, a UMA MAY ratchet ahead by a small lookahead when it encounters an unknown subkey (see ).

Avoiding System Clock Skew There are several ways to try to ensure that the local system clock matches the general consensus about what time it is. Broadly, the UMA (or the device on which it runs) can glean an understanding about the consensus time from dedicated time servers, from servers that it otherwise communicates with directly, or from the peers that send it messages. An attacker in control of any of these sources of time consensus might use their influence to try to defeat reliable deletion (e.g., by forcing a message to be encrypted to the fallback key, or by delaying secret key deletion), or to create a denial of service (e.g., by encouraging encryption of messages to an already deleted subkey, or by encouraging early deletion of a secret key). One approach to learning about the local clock's skew from consensus time is to use against one or more known-good time servers. Another approach is to glean a reasonable time bounds from the transport layer the UMA connects with. For example, when using using (or with the handshake), it's possible to infer a range of plausible times the server operator thinks it could be by looking at the Validity member (from notBefore to notAfter) of the server's certificate. Narrower Validity members are more common today than they were in the past and can help to detect a clock skew that is greater than the bounds of Validity. To the extent that the server participates in , the UMA could also determine reasonable time bounds from timestamp member of the SignedCertificateTimestamp extension. If the server offers a stapled response via the OCSP Status Request extension, the various timestamps (e.g. producedAt and thisUpdate and nextUpdate) in a stapled OCSPResponse can also be used as an estimate of the server's rough sense of the wall clock. Estimates like these based on information provided from the server in the TLS handshake are valuable because the UMA has typically not yet authenticated to the server during the handshake, which makes a targeted attack from the server in this context less likely. The UMA can also get a rough estimate of their correspondents' view of the wall clock time by looking, for example, at the Date header in recently-received e-mail messages. These methods can generate estimates of the likelihood of clock skew. In the event that the keyholder's UMA believes that its clock is substantially advanced beyond the consensus time, it MAY postpone secret key deletion until it is more confident in its clock alignment.

Usability Considerations The keyholder needs to regularly update their certificate, and re-transmit it to those peers who might want to write them a confidential message. Refreshing the encryption-capable subkeys might be done with a suitable invocation of sop update-key (see ). After subkey rollover, re-transmission to peers might be done with or some other in-band communication process. Alternately, if the keyholder's peers refresh certificates before sending mail, the updated certificate could be uploaded to keyservers using or a comparable protocol. If a peer is willing to encrypt to an expired encryption key, they will create a message that the keyholder cannot decrypt, because the keyholder regularly destroys the secret key material associated with expired subkeys. The peer MUST NOT encrypt to an expired encryption key.

IANA Considerations This document does not require any action from IANA.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public key or symmetric cryptographic algorithms, digital signatures, compression, and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document obsoletes RFCs 4880 ("OpenPGP Message Format"), 5581 ("The Camellia Cipher in OpenPGP"), and 6637 ("Elliptic Curve Cryptography (ECC) in OpenPGP"). This document defines a post-quantum public key algorithm extension for the OpenPGP protocol, extending RFC 9580. Given the generally assumed threat of a cryptographically relevant quantum computer, this extension provides a basis for long-term secure OpenPGP signatures and ciphertexts. Specifically, it defines composite public key encryption based on ML-KEM (formerly CRYSTALS-Kyber), composite public key signatures based on ML-DSA (formerly CRYSTALS-Dilithium), both in combination with Elliptic Curve Cryptography (ECC), and SLH-DSA (formerly SPHINCS+) as a standalone public key signature scheme. This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK] American Civil Liberties Union Proton AG This document defines a generic stateless command-line interface for dealing with OpenPGP messages, certificates, and secret key material, known as sop. It aims for a minimal, well-structured API covering OpenPGP object security and maintenance of credentials and secrets. arXiv The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. [STANDARDS-TRACK] Jabberwocky Tech PGPKeys.EU Proton AG This document specifies a series of conventions to implement an OpenPGP keyserver using the Hypertext Transfer Protocol (HTTP). As this document is a codification and extension of a protocol that is already in wide use, strict attention is paid to backward compatibility with these existing implementations. A.L. Digital Ltd The confidentiality of encrypted data depends on the secrecy of the key needed to decrypt it. If one key is able to decrypt large quantities of data, its compromise will be disastrous. This memo describes three methods for limiting this vulnerability for OpenPGP messages: reducing the lifetime of confidentiality keys; one-time keys; and the additional use of lower-layer security services.

Historical notes Prior work on "forward secrecy" in OpenPGP dates back decades, including . Much of the guidance in that document is useful, and it is worth reading. As far as the authors are aware, the mechanisms described there were never widely adopted, and no tooling is currently available to make certificates compliant with the policies or "single-use" subpackets outlined there. That specification also never grappled with the complexities of coordinating ephemeral subkeys across multiple UMAs, or considering how "reply all" would work in a group messaging context for single-use keys.

Design Choices

Subkey Validity Windows When designing the subkey rotation mechanism, it's possible to create back-to-back, overlapping, or superset validity windows.

Back-to-Back Validity Windows With back-to-back validity windows, Each subkey is valid for a period that doesn't overlap with any other subkey.

' ]]>

In this arrangement, it is unambiguous which subkey to encrypt to, and validity windows can be shorter. But toward the end of one subkey's validity window, the keyholder needs to distribute the next subkey as well as the current subkey, in case an incoming message is produced after the cutover. When the keyholder does this, they are distributing two subkeys (which makes the certificate larger). Also, the upcoming subkey will have a creation time and signature creation time in the future, and peer implementation support for subkeys with creation times or subkey binding times in the future is dubious. Some peers may reject the subkey for being "from the future", and strip it before storing the certificate. Those peers won't have it available when they need it, and might end up having to encrypt to the fallback subkey. Other peers may ignore the creation timestamps, and go ahead and encrypt to the subkey before its validity window begins. Policy needs a decision about when to start distributing the new subkey, but that decision does not affect the wireformat. If keyholder's UMA X distributes the new subkey earlier than keyholder's UMA Y, and a peer encrypts a message to the new subkey before the new subkey is valid, keyholder's UMA Y may need to trial-ratchet until it finds the right subkey.

Overlapping Validity Windows With overlapping validity windows, each subsequent rotating subkey's validity starts during the validity window of the prior rotating subkey.

' ]]>

The validity window for any subkey in this scheme is wider than back-to-back. Keyholder only needs to distribute a single rotating subkey. Policy needs a decision about how much the validity windows should overlap, which affects the wireformat. This document records the convention that the validity windows overlap by 50% (new subkey created halfway through the prior subkey's validity). The keyholder's UMAs can blindly coordinate subkey distribution by only distributing subkeys whose validity window is currently active.

Superset Validity Windows With superset validity windows, each rotating subkey has an identical creation time, but each subsequent subkey has a later expiration date.

' ]]>

This scheme relies on the keyholder's machines delaying generation of each subsequent rotating subkey, as a prematurely-generated (and distributed) subkey might get used by a peer.

Validity Window Conclusion Decision: better to go with overlapping, so that the common case is a certificate with only a single rotating subkey.

Ed25519 for Primary Key Why not go with PQ/T primary key? Because signatures from all PQ/T keys are very large, and each cert needs at least three signatures in it. Why not go with Ed448 primary key? Because Ed25519 implementations have endured significantly more scrutiny than Ed448 implementations. Also, Ed25519 is already mandatory-to-implement in OpenPGP, and signatures are marginally smaller.

Balancing Rotation and Reliable Deletion Timing The default 5-day rotation period, 10-day expiration, and 20-day deletion schedule balance reliability with security. The 10-day buffer after expiration accounts for potential message transmission delays in systems like SMTP. Deleting the secret key material after 20 days ensures that reliable message deletion occurs in the near future. This timeline prevents secret keys from being stored longer than necessary while remaining compatible with the pace of modern email.

No Explicit Annotations An Autocrypt v2 certificate is identifiable by its structure and parameterization alone. There is no attempt to mark a certificate explicitly as an attempt at Autocrypt v2. The design goal of interop with peers with a merely upgraded OpenPGP implementation suggests that an explicit indicator would be unnecessary.

Seed-free Ratcheting When ratcheting a secret subkey forward, this design only uses secret entropy from the current ratcheting subkey's secret key material. Introducing additional data in the form of a seed would require special coordination between cooperating peers for the initial synchronization of that seed, which complicates the goal of minimizing network synchronization. For example, a keyholder that adds another UMA to their account currently needs to transfer an OpenPGP TSK to the new UMA. How would a distinct seed be transmitted to the other UMA in such a way that it would not be be accidentally re-transmitted to a peer by legacy tooling that extracts an OpenPGP certificate from the TSK? Another choice of additional seed material could be the secret key material of the primary key itself, or of the fallback's secret key material. By not including any of that secret key material in the input to the ratchet, we enable the keyholder to distribute these two long-term keys to their various UMAs via a tamper-resistant hardware device.

Test vectors

Key and Certificate Created At 2026-07-01T17:33:45Z, this Autocrypt v2 secret key was created, with the associated certificate.

Initial Certificate This outbound certificate is distributed to peers that the key holder wants to communicate with.

Initial TSK This secret key is made available only to the keyholder's own devices.

After New Subkey Added After 2026-07-06T17:33:45Z (min_rd after the initial key creation), a new rotating subkey is added. The new subkey is derived via HKDF as described in , with the following parameters: Salt:

Info:

IKM:

The HKDF output is:

The first 64 octets of this is fed through SHA2_512 to create the salt for the subkey binding signature. The remaining octets are used to initialize the new subkey's secret key material. This results in a new TSK and a new cert.

Certificate With New Subkey This updated outbound certificate should be distributed to the keyholder's peers starting on 2026-07-06T17:33:45Z.

TSK With New Subkey Every device of the keyholder should be able to derive this exact secret key from the TSK found in .

Merged Certificate A peer that had received the original certificate and then the subsequent certificate would have merged the two into this object:

After 2026-07-11T17:33:45Z (when the first subkey expires and is no longer usable), the peer can prune the merged certificate, which should bring it back to the certificate found in .

Old Subkey Removed When the key and certificate are no longer useful, they can be removed.

TSK With Old Subkey Removed max_latency after the old rotating subkey expires (that is, any time after 2026-07-21T17:33:45Z), the keyholder's device checks for all incoming messages and processes them. Once they have all been received and processed, the keyholder's device destroys the expired rotating secret subkey, leaving this TSK.

Acknowledgements The following people have contributed in various ways to this draft, offering reviews, suggestions, corrections, and implementation notes: Ramakrishnan Muthukrishnan Heiko Schäfer

Document History

Changes from draft-autocrypt-openpgp-cert-v2-02 to draft-autocrypt-openpgp-cert-v2-03 new goal: reduce metadata leaks canonicalize rotating subkey binding signature subpackets, rather than copy from previous generation fix a generic, shared creation date for primary key and fallback key provide explicit AC2 TSK detection logic explicitly reference minor editorial cleanup

Changes from draft-autocrypt-openpgp-cert-v2-01 to draft-autocrypt-openpgp-cert-v2-02 adjust description of max_rd and min_rd acknowledge reviewers correct default value of min_rd offer mitigation for small clock skew between MUAs of the same user

Changes from draft-autocrypt-openpgp-cert-v2-00 to draft-autocrypt-openpgp-cert-v2-01 rename delay to max_latency clean up some lingering terminology that should have been max_rd align timeline diagram with text refocus abstract test vector descriptions: correct when old secret subkey gets removed