Autocrypt v2 OpenPGP Certificates and Transferable Secret Keys

Internet-Draft	Autocrypt v2 Certificates and TSKs	January 2026
Gillmor, et al.	Expires 1 August 2026	[Page]

Abstract

This document describes the "Autocrypt v2 Certificate", a standard structure for an OpenPGP certificate for Internet messaging (such as email) that offers a defense against both store-now-decrypt-later attacks from quantum computer and future key exfiltration attacks. It is also structured to support reasonable in-band transmission, using established mechanisms like the Autocrypt header field. This document also describes the structure, use, and maintenance of the OpenPGP Transferable Secret Key that corresponds with the Autocrypt v2 Certificate.¶

1. 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.¶

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

"OpenPGP certificate" or just "certificate" refers to an OpenPGP Transferable Public Key (see Section 10.1 of [RFC9580]). 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 Section 10.2 of [RFC9580]).¶
"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.¶

1.3. 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 Section 5.1).¶
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.¶

1.4. 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.¶

4. 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.¶

4.1. 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.¶

4.1.1. 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 it latest-expiring subkey that is marked with "encrypt to comms"¶
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 Section 5 of [RFC7748].¶
get_hashed_subpackets(S) -> subpackets takes a Signature packet and returns the ordered list of hashed subpackets from that Signature.¶
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.¶
replace_creation_time(subpackets, T) -> subpackets takes an ordered list of OpenPGP signature subpackets sps and returns the same list but with the value of the Signature Creation Time subpacket replaced by T.¶
bind_subkey(P,K,T,sps,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 Section 8.2 of [RFC8032].¶

The next secret subkey and subkey binding signature are derived via [HKDF] using SHA2-512, with the following construction, where || represents concatenation:¶

AC2_Ratchet(secret_key
            start)
            -> (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)
  subp = replace_creation_time(get_hashed_subpackets(oldsbs), start)
  binding_sig = bind_subkey(primary_key,
                            get_public(new_subkey),
                            subp, bssalt)
  return (new_subkey, binding_sig)

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

000  41 75 74 6f 63 72 79 70 |Autocryp|
008  74 5f 76 32 5f 72 61 74 |t_v2_rat|
010  63 68 65 74             |chet|
014

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.¶

4.1.1.1. AC2_Ratchet Diagram

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

Figure 2: AC2_Ratchet Diagram

4.1.2. 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.¶

Note that this algorithm is specifically about new subkey creation. Please see Section 4.1.4 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 Section 3.2)¶

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 Section 4.1.1 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.¶

4.1.3. 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 Section 4.2). 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 Section 4.3.¶

4.1.4. 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 delay accounts for the maximum expected transit time of the underlying transport mechanism. For example, a 10-day delay (864000 seconds) is reasonable for Internet mail.¶

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 delay.¶
Determine the Safety Horizon: The UMA calculates an oldest_update timestamp, which is the minimum value of (last_checked - delay) 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 Section 5.4). 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.¶

4.1.5. Autocrypt v2 TSK and Certificate Timeline

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

Figure 3: Autocrypt V2 TSK and Certificate Timeline

4.2. 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 (Section 5.2.6 of [I-D.dkg-openpgp-stateless-cli]).¶

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.¶

4.2.1. 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 (Section 4.1.1), 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 Section 4.1.4.¶

4.3. 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 revocation date. This hastens the time when the message becomes reliably deletable.¶

4.4. 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 Section 4.1.4).¶

4.4.1. 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 Section 4.1.4). 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¶

4.4.1.1. 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.¶

4.4.1.2. 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.¶

4.4.1.3. 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 Section 5.1 of [RFC9580]) 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.¶

4.4.2. Summary of Message Processing Strategies

Table 1: Message Archiving 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

5. Security Considerations

See the discussion of quantum impersonation in Section 1.4.¶

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.¶

5.1. 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.¶

5.2. 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.¶

5.3. 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., [Double-Ratchet]) 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 Section 5.4.¶

5.4. 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, [PREKEY-POGO]).¶

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.¶

5.5. System Clock Reliance

A wrong system clock can have three serious impacts on 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 three possible security-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.¶

5.5.1. 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 [NTP] 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 [TLS] (or [QUIC] with the [TLS] 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 [X.509] 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 [Certificate-Transparency], the UMA could also determine reasonable time bounds from timestamp member of the SignedCertificateTimestamp extension. If the server offers a stapled [OCSP] 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.¶

Appendix C. Test vectors

C.1. Key and Certificate Created

At 2025-11-01T17:33:45Z, this Autocrypt v2 secret key was created, with the associated certificate.¶

C.1.1. Initial Certificate

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

C.1.2. Initial TSK

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

C.2. After New Subkey Added

After 2025-11-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 Section 4.1.1, with the following parameters:¶

Salt:¶

000  69 0c db f9 ce c4 0a 06  69 06 44 79 23 00 00 04
010  c0 98 24 64 8a b5 b9 09  83 5d b9 c1 09 b3 9d 0e
020  7b 05 d3 20 3a 5d fb 50  51 0f cf 37 c7 ae 4a 9a
030  6a 5b 63 c5 40 05 77 65  73 8b a7 20 4e f2 9c c3
040  57 4c 9b d6 91 5f 23 50  4d c7 51 17 a7 e2 4f 54
050  52 5c d1 90 5d ee c0 a8  78 e9 50 a7 f7 84 a1 9b
060  0e eb b3 9c 14 e3 84 17  73 b6 b2 b3 46 29 6b 75
070  c5 56 78 e8 30 4a 3e 0b  c3 79 36 a2 d0 8a 92 07
080  a6 62 63 80 48 d5 1a 1f  3f 13 5d 20 e4 50 93 73
090  6b 31 f1 70 23 77 3c 69  6c b4 5c 94 a6 a0 a4 05
0a0  25 69 b3 e3 60 83 a8 c2  83 88 65 3b 3d 0b 1d 39
0b0  c2 0c b8 f7 5a 44 70 55  2f 58 05 9b 74 b6 f1 56
0c0  1f 6d ab 53 1d 57 61 49  76 25 3c 3a 1b c8 83 62
0d0  c7 74 ad 8a 00 ae e1 f2  00 50 c1 a4 88 cb 49 fe
0e0  9a 1c bf d4 72 77 81 c7  fc 17 14 ca 7c c4 0f 02
0f0  1d 98 9b 45 b9 a1 5a 9c  d4 74 d8 02 51 2e 72 02
100  95 65 99 79 e5 35 f5 6c  39 dd f5 00 eb e7 6a cd
110  11 c7 f9 14 52 32 49 bc  59 6c 37 3f ba 69 84 47
120  c4 fa a0 85 d7 99 b2 ed  51 12 9d 8a 77 78 59 2b
130  56 57 85 c4 04 61 2f a0  1d a0 eb 98 a0 28 8f af
140  97 c6 c7 f3 3d 15 d9 7c  e7 49 c2 1f 28 ce 6a 34
150  49 b5 7b 92 5c ba 01 9a  7b 0f 41 c5 a3 4a ba 8b
160  7a 74 b4 fe f2 7e c8 a1  3a 8e 2c 74 33 83 94 b1
170  71 c0 8d 5a c2 d2 b7 01  db 43 62 36 39 76 0f 40
180  29 5e 44 cc 1b 38 80 eb  50 8b 05 a9 0c d7 77 89
190  d9 37 a4 b4 cb 78 05 39  88 a0 41 c9 a6 96 3c 79
1a0  03 6e 1e 69 a9 b8 a4 9d  08 e0 03 d5 95 89 d1 ca
1b0  90 b2 29 6a cc ca 23 98  ac a4 19 cb 77 18 a1 4a
1c0  72 70 c3 0a c1 74 76 61  2f 6a 41 ac 0f 23 9e d6
1d0  b2 8e bb 2a c4 00 8d 8b  d6 07 7f 7b b7 4b 11 cc
1e0  4d c5 17 a7 91 c2 59 08  66 5c b7 da b2 7c e8 c0
1f0  c9 e0 55 e8 41 69 04 d9  84 c6 26 b8 77 0a 8f 0a
200  d9 c5 96 25 88 f3 3c 37  40 30 9e 8b 92 c1 1b dc
210  b5 d8 70 63 e1 19 3d 66  25 a1 98 eb 05 8b 1b 4f
220  37 a0 9a 48 78 31 4c 5c  13 9e 09 17 ce e6 8b aa
230  45 1f 35 f7 ac 11 c9 2a  1d e6 44 4a 2a 02 a2 ab
240  2e 0f 22 22 f3 21 00 ae  48 b7 27 09 40 70 a9 7e
250  3b 14 b4 01 91 bb c6 d0  cf 9c b0 ae 8d d7 29 05
260  56 30 9e 77 80 83 33 27  f9 01 c8 68 f2 71 fd e9
270  76 dd ba 73 d6 59 7c f2  6a cd 9b a2 22 c3 c7 c1
280  e8 40 37 69 91 77 a9 b9  c5 8d 49 0f ae a0 b5 62
290  64 bc 96 f5 8a 5a fb 69  8c 08 7a e8 c9 19 c9 53
2a0  2c 2e d7 25 0d a4 80 7e  c7 b2 96 e0 5c 74 60 3f
2b0  24 4a 12 6a d5 60 44 b8  41 fc 02 6d 7d 9a 65 24
2c0  93 b9 63 06 c7 4b 1b 9a  39 43 09 31 88 04 81 45
2d0  6b b8 d8 81 fa 85 c1 75  ab 94 f1 66 ac 01 98 3c
2e0  63 e4 02 aa 53 10 e8 c8  12 e5 dc 41 1d 96 7c ff
2f0  f8 cc f0 70 03 f1 65 05  3f f9 57 84 75 b4 c7 7c
300  b5 08 d4 25 ed 24 2a 55  48 c8 c9 f3 7a 68 4b 13
310  ed 7c 7c 74 02 77 38 d7  07 13 f8 84 69 f0 12 59
320  b4 5d 90 0a 06 42 f1 0d  c8 da bb 6c 13 b9 c8 b7
330  8a 59 45 85 74 45 b1 af  c0 cc 73 9c 7d 99 f7 b3
340  f5 70 29 b2 71 c6 09 69  71 96 92 08 70 35 be 9d
350  70 89 cf b5 7a fc d5 64  71 70 80 71 e3 88 20 5a
360  01 70 90 b7 52 86 8e bc  a6 68 3a d1 c5 9c 8a 81
370  0a c4 6c 01 04 87 1a 42  af a9 24 30 e8 a9 50 b6
380  01 4f 1c 01 39 07 75 98  73 ac 8f 1a 45 77 df 59
390  7e 31 b0 9d 3f e1 af f5  34 8d 05 d2 6c 6f 65 17
3a0  ce d5 08 e0 d2 87 d8 a6  43 d2 3a 69 f2 8c 39 58
3b0  28 29 99 44 ab f3 95 89  2f d0 b2 f4 57 a4 61 0b
3c0  0d ae 68 a0 e1 83 7b 22  67 38 1f 05 4a 1c 1b 06
3d0  7c 91 a4 d8 ec af fa d2  a0 b8 c7 9a 2a 22 59 dc
3e0  b4 23 79 f1 c8 4c 38 75  3b 60 63 73 69 40 af 81
3f0  b5 13 51 6b 07 20 6b 7b  c8 b7 fe 02 29 29 99 3a
400  bd 22 39 32 8c b9 2e 6a  4d 1b 54 24 29 13 01 f2
410  05 28 91 56 aa 36 08 59  86 77 35 3a c1 1f 1d 00
420  58 ae b1 07 cb 60 22 c5  f1 7f 39 97 80 e4 11 8a
430  70 b1 88 ad 50 8b 3e 3c  c0 76 52 83 95 bb 56 49
440  85 b0 76 d2 ba e6 4c c4  99 f7 61 06 b8 18 af cb
450  8a c9 a2 ce 6d 23 7b 7b  67 c8 11 90 3f 4d d8 bc
460  a6 47 7c 53 db 18 2f f6  9f 91 37 18 25 48 cd 96
470  97 13 33 10 3f cc a8 3a  b6 d1 aa 42 77 9a 41 41
480  37 44 ab b7 a9 dc 14 c6  b4 0b 4e e5 ad 98 f2 cc
490  6b 99 ca 83 e1 3b 0f 37  b0 a6 31 57 52 51 79 e8
4a0  f5 4d 51 2a 32 a0 38 8f  97 c2 7e cc 5c 0b 0d 27
4b0  47 5f d9 99 e6 a3 35 93  d4 8e ba 71 c3 a8 be 55
4c0  f9 5c c9 60 84 eb 26 b4  f0 43 89 98 89 2c 22 02
4d0  39
4d1

Info:¶

000  41 75 74 6f 63 72 79 70  74 5f 76 32 5f 72 61 74
010  63 68 65 74 c6 2a 06 69  06 44 79 1b 00 00 00 20
020  71 12 55 45 47 6a 19 33  4c 9f 0c 13 79 06 6f fa
030  8f 17 89 a0 dd 55 34 e9  5e 78 cf 34 7d 85 47 8c
040  00 0d 2f 00
044

IKM:¶

000  a0 d7 c7 5b f6 52 19 1a  27 60 2f f2 8c 55 b1 a6
010  90 e4 93 0b 3c 1c a6 dd  9b 89 dc af a8 e1 18 72
020  9c ac 36 0e 74 e2 5c 9c  d6 8d a9 f7 e0 d2 e9 ff
030  97 81 66 f6 7e 09 ca 82  92 15 17 5c de b9 2d 31
040  a4 55 62 46 32 2a cc 50  ac 31 eb b6 66 61 60 c2
050  e8 c7 db 75 76 38 d9 6a  1e 46 bf 11 3f 79 98 2e
060

The HKDF output is:¶

000  46 d0 19 07 17 f2 68 a0  d1 52 26 2e e9 28 48 23
010  f9 db dc a5 99 54 00 b3  77 6c a8 8a c5 e5 6b 01
020  2e b4 11 60 a4 9e f9 f9  d5 e8 6f 41 6b 09 bf d3
030  a1 34 56 52 93 02 d4 c5  d1 f8 28 9b 5e 5a f6 f2
040  04 1f b5 2f c6 4d f7 01  bc 75 3d d4 5d d0 5a 19
050  98 fc 39 9a 13 26 18 c4  d6 f2 79 92 fb be 3f 51
060  89 80 49 b1 cb 63 fc 2a  68 47 5c a3 57 58 96 e8
070  ae a8 36 c1 10 6a 3f 23  ec 4d 1c 06 46 58 6e e8
080  b3 24 97 b3 13 a4 77 fa  1d 23 80 b0 6f 96 d4 ac
090  f3 84 f8 d0 46 ab 27 1a  7f b3 10 15 29 9d bc 22
0a0

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.¶

C.2.1. Certificate With New Subkey

This updated outbound certificate should be distributed to the keyholder's peers starting on 2025-11-06T17:33:45Z.¶

C.2.2. TSK With New Subkey

Every device from the keyholder should be able to derive this exact secret key from the TSK found in Appendix C.1.2.¶

C.2.3. Merged Certificate

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

After 2025-11-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 Appendix C.2.1.¶

C.3. Old Subkey Removed

When the key and certificate are no longer useful, they can be removed.¶

C.3.1. TSK With Old Subkey Removed

max_rd time after the old rotating subkey expires (that is, any time after 2025-11-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.¶