Autocrypt v2 OpenPGP Certificates and Transferable Secret Keys
draft-autocrypt-openpgp-v2-cert-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Daniel Kahn Gillmor , Holger Krekel , Friedel Ziegelmayer | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Other Repository
Issue Tracker |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| On agenda | openpgp at IETF-126 | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-autocrypt-openpgp-v2-cert-03
openpgp D. K. Gillmor
Internet-Draft ACLU
Intended status: Informational H. Krekel
Expires: 7 January 2027 merlinux gmbh
F. Ziegelmayer
n0 Inc.
6 July 2026
Autocrypt v2 OpenPGP Certificates and Transferable Secret Keys
draft-autocrypt-openpgp-v2-cert-03
Abstract
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.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://autocrypt2.codeberg.page/autocrypt-v2-cert/. Status
information for this document may be found at
https://datatracker.ietf.org/doc/draft-autocrypt-openpgp-v2-cert/.
Discussion of this document takes place on the OpenPGP Working Group
mailing list (mailto:openpgp@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/openpgp/. Subscribe at
https://www.ietf.org/mailman/listinfo/openpgp/.
Source for this draft and an issue tracker can be found at
https://codeberg.org/autocrypt2/autocrypt-v2-cert/.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Gillmor, et al. Expires 7 January 2027 [Page 1]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Certificate Structure . . . . . . . . . . . . . . . . . . . . 8
2.1. Encryption subkey rotation . . . . . . . . . . . . . . . 8
2.2. Fixed Creation Timestamp . . . . . . . . . . . . . . . . 9
2.3. Packet Composition . . . . . . . . . . . . . . . . . . . 9
2.4. Certificate Size . . . . . . . . . . . . . . . . . . . . 10
2.5. Use of OpenPGP format . . . . . . . . . . . . . . . . . . 11
3. Identifying an Autocrypt v2 Transferable Secret Key . . . . . 11
3.1. Identification By TSK Structure . . . . . . . . . . . . . 11
3.2. Determining min_rd and max_rd . . . . . . . . . . . . . . 12
4. Reliable Deletion Strategy . . . . . . . . . . . . . . . . . 12
4.1. Keyholder Certificate and Secret Key Management . . . . . 13
4.1.1. Subkey Ratchet . . . . . . . . . . . . . . . . . . . 13
4.1.2. Ratcheting Schedule . . . . . . . . . . . . . . . . . 17
4.1.3. Custom Ratcheting Schedules . . . . . . . . . . . . . 18
4.1.4. Timing of Secret Key Destruction . . . . . . . . . . 18
Gillmor, et al. Expires 7 January 2027 [Page 2]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
4.1.5. Autocrypt v2 TSK and Certificate Timeline . . . . . . 19
4.2. Receiving and Merging Certificates . . . . . . . . . . . 20
4.2.1. Minimization and pruning of Autocrypt v2
certificates . . . . . . . . . . . . . . . . . . . . 20
4.3. Encrypting to an Autocrypt v2 Certificate . . . . . . . . 21
4.4. Message Deletion . . . . . . . . . . . . . . . . . . . . 21
4.4.1. Keyholder Processing of Encrypted Messages . . . . . 21
4.4.2. Summary of Message Processing Strategies . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
5.1. Reliable Deletion Threat Model . . . . . . . . . . . . . 24
5.2. The Cleartext Is The Targeted Asset . . . . . . . . . . . 24
5.3. Key Destruction: Time-based vs. Message-based . . . . . . 24
5.4. The Window of Recoverability . . . . . . . . . . . . . . 25
5.5. System Clock Reliance . . . . . . . . . . . . . . . . . . 26
5.5.1. Avoiding System Clock Skew . . . . . . . . . . . . . 27
6. Usability Considerations . . . . . . . . . . . . . . . . . . 28
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Historical notes . . . . . . . . . . . . . . . . . . 31
Appendix B. Design Choices . . . . . . . . . . . . . . . . . . . 31
B.1. Subkey Validity Windows . . . . . . . . . . . . . . . . . 31
B.1.1. Back-to-Back Validity Windows . . . . . . . . . . . . 31
B.1.2. Overlapping Validity Windows . . . . . . . . . . . . 32
B.1.3. Superset Validity Windows . . . . . . . . . . . . . . 33
B.1.4. Validity Window Conclusion . . . . . . . . . . . . . 33
B.2. Ed25519 for Primary Key . . . . . . . . . . . . . . . . . 33
B.3. Balancing Rotation and Reliable Deletion Timing . . . . . 34
B.4. No Explicit Annotations . . . . . . . . . . . . . . . . . 34
B.5. Seed-free Ratcheting . . . . . . . . . . . . . . . . . . 34
Appendix C. Test vectors . . . . . . . . . . . . . . . . . . . . 34
C.1. Key and Certificate Created . . . . . . . . . . . . . . . 35
C.1.1. Initial Certificate . . . . . . . . . . . . . . . . . 35
C.1.2. Initial TSK . . . . . . . . . . . . . . . . . . . . . 36
C.2. After New Subkey Added . . . . . . . . . . . . . . . . . 38
C.2.1. Certificate With New Subkey . . . . . . . . . . . . . 40
C.2.2. TSK With New Subkey . . . . . . . . . . . . . . . . . 42
C.2.3. Merged Certificate . . . . . . . . . . . . . . . . . 44
C.3. Old Subkey Removed . . . . . . . . . . . . . . . . . . . 46
C.3.1. TSK With Old Subkey Removed . . . . . . . . . . . . . 46
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 48
Document History . . . . . . . . . . . . . . . . . . . . . . . . 48
Changes from draft-autocrypt-openpgp-cert-v2-02 to
draft-autocrypt-openpgp-cert-v2-03 . . . . . . . . . . 48
Changes from draft-autocrypt-openpgp-cert-v2-01 to
draft-autocrypt-openpgp-cert-v2-02 . . . . . . . . . . 49
Gillmor, et al. Expires 7 January 2027 [Page 3]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
Changes from draft-autocrypt-openpgp-cert-v2-00 to
draft-autocrypt-openpgp-cert-v2-01 . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
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".
Gillmor, et al. Expires 7 January 2027 [Page 4]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
* "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.
Gillmor, et al. Expires 7 January 2027 [Page 5]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
* 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.
* 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.
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:
Gillmor, et al. Expires 7 January 2027 [Page 6]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
* 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.
Gillmor, et al. Expires 7 January 2027 [Page 7]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
* 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.
2. 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 Section 2.3.
.------------------------------------------------------.
| A. Primary Key (Ed25519) |
+-------------------------------------------------------+
| B. Direct key sig (cert+sign, no expire) |
| C. Fallback Subkey (ML-KEM-768+X25519) |
| D. Subkey binding sig (encrypt, no expire) |
| E. Rotating Subkey (ML-KEM-768+X25519) |
| F. Subkey binding sig (encrypt, expires in max_rd) |
'-----------------------------------------------------'
Figure 1: Autocrypt v2 Certificate Structure
2.1. 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
Section 3.2 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 Section 4.1.3 for
more information.
Gillmor, et al. Expires 7 January 2027 [Page 8]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
This arrangement means the validity window of each subsequent
rotating subkey overlaps with the validity window of the prior
rotating subkey. See Appendix B.1 for more discussion about temporal
layout of subkey validity windows.
2.2. 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 [RFC9980] in UTC.
2.3. 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
Gillmor, et al. Expires 7 January 2027 [Page 9]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
- 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
Section 4.2 of [RFC9980]), 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
Section 4.2 of [RFC9980]), 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
2.4. 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.
Gillmor, et al. Expires 7 January 2027 [Page 10]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
2.5. Use of OpenPGP format
OpenPGP has two different packet framing formats: the "OpenPGP
format" (Section 4.2.1 of [RFC9580]) and the "Legacy format"
(Section 4.2.2 of [RFC9580]). Autocrypt v2 certificates and TSKs use
only the OpenPGP format.
This is particularly relevant for the deterministic ratcheting step
described in Section 4.1.1 because that step needs a canonical octet-
string representation of several OpenPGP packets.
3. 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 Section 4.1.1 and achieve reliable deletion
for the keyholder.
3.1. 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
Section 2.3. 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.
Gillmor, et al. Expires 7 January 2027 [Page 11]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
- 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 Section 2.3.
3.2. Determining min_rd and max_rd
The subkey rotation cadence is derived from the Key Expiration Time
subpacket (Section 5.2.3.13 of [RFC9580]) found in Packet F of
Section 2.3.
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.
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.
Gillmor, et al. Expires 7 January 2027 [Page 12]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
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 the latest-expiring subkey that
has the canonical list of subpackets described in Packet F of
Section 2.3.
* 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.
Gillmor, et al. Expires 7 January 2027 [Page 13]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
* 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_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 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:
Gillmor, et al. Expires 7 January 2027 [Page 14]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
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)
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.
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:
+------------------------+---------------------------+--------+
| "Autocrypt_v2_ratchet" | public primary key packet | max_rd |
+-+----------------------+---------------------------+--------+
|
| +-------+-------------------------------------+
| | start | prior rotating public subkey packet |
Gillmor, et al. Expires 7 January 2027 [Page 15]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
| +--+----+-------------------------------------+
| |
| | +---------------------------------------+
| | | prior rotating subkey secret material |
| | +-----------+---------------------------+
| | |
| | | input
- | - -| - - - - - - | - - - - - - - - - - - - - - - - - -
| | |
| | v
| | .----------------.
| | | normalize_x25519 |
| | '-------+--------'
| | |
'-. '------. '--.
info | salt | IKM |
v v v
.------------------------.
| HKDF H=SHA2_512 L=160 |
'-------------+----------'
|
v
+------------+-------------------------+
| 64 bytes | 96 bytes |
+-----+------+---------------------+---+
| |
v v
.--------. .----------------.
| SHA2_512 | | normalize_x25519 |
'----+---' '---------+------'
| |
- - - - | - - - - - - - - - - - - - - | - - - - - - - - -
| output |
v |
+---------------------+------------+ |
| 16 byte salt for v6 | ... | |
| subkey binding sig | (discard) | |
+---------------------+------------+ |
v
+--------------------------------------+
| next rotating subkey secret material |
+--------------------------------------+
Figure 2: AC2_Ratchet Diagram
Gillmor, et al. Expires 7 January 2027 [Page 16]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
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. 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 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:
1. If now < base_start, abort. (something is probably wrong with the
system clock or the secret key material)
2. Let next_start be base_start + max_rd - min_rd.
Gillmor, et al. Expires 7 January 2027 [Page 17]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
3. If now < next_start, terminate successfully (no need to ratchet).
4. 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.
5. 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 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
Section 4.5.4.1 of [RFC5321]).
Gillmor, et al. Expires 7 January 2027 [Page 18]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
The destruction process is tied to the successful retrieval and
processing of messages. A UMA SHOULD follow this routine:
1. 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.
2. 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.
3. 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.
Gillmor, et al. Expires 7 January 2027 [Page 19]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
Time
max_rd |
| .- +--+--------------------------------------.
| | | | primary key + fallback subkey created |
| | | | first rotating subkey created |
'-----+ | | cert generated |
| | | cert distribution begins |
| | +--------------------------------------'
| |
min_rd .--- +--+-------------------------------------------.
| | | | | new rotating subkey derived (AC2_Ratchet) |
| | | | | new subkey deterministically bound to cert |
'-----+ | | | cert redistribution begins |
| | | +-------------------------------------------'
| | |
'-+- +--+-----------------------------------------.
max_latency | | | first rotating subkey expires |
| | | | peers drop first subkey from merged cert |
'------+ | +-----------------------------------------'
| |
'- +--+------------------------------------------.
| | msgs recv'd+processed from all transports |
| | destroy first rotating secret subkey |
| +------------------------------------------'
v
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.
Gillmor, et al. Expires 7 January 2027 [Page 20]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
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 expiration 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
Gillmor, et al. Expires 7 January 2027 [Page 21]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
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.
Gillmor, et al. Expires 7 January 2027 [Page 22]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
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
+==============+=============+==========+==========+================+
| Archiving | raw | simple | OpenPGP | Deletable if |
| Strategy | message | indexing | packet | adversary can |
| | retained? | | handling | access archive |
+==============+=============+==========+==========+================+
| Archived | N | Y | N | N |
| Cleartext | | | | |
+--------------+-------------+----------+----------+----------------+
| Stashed | Y | N | N | Y |
| Session Key | | | | |
+--------------+-------------+----------+----------+----------------+
| Re-encrypted | N | N | Y | N |
| Message | | | | |
+--------------+-------------+----------+----------+----------------+
Table 1: Message Archiving Strategies
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.
Gillmor, et al. Expires 7 January 2027 [Page 23]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
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.
Gillmor, et al. Expires 7 January 2027 [Page 24]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
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")
Gillmor, et al. Expires 7 January 2027 [Page 25]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
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 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
Section 4.1.2).
Gillmor, et al. Expires 7 January 2027 [Page 26]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
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.
Gillmor, et al. Expires 7 January 2027 [Page 27]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
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.
6. 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 Section 5.2.5 of
[I-D.dkg-openpgp-stateless-cli]).
After subkey rollover, re-transmission to peers might be done with
[Autocrypt] 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 [HKP] 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.
7. IANA Considerations
This document does not require any action from IANA.
8. References
8.1. Normative References
[HKDF] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/rfc/rfc5869>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Gillmor, et al. Expires 7 January 2027 [Page 28]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/rfc/rfc7748>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9580] Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe,
"OpenPGP", RFC 9580, DOI 10.17487/RFC9580, July 2024,
<https://www.rfc-editor.org/rfc/rfc9580>.
[RFC9980] Kousidis, S., Roth, J., Strenzke, F., and A. Wussler,
"Post-Quantum Cryptography in OpenPGP", RFC 9980,
DOI 10.17487/RFC9980, June 2026,
<https://www.rfc-editor.org/rfc/rfc9980>.
8.2. Informative References
[Autocrypt]
Breitmoser, V., Krekel, H., and D. K. Gillmor, "Autocrypt
- Convenient End-to-End Encryption for E-Mail", 10
February 2019, <https://autocrypt.org/>.
[Certificate-Transparency]
Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<https://www.rfc-editor.org/rfc/rfc6962>.
[Double-Ratchet]
Perrin, T., Marlinspike, M., and R. Schmidt, "The Double
Ratchet Algorithm", 4 November 2025,
<https://signal.org/docs/specifications/doubleratchet/>.
[HKP] Shaw, D., Gallagher, A., and D. Huigens, "OpenPGP HTTP
Keyserver Protocol", Work in Progress, Internet-Draft,
draft-gallagher-openpgp-hkp-10, 29 April 2026,
<https://datatracker.ietf.org/doc/html/draft-gallagher-
openpgp-hkp-10>.
[I-D.brown-pgp-pfs]
Brown, I. and B. Laurie, "Forward Secrecy Extensions for
OpenPGP", Work in Progress, Internet-Draft, draft-brown-
Gillmor, et al. Expires 7 January 2027 [Page 29]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
pgp-pfs-03, 8 October 2001,
<https://datatracker.ietf.org/doc/html/draft-brown-pgp-
pfs-03>.
[I-D.dkg-openpgp-stateless-cli]
Gillmor, D. K. and D. Huigens, "Stateless OpenPGP Command
Line Interface", Work in Progress, Internet-Draft, draft-
dkg-openpgp-stateless-cli-16, 26 June 2026,
<https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-
stateless-cli-16>.
[NTP] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/rfc/rfc5905>.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560,
DOI 10.17487/RFC2560, June 1999,
<https://www.rfc-editor.org/rfc/rfc2560>.
[PREKEY-POGO]
Gegenhuber, G., Frenzel, P., Günther, M., and A. Judmayer,
"Prekey Pogo: Investigating Security and Privacy Issues in
WhatsApp's Handshake Mechanism", arXiv,
DOI 10.48550/ARXIV.2504.07323, 2025,
<https://doi.org/10.48550/ARXIV.2504.07323>.
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/rfc/rfc5321>.
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[X.509] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
Gillmor, et al. Expires 7 January 2027 [Page 30]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
Appendix A. Historical notes
Prior work on "forward secrecy" in OpenPGP dates back decades,
including [I-D.brown-pgp-pfs]. 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.
Appendix B. Design Choices
B.1. Subkey Validity Windows
When designing the subkey rotation mechanism, it's possible to create
back-to-back, overlapping, or superset validity windows.
B.1.1. 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.
. .
+----K0----+
' | .
+----K1----+
' | .
+----K2----+
' | .
+----K3----+
' |
+--- ...
. '
Time +---------------------------------------------------------->
'
Figure 4: Back-to-Back Validity Windows
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).
Gillmor, et al. Expires 7 January 2027 [Page 31]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
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.
B.1.2. Overlapping Validity Windows
With overlapping validity windows, each subsequent rotating subkey's
validity starts during the validity window of the prior rotating
subkey.
. .
+-------K0------+
' . ' .
+------K1-------+
' . ' .
+------K2-------+
' . ' .
+------K3-------+
' . '
+-------- ...
. '
Time +---------------------------------------------------------->
'
Figure 5: Overlapping Validity Windows
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).
Gillmor, et al. Expires 7 January 2027 [Page 32]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
The keyholder's UMAs can blindly coordinate subkey distribution by
only distributing subkeys whose validity window is currently active.
B.1.3. Superset Validity Windows
With superset validity windows, each rotating subkey has an identical
creation time, but each subsequent subkey has a later expiration
date.
. .
+----K0----+
| ' .
+---------K1----------+
| ' .
+---------------K2---------------+
| ' .
+----------------------K3-------------------+
| '
+----------------------------------------------- ...
|
Time +---------------------------------------------------------->
'
Figure 6: Superset Validity Windows
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.
B.1.4. Validity Window Conclusion
Decision: better to go with overlapping, so that the common case is a
certificate with only a single rotating subkey.
B.2. 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.
Gillmor, et al. Expires 7 January 2027 [Page 33]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
B.3. 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.
B.4. 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.
B.5. 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.
Appendix C. Test vectors
Gillmor, et al. Expires 7 January 2027 [Page 34]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
C.1. Key and Certificate Created
At 2026-07-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.
-----BEGIN PGP PUBLIC KEY BLOCK-----
xioGakRYfxsAAAAgcRJVRUdqGTNMnwwTeQZv+o8XiaDdVTTpXnjPNH2FR4zCkgYf
GwgAAAAzBYJqRFh/ApsDAh4IIiEGVsEF0JnaJfhSKus9nc+IvOBp9aMRF6K7T1Ya
v6vmHKEDJwkCAAAAADqFENl3uzg/tNOjW2+khGm+tpsVwFezqZ9N64SfSylWouMq
267PJtdf8y+mx3g4BbY0R3N5eTZiIpscbzy8p+PJ5+Hh7edI6p1hrbFxVSY/SjUI
zsQKBmpEWH8jAAAEwMnQyYCYyPLlqXKM8d+oKEe+a1maw5IdqzQRl3fDQA8WlOlA
/Ywqa+MA9Ni7ZMBE9pBRUKefJGZOu2NuNIJSzsB4c1tYPDqrMSR29JqqnOxXpISJ
VOmIxhC1j5VAKqnO4AuJ8zEa3imhDxUr4JORP8eRi5gwkgu8BMQJfDA9kBgeYzQz
x5JMJ5Mh/dW8/WOLdzIE77I8L6dX2NB0v6uAV0A6eFy+LCuivxV/aDRH/9SW1tDG
WocNMYqQ75JkFSpE4RVcYvVBE1iO6XBInjGAm/hSzwE6RglwbpQdy3WaJfYsVuqL
QgRpqZhuKmu18vaij0JGHRhAEDNJuvmBtdgnCneezGtbOPF4zcax5Da+EekANUKh
aClxZjSAFpAcpii0GElEQIpYxaWas6C2fsNxmhsh57d/U0p0SAAiOrmVLrdCC6kp
CNuqRiQ8jAC0+/tmZRe3YVi6lBiNHlVXtcoUCOCH4jWiMAMB04sTb1uz+3EtAJkt
ECDJ5muyIHhCBBQMKBKI9rMCujJfIQApZ1IHq8qOl2G1NfcdGfsUQ9sbnKZRyik6
5FBMIOsco+Q7XppgxyehKSmEpxJfwCtfC6YIosud5GSDOZMzCVQViDUawRk58KII
S8YDRNq9SrdqY9uLx4gq23Jyvfmkald7EsbAaOKbPQNgPaRpJTO7W9QGmFdCL4Kk
O4hOoVZHltq5Pko+/zYQick7kro5pvPDUaVhxuEu/GIlZWNoR9fO4TIItZwmIjwR
5YN0MVC7CyFEaBySPHhYZDdJJ7dj+EKncGts02cO7HmM8WUDPAAELlViZ/k10KjH
5oO+jWM6YBZrkLOPVngJSMB43EpJICeYSsGc2qCNK5NMtLvNSGsvsuUdr/WDtANT
rWI2XOw9oVs9APpuiKrHT+OGQTKnK+lKhUlJMEV6Iqt/6jt2ereLCzgls8B1fceG
6disSDiz6jKn/1APsSInlcsQqyR8MwoaE5g1tKx8SGFL3xK3VvMrSMED/8g4bsGa
yfEOM7lKrOIrv8nCyXrINOdrW5SgmmmOl2GR63l0qdybFsqZ0BFmlWWlTRFKekRo
meMB21yZXbc/qVhqILS41oYtUhSxFjBBbClKcAlHIzxNJeJaofALanq2VbKEbnBT
pCm+0HhH8Xu+/ACtZew8QliFrcoRsPM2zcy/nqPAN4QsvRFkykoDiDcId3cjwfAA
EKWKIshR5jNZoSwS+fcKcGk1hoYBhVY0WhQiZTSwNZsOOqaujNNhLgKZ5bebExqz
AkIrEhozfSS0ZBtzjCs1IMRchHOhzgpv3HWl0ZuwtxKu9MY1h+dOjbqxFai7IwOs
3xC0PMN03GIWkcNL8UACrLNEFPW6sVwE1ROXcTy5Lde63WsmxipfJEtdWfEqrvxZ
97yDKfRMGILApbY2CFuAPkYLiQd+lFGwytNxYbqI7pJKOdlVZ5s/7kBhlCwSedZ9
1uK/3JijNotlNrt/7atasaSk2kKjFpRGpUvArJRJGdVJszm5sBZ0PTWn94Zxunaz
ICo15jhCENG++qdEJ6ZbGHwMX8O7LWNXHUClYtRVTUR0mSFE2mwxLPFeeRJlIOkY
FzqWfDCMwXTwl1BLbyLQWhk/JW9MNw+ewkrxPD7CiwYYGwgAAAAsBYJqRFh/ApsM
IiEGVsEF0JnaJfhSKus9nc+IvOBp9aMRF6K7T1Yav6vmHKEAAAAAuV0Qz5l1AOOR
vovCj4Bu3eC92HlxHDLjXEZq/38loDYMHyjrUBUxYFOr1tWqk8dsonwGn/hEzsW+
4T/1SDccLQchb/vD4GUd4v2JFW6eKNY+8wTOxAoGakVPeSMAAATAmCRkirW5CYNd
ucEJs50OewXTIDpd+1BRD883x65KmmpbY8VABXdlc4unIE7ynMNXTJvWkV8jUE3H
URen4k9UUlzRkF3uwKh46VCn94Shmw7rs5wU44QXc7ays0Ypa3XFVnjoMEo+C8N5
NqLQipIHpmJjgEjVGh8/E10g5FCTc2sx8XAjdzxpbLRclKagpAUlabPjYIOowoOI
Gillmor, et al. Expires 7 January 2027 [Page 35]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
ZTs9Cx05wgy491pEcFUvWAWbdLbxVh9tq1MdV2FJdiU8OhvIg2LHdK2KAK7h8gBQ
waSIy0n+mhy/1HJ3gcf8FxTKfMQPAh2Ym0W5oVqc1HTYAlEucgKVZZl55TX1bDnd
9QDr52rNEcf5FFIySbxZbDc/ummER8T6oIXXmbLtURKdind4WStWV4XEBGEvoB2g
65igKI+vl8bH8z0V2XznScIfKM5qNEm1e5JcugGaew9BxaNKuot6dLT+8n7IoTqO
LHQzg5SxccCNWsLStwHbQ2I2OXYPQCleRMwbOIDrUIsFqQzXd4nZN6S0y3gFOYig
Qcmmljx5A24eaam4pJ0I4APVlYnRypCyKWrMyiOYrKQZy3cYoUpycMMKwXR2YS9q
QawPI57Wso67KsQAjYvWB397t0sRzE3FF6eRwlkIZly32rJ86MDJ4FXoQWkE2YTG
Jrh3Co8K2cWWJYjzPDdAMJ6LksEb3LXYcGPhGT1mJaGY6wWLG083oJpIeDFMXBOe
CRfO5ouqRR8196wRySod5kRKKgKiqy4PIiLzIQCuSLcnCUBwqX47FLQBkbvG0M+c
sK6N1ykFVjCed4CDMyf5Acho8nH96XbdunPWWXzyas2boiLDx8HoQDdpkXepucWN
SQ+uoLViZLyW9Ypa+2mMCHroyRnJUywu1yUNpIB+x7KW4Fx0YD8kShJq1WBEuEH8
Am19mmUkk7ljBsdLG5o5QwkxiASBRWu42IH6hcF1q5TxZqwBmDxj5AKqUxDoyBLl
3EEdlnz/+MzwcAPxZQU/+VeEdbTHfLUI1CXtJCpVSMjJ83poSxPtfHx0Anc41wcT
+IRp8BJZtF2QCgZC8Q3I2rtsE7nIt4pZRYV0RbGvwMxznH2Z97P1cCmyccYJaXGW
kghwNb6dcInPtXr81WRxcIBx44ggWgFwkLdSho68pmg60cWcioEKxGwBBIcaQq+p
JDDoqVC2AU8cATkHdZhzrI8aRXffWX4xsJ0/4a/1NI0F0mxvZRfO1Qjg0ofYpkPS
OmnyjDlYKCmZRKvzlYkv0LL0V6RhCw2uaKDhg3siZzgfBUocGwZ8kaTY7K/60qC4
x5oqIlnctCN58chMOHU7YGNzaUCvgbUTUWsHIGt7yLf+AikpmTq9IjkyjLkuak0b
VCQpEwHyBSiRVqo2CFmGdzU6wR8dAFiusQfLYCLF8X85l4DkEYpwsYitUIs+PMB2
UoOVu1ZJhbB20rrmTMSZ92EGuBivy4rJos5tI3t7Z8gRkD9N2LymR3xT2xgv9p+R
NxglSM2WlxMzED/MqDq20apCd5pBQTdEq7ep3BTGtAtO5a2Y8sxrmcqD4TsPN7Cm
MVdSUXno9U1RKjKgOI+Xwn7MXAsNJ0df2ZnmozWT1I66ccOovlX5XMlghOsmtPBD
iZiJLCICOcKRBhgbCAAAADIFgmpFT3kFiQANLwACmwQiIQZWwQXQmdol+FIq6z2d
z4i84Gn1oxEXortPVhq/q+YcoQAAAAAcPRDjNtQHkZBvJC02Qn1fsEFWdrHIbvPZ
XkrPWa5CkP2yb2TMdEH8pqp3bIGapgzDoyvWZzlcBK6xxF+AVQqSrwOaHYx/Ahht
nMSP0IHrw5wmCQ==
-----END PGP PUBLIC KEY BLOCK-----
C.1.2. Initial TSK
This secret key is made available only to the keyholder's own
devices.
-----BEGIN PGP PRIVATE KEY BLOCK-----
xUsGakRYfxsAAAAgcRJVRUdqGTNMnwwTeQZv+o8XiaDdVTTpXnjPNH2FR4wAET8I
Q3fQeNm71dOZSkB/260JmbL1QIX/q4ugYzBOFKLCkgYfGwgAAAAzBYJqRFh/ApsD
Ah4IIiEGVsEF0JnaJfhSKus9nc+IvOBp9aMRF6K7T1Yav6vmHKEDJwkCAAAAADqF
ENl3uzg/tNOjW2+khGm+tpsVwFezqZ9N64SfSylWouMq267PJtdf8y+mx3g4BbY0
R3N5eTZiIpscbzy8p+PJ5+Hh7edI6p1hrbFxVSY/SjUIx8RrBmpEWH8jAAAEwMnQ
yYCYyPLlqXKM8d+oKEe+a1maw5IdqzQRl3fDQA8WlOlA/Ywqa+MA9Ni7ZMBE9pBR
UKefJGZOu2NuNIJSzsB4c1tYPDqrMSR29JqqnOxXpISJVOmIxhC1j5VAKqnO4AuJ
8zEa3imhDxUr4JORP8eRi5gwkgu8BMQJfDA9kBgeYzQzx5JMJ5Mh/dW8/WOLdzIE
77I8L6dX2NB0v6uAV0A6eFy+LCuivxV/aDRH/9SW1tDGWocNMYqQ75JkFSpE4RVc
YvVBE1iO6XBInjGAm/hSzwE6RglwbpQdy3WaJfYsVuqLQgRpqZhuKmu18vaij0JG
HRhAEDNJuvmBtdgnCneezGtbOPF4zcax5Da+EekANUKhaClxZjSAFpAcpii0GElE
QIpYxaWas6C2fsNxmhsh57d/U0p0SAAiOrmVLrdCC6kpCNuqRiQ8jAC0+/tmZRe3
YVi6lBiNHlVXtcoUCOCH4jWiMAMB04sTb1uz+3EtAJktECDJ5muyIHhCBBQMKBKI
Gillmor, et al. Expires 7 January 2027 [Page 36]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
9rMCujJfIQApZ1IHq8qOl2G1NfcdGfsUQ9sbnKZRyik65FBMIOsco+Q7Xppgxyeh
KSmEpxJfwCtfC6YIosud5GSDOZMzCVQViDUawRk58KIIS8YDRNq9SrdqY9uLx4gq
23Jyvfmkald7EsbAaOKbPQNgPaRpJTO7W9QGmFdCL4KkO4hOoVZHltq5Pko+/zYQ
ick7kro5pvPDUaVhxuEu/GIlZWNoR9fO4TIItZwmIjwR5YN0MVC7CyFEaBySPHhY
ZDdJJ7dj+EKncGts02cO7HmM8WUDPAAELlViZ/k10KjH5oO+jWM6YBZrkLOPVngJ
SMB43EpJICeYSsGc2qCNK5NMtLvNSGsvsuUdr/WDtANTrWI2XOw9oVs9APpuiKrH
T+OGQTKnK+lKhUlJMEV6Iqt/6jt2ereLCzgls8B1fceG6disSDiz6jKn/1APsSIn
lcsQqyR8MwoaE5g1tKx8SGFL3xK3VvMrSMED/8g4bsGayfEOM7lKrOIrv8nCyXrI
NOdrW5SgmmmOl2GR63l0qdybFsqZ0BFmlWWlTRFKekRomeMB21yZXbc/qVhqILS4
1oYtUhSxFjBBbClKcAlHIzxNJeJaofALanq2VbKEbnBTpCm+0HhH8Xu+/ACtZew8
QliFrcoRsPM2zcy/nqPAN4QsvRFkykoDiDcId3cjwfAAEKWKIshR5jNZoSwS+fcK
cGk1hoYBhVY0WhQiZTSwNZsOOqaujNNhLgKZ5bebExqzAkIrEhozfSS0ZBtzjCs1
IMRchHOhzgpv3HWl0ZuwtxKu9MY1h+dOjbqxFai7IwOs3xC0PMN03GIWkcNL8UAC
rLNEFPW6sVwE1ROXcTy5Lde63WsmxipfJEtdWfEqrvxZ97yDKfRMGILApbY2CFuA
PkYLiQd+lFGwytNxYbqI7pJKOdlVZ5s/7kBhlCwSedZ91uK/3JijNotlNrt/7ata
saSk2kKjFpRGpUvArJRJGdVJszm5sBZ0PTWn94ZxunazICo15jhCENG++qdEJ6Zb
GHwMX8O7LWNXHUClYtRVTUR0mSFE2mwxLPFeeRJlIOkYFzqWfDCMwXTwl1BLbyLQ
Whk/JW9MNw+ewkrxPD4AaGZh9fcInOX2yYpJXNKEnHCNh08uWEosBWRDzpeOVGja
b3dBAAafhaFGEhx4WqVYOan5ZDw/WNqlTVIRdLWvDuQjHvRMLCoqgQ/E+04G6uS6
arNh3q8Bzija4mELayyhwosGGBsIAAAALAWCakRYfwKbDCIhBlbBBdCZ2iX4Uirr
PZ3PiLzgafWjEReiu09WGr+r5hyhAAAAALldEM+ZdQDjkb6Lwo+Abt3gvdh5cRwy
41xGav9/JaA2DB8o61AVMWBTq9bVqpPHbKJ8Bp/4RM7FvuE/9Ug3HC0HIW/7w+Bl
HeL9iRVunijWPvMEx8RrBmpFT3kjAAAEwJgkZIq1uQmDXbnBCbOdDnsF0yA6XftQ
UQ/PN8euSppqW2PFQAV3ZXOLpyBO8pzDV0yb1pFfI1BNx1EXp+JPVFJc0ZBd7sCo
eOlQp/eEoZsO67OcFOOEF3O2srNGKWt1xVZ46DBKPgvDeTai0IqSB6ZiY4BI1Rof
PxNdIORQk3NrMfFwI3c8aWy0XJSmoKQFJWmz42CDqMKDiGU7PQsdOcIMuPdaRHBV
L1gFm3S28VYfbatTHVdhSXYlPDobyINix3StigCu4fIAUMGkiMtJ/pocv9Ryd4HH
/BcUynzEDwIdmJtFuaFanNR02AJRLnIClWWZeeU19Ww53fUA6+dqzRHH+RRSMkm8
WWw3P7pphEfE+qCF15my7VESnYp3eFkrVleFxARhL6AdoOuYoCiPr5fGx/M9Fdl8
50nCHyjOajRJtXuSXLoBmnsPQcWjSrqLenS0/vJ+yKE6jix0M4OUsXHAjVrC0rcB
20NiNjl2D0ApXkTMGziA61CLBakM13eJ2TektMt4BTmIoEHJppY8eQNuHmmpuKSd
COAD1ZWJ0cqQsilqzMojmKykGct3GKFKcnDDCsF0dmEvakGsDyOe1rKOuyrEAI2L
1gd/e7dLEcxNxRenkcJZCGZct9qyfOjAyeBV6EFpBNmExia4dwqPCtnFliWI8zw3
QDCei5LBG9y12HBj4Rk9ZiWhmOsFixtPN6CaSHgxTFwTngkXzuaLqkUfNfesEckq
HeZESioCoqsuDyIi8yEArki3JwlAcKl+OxS0AZG7xtDPnLCujdcpBVYwnneAgzMn
+QHIaPJx/el23bpz1ll88mrNm6Iiw8fB6EA3aZF3qbnFjUkPrqC1YmS8lvWKWvtp
jAh66MkZyVMsLtclDaSAfseyluBcdGA/JEoSatVgRLhB/AJtfZplJJO5YwbHSxua
OUMJMYgEgUVruNiB+oXBdauU8WasAZg8Y+QCqlMQ6MgS5dxBHZZ8//jM8HAD8WUF
P/lXhHW0x3y1CNQl7SQqVUjIyfN6aEsT7Xx8dAJ3ONcHE/iEafASWbRdkAoGQvEN
yNq7bBO5yLeKWUWFdEWxr8DMc5x9mfez9XApsnHGCWlxlpIIcDW+nXCJz7V6/NVk
cXCAceOIIFoBcJC3UoaOvKZoOtHFnIqBCsRsAQSHGkKvqSQw6KlQtgFPHAE5B3WY
c6yPGkV331l+MbCdP+Gv9TSNBdJsb2UXztUI4NKH2KZD0jpp8ow5WCgpmUSr85WJ
L9Cy9FekYQsNrmig4YN7Imc4HwVKHBsGfJGk2Oyv+tKguMeaKiJZ3LQjefHITDh1
O2Bjc2lAr4G1E1FrByBre8i3/gIpKZk6vSI5Moy5LmpNG1QkKRMB8gUokVaqNghZ
hnc1OsEfHQBYrrEHy2AixfF/OZeA5BGKcLGIrVCLPjzAdlKDlbtWSYWwdtK65kzE
mfdhBrgYr8uKyaLObSN7e2fIEZA/Tdi8pkd8U9sYL/afkTcYJUjNlpcTMxA/zKg6
ttGqQneaQUE3RKu3qdwUxrQLTuWtmPLMa5nKg+E7DzewpjFXUlF56PVNUSoyoDiP
l8J+zFwLDSdHX9mZ5qM1k9SOunHDqL5V+VzJYITrJrTwQ4mYiSwiAjkAoNfHW/ZS
Gillmor, et al. Expires 7 January 2027 [Page 37]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
GRonYC/yjFWxppDkkws8HKbdm4ncr6jhGHKcrDYOdOJcnNaNqffg0un/l4Fm9n4J
yoKSFRdc3rktMaRVYkYyKsxQrDHrtmZhYMLox9t1djjZah5GvxE/eZguwpEGGBsI
AAAAMgWCakVPeQWJAA0vAAKbBCIhBlbBBdCZ2iX4UirrPZ3PiLzgafWjEReiu09W
Gr+r5hyhAAAAABw9EOM21AeRkG8kLTZCfV+wQVZ2schu89leSs9ZrkKQ/bJvZMx0
QfymqndsgZqmDMOjK9ZnOVwErrHEX4BVCpKvA5odjH8CGG2cxI/QgevDnCYJ
-----END PGP PRIVATE KEY BLOCK-----
C.2. 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 Section 4.1.1,
with the following parameters:
Salt:
000 6a 4b e6 f9 ce c4 0a 06 6a 45 4f 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
Gillmor, et al. Expires 7 January 2027 [Page 38]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
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
Gillmor, et al. Expires 7 January 2027 [Page 39]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
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 6a 44 58 7f 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 0b 3a 6d 0c 6c 5c 0f ec 73 59 a8 6b dc 1d 7e 11
010 c7 6c 3d 9d 80 65 75 40 26 73 a6 68 17 17 f5 e2
020 a2 62 b9 2f 65 5e 59 1e 9b 20 ed 63 89 64 6e 8e
030 66 b9 9f dd 3c b2 f7 0b 66 6b 6a f0 69 27 17 3c
040 a0 69 66 14 26 34 1b 83 50 f4 a2 13 db 9c 57 26
050 13 66 75 42 06 14 d8 51 b3 2d 8f 00 b9 02 27 87
060 36 d9 3c 09 48 8e c9 a0 ea ee c5 50 ca 17 24 61
070 c5 10 d5 98 e6 ee c7 a6 c1 f7 5b 6f 00 27 50 e9
080 35 9c e4 c7 8d a7 a6 88 d7 91 10 4a 2e 77 d3 57
090 c6 32 bd 80 f2 77 0d 0a ba e4 c5 9b 56 64 d8 ea
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 2026-07-06T17:33:45Z.
Gillmor, et al. Expires 7 January 2027 [Page 40]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
-----BEGIN PGP PUBLIC KEY BLOCK-----
xioGakRYfxsAAAAgcRJVRUdqGTNMnwwTeQZv+o8XiaDdVTTpXnjPNH2FR4zCkgYf
GwgAAAAzBYJqRFh/ApsDAh4IIiEGVsEF0JnaJfhSKus9nc+IvOBp9aMRF6K7T1Ya
v6vmHKEDJwkCAAAAADqFENl3uzg/tNOjW2+khGm+tpsVwFezqZ9N64SfSylWouMq
267PJtdf8y+mx3g4BbY0R3N5eTZiIpscbzy8p+PJ5+Hh7edI6p1hrbFxVSY/SjUI
zsQKBmpEWH8jAAAEwMnQyYCYyPLlqXKM8d+oKEe+a1maw5IdqzQRl3fDQA8WlOlA
/Ywqa+MA9Ni7ZMBE9pBRUKefJGZOu2NuNIJSzsB4c1tYPDqrMSR29JqqnOxXpISJ
VOmIxhC1j5VAKqnO4AuJ8zEa3imhDxUr4JORP8eRi5gwkgu8BMQJfDA9kBgeYzQz
x5JMJ5Mh/dW8/WOLdzIE77I8L6dX2NB0v6uAV0A6eFy+LCuivxV/aDRH/9SW1tDG
WocNMYqQ75JkFSpE4RVcYvVBE1iO6XBInjGAm/hSzwE6RglwbpQdy3WaJfYsVuqL
QgRpqZhuKmu18vaij0JGHRhAEDNJuvmBtdgnCneezGtbOPF4zcax5Da+EekANUKh
aClxZjSAFpAcpii0GElEQIpYxaWas6C2fsNxmhsh57d/U0p0SAAiOrmVLrdCC6kp
CNuqRiQ8jAC0+/tmZRe3YVi6lBiNHlVXtcoUCOCH4jWiMAMB04sTb1uz+3EtAJkt
ECDJ5muyIHhCBBQMKBKI9rMCujJfIQApZ1IHq8qOl2G1NfcdGfsUQ9sbnKZRyik6
5FBMIOsco+Q7XppgxyehKSmEpxJfwCtfC6YIosud5GSDOZMzCVQViDUawRk58KII
S8YDRNq9SrdqY9uLx4gq23Jyvfmkald7EsbAaOKbPQNgPaRpJTO7W9QGmFdCL4Kk
O4hOoVZHltq5Pko+/zYQick7kro5pvPDUaVhxuEu/GIlZWNoR9fO4TIItZwmIjwR
5YN0MVC7CyFEaBySPHhYZDdJJ7dj+EKncGts02cO7HmM8WUDPAAELlViZ/k10KjH
5oO+jWM6YBZrkLOPVngJSMB43EpJICeYSsGc2qCNK5NMtLvNSGsvsuUdr/WDtANT
rWI2XOw9oVs9APpuiKrHT+OGQTKnK+lKhUlJMEV6Iqt/6jt2ereLCzgls8B1fceG
6disSDiz6jKn/1APsSInlcsQqyR8MwoaE5g1tKx8SGFL3xK3VvMrSMED/8g4bsGa
yfEOM7lKrOIrv8nCyXrINOdrW5SgmmmOl2GR63l0qdybFsqZ0BFmlWWlTRFKekRo
meMB21yZXbc/qVhqILS41oYtUhSxFjBBbClKcAlHIzxNJeJaofALanq2VbKEbnBT
pCm+0HhH8Xu+/ACtZew8QliFrcoRsPM2zcy/nqPAN4QsvRFkykoDiDcId3cjwfAA
EKWKIshR5jNZoSwS+fcKcGk1hoYBhVY0WhQiZTSwNZsOOqaujNNhLgKZ5bebExqz
AkIrEhozfSS0ZBtzjCs1IMRchHOhzgpv3HWl0ZuwtxKu9MY1h+dOjbqxFai7IwOs
3xC0PMN03GIWkcNL8UACrLNEFPW6sVwE1ROXcTy5Lde63WsmxipfJEtdWfEqrvxZ
97yDKfRMGILApbY2CFuAPkYLiQd+lFGwytNxYbqI7pJKOdlVZ5s/7kBhlCwSedZ9
1uK/3JijNotlNrt/7atasaSk2kKjFpRGpUvArJRJGdVJszm5sBZ0PTWn94Zxunaz
ICo15jhCENG++qdEJ6ZbGHwMX8O7LWNXHUClYtRVTUR0mSFE2mwxLPFeeRJlIOkY
FzqWfDCMwXTwl1BLbyLQWhk/JW9MNw+ewkrxPD7CiwYYGwgAAAAsBYJqRFh/ApsM
IiEGVsEF0JnaJfhSKus9nc+IvOBp9aMRF6K7T1Yav6vmHKEAAAAAuV0Qz5l1AOOR
vovCj4Bu3eC92HlxHDLjXEZq/38loDYMHyjrUBUxYFOr1tWqk8dsonwGn/hEzsW+
4T/1SDccLQchb/vD4GUd4v2JFW6eKNY+8wTOxAoGakvm+SMAAATApzmMW/yCk3LT
TS1nkQLD+Ua4hYNAJpEqhlmXXgHAj0JBiFbWxLPfy0jbEFDlrMBVhXKggbwVtwYz
cbSGBy2i3KlxIpYUsDwg5BVdGo2xG3RwHEObMVAPgSfcsXwGMXkcXK2Yp7e4W07l
MHh2Ob5guXZN+HWw40ql9j2qcMdY0lhfIwAVR0Olo3kLXMMp0k/U1Mj7bA26QcSt
o04Pcm9VwXdsMlOMe7MBWVY/C3+6wyIk9rMGO6sOFkVPyHmdCXUB2KWwOIjQUiwl
Jis9CpRE5603UBJr26k1GMPRJK0L2T7yZ5ELI1Ee67FqSD+OWBMLhqaL7AI+ylcZ
arpcErQs7IflfDm0py2wuHgDOiQnaRN3aA66hgr0K4pZ8zO1UM2RRB4bNqhv4LE+
kyiwaQLNA8OV/Enmk7ax5EF3ADlIto0o5VqmqVRUUHLtGTRbClUvoTe5fBBU+C1O
AlRXaE3NoiTOhrGd+C4jqXX1AKPFmBE+Cjv5Z2tSWn1rdHk1oKIoaQn8OqaJoA/5
K8jPhxpjQU3fSBL7MANSU2C3GhwmMML8ccgwR3Ve2I9B9K9tKjm0oJdQ2QsqdA3j
4DaP8aMyElGOJpB/0W7d6xbNc7SLcYltpMGiqZObWwd8BFsAKoArkahMhgQQvKfa
CkWO4nOMDMKF5MiDUVNkyZCyAg7wuFBYmxsxpHaKwphSIsTliHaxQkUaJxRa4gVB
66ppumZmgWBxMTV1JWNQ5K6BE0ma0RIXmEQGu7SwW2+eInZYnG7wYVjtpSDvRQul
45Dw5AFjMLSWF5rxEjT2Cw9Mpk75cFAsEwRH9Gj7YoULt46vB4/DYykAYIYKwWyf
Gillmor, et al. Expires 7 January 2027 [Page 41]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
67+RWjWs2M1/hFBP5T0/y1LMU2bOkmspKxmgqzMIu3Blt8/JomXhGwD8czl20rFV
IgG6cT+xQVhCsxp1pbAtS2MMopF85RQQGZiWihdPhR8VIApRQD+W9AWiFYu82jin
jInh6kWPh6VJZ51F2V6tRh4RNIlAiY9IOwLShXTPIE3hO5McIlBFcnk5RVZ8QwsF
AFqxlVjfiWtIaRpuyW+0tRM7NitW9mT8RiTVNAKoegV9GMvphsXJ60Uhuo5yC5tC
dY/PNz1hGpi19RdVl0NoC4KVxF8243vUpI0DIQeAkkAJGhK6WnoAjK+dxgitm6yP
2DI9e8048l7v63iD97EH42pq1iDYICaNBshMMAL3nK+UBCdW6b90GIO3+CGtlGod
YMPsLI1VcVbVUQVv8E0C5j20SDakC3a7MIaeykeSuJKXaK1apm6rl3PBBmQGWEI9
Fyw2eamj90HulMfT2EMBQE/St5yt1QHl8H49yWnocR7qZXgtRU70h3x7M1jS44fr
4WaZVrTqasOGnE4wCFGzZmBx12k3lWyhZ3yx9gNiQSTAmDL3/BMz6avUbJ1wHHSC
a6spNXD0SzV8FYMHUxCnpJDUpX+TNImisUoFhnF6izgEFRAFBZeu60OedmUEoVtW
/H+d9rZus4J/FVAIwwzbys3cyqjtRB9g+l4X0zqvak3a5bX8uGx/l00Id5cTgRqF
y5TaSSZ5C5L/WgOB4h9m6LqBYSLP4kUEiBz1Z8F6F/qs0WfL2DLWCoMPX7sd7bXZ
OEI21oczw8KRBhgbCAAAADIFgmpL5vkFiQANLwACmwQiIQZWwQXQmdol+FIq6z2d
z4i84Gn1oxEXortPVhq/q+YcoQAAAAChlBCFOtHzS6ZbYgNa4t1Lbw/WOHl6TW+W
S49juf+HbDngK7OLH8myXJtTvFWR8OVA+IG8Re0hRtqYVYnvl/jMPFw6PWwU44X9
jNEWMnF7vyOfBA==
-----END PGP PUBLIC KEY BLOCK-----
C.2.2. TSK With New Subkey
Every device of the keyholder should be able to derive this exact
secret key from the TSK found in Appendix C.1.2.
-----BEGIN PGP PRIVATE KEY BLOCK-----
xUsGakRYfxsAAAAgcRJVRUdqGTNMnwwTeQZv+o8XiaDdVTTpXnjPNH2FR4wAET8I
Q3fQeNm71dOZSkB/260JmbL1QIX/q4ugYzBOFKLCkgYfGwgAAAAzBYJqRFh/ApsD
Ah4IIiEGVsEF0JnaJfhSKus9nc+IvOBp9aMRF6K7T1Yav6vmHKEDJwkCAAAAADqF
ENl3uzg/tNOjW2+khGm+tpsVwFezqZ9N64SfSylWouMq267PJtdf8y+mx3g4BbY0
R3N5eTZiIpscbzy8p+PJ5+Hh7edI6p1hrbFxVSY/SjUIx8RrBmpEWH8jAAAEwMnQ
yYCYyPLlqXKM8d+oKEe+a1maw5IdqzQRl3fDQA8WlOlA/Ywqa+MA9Ni7ZMBE9pBR
UKefJGZOu2NuNIJSzsB4c1tYPDqrMSR29JqqnOxXpISJVOmIxhC1j5VAKqnO4AuJ
8zEa3imhDxUr4JORP8eRi5gwkgu8BMQJfDA9kBgeYzQzx5JMJ5Mh/dW8/WOLdzIE
77I8L6dX2NB0v6uAV0A6eFy+LCuivxV/aDRH/9SW1tDGWocNMYqQ75JkFSpE4RVc
YvVBE1iO6XBInjGAm/hSzwE6RglwbpQdy3WaJfYsVuqLQgRpqZhuKmu18vaij0JG
HRhAEDNJuvmBtdgnCneezGtbOPF4zcax5Da+EekANUKhaClxZjSAFpAcpii0GElE
QIpYxaWas6C2fsNxmhsh57d/U0p0SAAiOrmVLrdCC6kpCNuqRiQ8jAC0+/tmZRe3
YVi6lBiNHlVXtcoUCOCH4jWiMAMB04sTb1uz+3EtAJktECDJ5muyIHhCBBQMKBKI
9rMCujJfIQApZ1IHq8qOl2G1NfcdGfsUQ9sbnKZRyik65FBMIOsco+Q7Xppgxyeh
KSmEpxJfwCtfC6YIosud5GSDOZMzCVQViDUawRk58KIIS8YDRNq9SrdqY9uLx4gq
23Jyvfmkald7EsbAaOKbPQNgPaRpJTO7W9QGmFdCL4KkO4hOoVZHltq5Pko+/zYQ
ick7kro5pvPDUaVhxuEu/GIlZWNoR9fO4TIItZwmIjwR5YN0MVC7CyFEaBySPHhY
ZDdJJ7dj+EKncGts02cO7HmM8WUDPAAELlViZ/k10KjH5oO+jWM6YBZrkLOPVngJ
SMB43EpJICeYSsGc2qCNK5NMtLvNSGsvsuUdr/WDtANTrWI2XOw9oVs9APpuiKrH
T+OGQTKnK+lKhUlJMEV6Iqt/6jt2ereLCzgls8B1fceG6disSDiz6jKn/1APsSIn
lcsQqyR8MwoaE5g1tKx8SGFL3xK3VvMrSMED/8g4bsGayfEOM7lKrOIrv8nCyXrI
NOdrW5SgmmmOl2GR63l0qdybFsqZ0BFmlWWlTRFKekRomeMB21yZXbc/qVhqILS4
1oYtUhSxFjBBbClKcAlHIzxNJeJaofALanq2VbKEbnBTpCm+0HhH8Xu+/ACtZew8
Gillmor, et al. Expires 7 January 2027 [Page 42]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
QliFrcoRsPM2zcy/nqPAN4QsvRFkykoDiDcId3cjwfAAEKWKIshR5jNZoSwS+fcK
cGk1hoYBhVY0WhQiZTSwNZsOOqaujNNhLgKZ5bebExqzAkIrEhozfSS0ZBtzjCs1
IMRchHOhzgpv3HWl0ZuwtxKu9MY1h+dOjbqxFai7IwOs3xC0PMN03GIWkcNL8UAC
rLNEFPW6sVwE1ROXcTy5Lde63WsmxipfJEtdWfEqrvxZ97yDKfRMGILApbY2CFuA
PkYLiQd+lFGwytNxYbqI7pJKOdlVZ5s/7kBhlCwSedZ91uK/3JijNotlNrt/7ata
saSk2kKjFpRGpUvArJRJGdVJszm5sBZ0PTWn94ZxunazICo15jhCENG++qdEJ6Zb
GHwMX8O7LWNXHUClYtRVTUR0mSFE2mwxLPFeeRJlIOkYFzqWfDCMwXTwl1BLbyLQ
Whk/JW9MNw+ewkrxPD4AaGZh9fcInOX2yYpJXNKEnHCNh08uWEosBWRDzpeOVGja
b3dBAAafhaFGEhx4WqVYOan5ZDw/WNqlTVIRdLWvDuQjHvRMLCoqgQ/E+04G6uS6
arNh3q8Bzija4mELayyhwosGGBsIAAAALAWCakRYfwKbDCIhBlbBBdCZ2iX4Uirr
PZ3PiLzgafWjEReiu09WGr+r5hyhAAAAALldEM+ZdQDjkb6Lwo+Abt3gvdh5cRwy
41xGav9/JaA2DB8o61AVMWBTq9bVqpPHbKJ8Bp/4RM7FvuE/9Ug3HC0HIW/7w+Bl
HeL9iRVunijWPvMEx8RrBmpFT3kjAAAEwJgkZIq1uQmDXbnBCbOdDnsF0yA6XftQ
UQ/PN8euSppqW2PFQAV3ZXOLpyBO8pzDV0yb1pFfI1BNx1EXp+JPVFJc0ZBd7sCo
eOlQp/eEoZsO67OcFOOEF3O2srNGKWt1xVZ46DBKPgvDeTai0IqSB6ZiY4BI1Rof
PxNdIORQk3NrMfFwI3c8aWy0XJSmoKQFJWmz42CDqMKDiGU7PQsdOcIMuPdaRHBV
L1gFm3S28VYfbatTHVdhSXYlPDobyINix3StigCu4fIAUMGkiMtJ/pocv9Ryd4HH
/BcUynzEDwIdmJtFuaFanNR02AJRLnIClWWZeeU19Ww53fUA6+dqzRHH+RRSMkm8
WWw3P7pphEfE+qCF15my7VESnYp3eFkrVleFxARhL6AdoOuYoCiPr5fGx/M9Fdl8
50nCHyjOajRJtXuSXLoBmnsPQcWjSrqLenS0/vJ+yKE6jix0M4OUsXHAjVrC0rcB
20NiNjl2D0ApXkTMGziA61CLBakM13eJ2TektMt4BTmIoEHJppY8eQNuHmmpuKSd
COAD1ZWJ0cqQsilqzMojmKykGct3GKFKcnDDCsF0dmEvakGsDyOe1rKOuyrEAI2L
1gd/e7dLEcxNxRenkcJZCGZct9qyfOjAyeBV6EFpBNmExia4dwqPCtnFliWI8zw3
QDCei5LBG9y12HBj4Rk9ZiWhmOsFixtPN6CaSHgxTFwTngkXzuaLqkUfNfesEckq
HeZESioCoqsuDyIi8yEArki3JwlAcKl+OxS0AZG7xtDPnLCujdcpBVYwnneAgzMn
+QHIaPJx/el23bpz1ll88mrNm6Iiw8fB6EA3aZF3qbnFjUkPrqC1YmS8lvWKWvtp
jAh66MkZyVMsLtclDaSAfseyluBcdGA/JEoSatVgRLhB/AJtfZplJJO5YwbHSxua
OUMJMYgEgUVruNiB+oXBdauU8WasAZg8Y+QCqlMQ6MgS5dxBHZZ8//jM8HAD8WUF
P/lXhHW0x3y1CNQl7SQqVUjIyfN6aEsT7Xx8dAJ3ONcHE/iEafASWbRdkAoGQvEN
yNq7bBO5yLeKWUWFdEWxr8DMc5x9mfez9XApsnHGCWlxlpIIcDW+nXCJz7V6/NVk
cXCAceOIIFoBcJC3UoaOvKZoOtHFnIqBCsRsAQSHGkKvqSQw6KlQtgFPHAE5B3WY
c6yPGkV331l+MbCdP+Gv9TSNBdJsb2UXztUI4NKH2KZD0jpp8ow5WCgpmUSr85WJ
L9Cy9FekYQsNrmig4YN7Imc4HwVKHBsGfJGk2Oyv+tKguMeaKiJZ3LQjefHITDh1
O2Bjc2lAr4G1E1FrByBre8i3/gIpKZk6vSI5Moy5LmpNG1QkKRMB8gUokVaqNghZ
hnc1OsEfHQBYrrEHy2AixfF/OZeA5BGKcLGIrVCLPjzAdlKDlbtWSYWwdtK65kzE
mfdhBrgYr8uKyaLObSN7e2fIEZA/Tdi8pkd8U9sYL/afkTcYJUjNlpcTMxA/zKg6
ttGqQneaQUE3RKu3qdwUxrQLTuWtmPLMa5nKg+E7DzewpjFXUlF56PVNUSoyoDiP
l8J+zFwLDSdHX9mZ5qM1k9SOunHDqL5V+VzJYITrJrTwQ4mYiSwiAjkAoNfHW/ZS
GRonYC/yjFWxppDkkws8HKbdm4ncr6jhGHKcrDYOdOJcnNaNqffg0un/l4Fm9n4J
yoKSFRdc3rktMaRVYkYyKsxQrDHrtmZhYMLox9t1djjZah5GvxE/eZguwpEGGBsI
AAAAMgWCakVPeQWJAA0vAAKbBCIhBlbBBdCZ2iX4UirrPZ3PiLzgafWjEReiu09W
Gr+r5hyhAAAAABw9EOM21AeRkG8kLTZCfV+wQVZ2schu89leSs9ZrkKQ/bJvZMx0
QfymqndsgZqmDMOjK9ZnOVwErrHEX4BVCpKvA5odjH8CGG2cxI/QgevDnCYJx8Rr
BmpL5vkjAAAEwKc5jFv8gpNy000tZ5ECw/lGuIWDQCaRKoZZl14BwI9CQYhW1sSz
38tI2xBQ5azAVYVyoIG8FbcGM3G0hgctotypcSKWFLA8IOQVXRqNsRt0cBxDmzFQ
D4En3LF8BjF5HFytmKe3uFtO5TB4djm+YLl2Tfh1sONKpfY9qnDHWNJYXyMAFUdD
paN5C1zDKdJP1NTI+2wNukHEraNOD3JvVcF3bDJTjHuzAVlWPwt/usMiJPazBjur
DhZFT8h5nQl1AdilsDiI0FIsJSYrPQqUROetN1ASa9upNRjD0SStC9k+8meRCyNR
Gillmor, et al. Expires 7 January 2027 [Page 43]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
Huuxakg/jlgTC4ami+wCPspXGWq6XBK0LOyH5Xw5tKctsLh4AzokJ2kTd2gOuoYK
9CuKWfMztVDNkUQeGzaob+CxPpMosGkCzQPDlfxJ5pO2seRBdwA5SLaNKOVapqlU
VFBy7Rk0WwpVL6E3uXwQVPgtTgJUV2hNzaIkzoaxnfguI6l19QCjxZgRPgo7+Wdr
Ulp9a3R5NaCiKGkJ/DqmiaAP+SvIz4caY0FN30gS+zADUlNgtxocJjDC/HHIMEd1
XtiPQfSvbSo5tKCXUNkLKnQN4+A2j/GjMhJRjiaQf9Fu3esWzXO0i3GJbaTBoqmT
m1sHfARbACqAK5GoTIYEELyn2gpFjuJzjAzCheTIg1FTZMmQsgIO8LhQWJsbMaR2
isKYUiLE5Yh2sUJFGicUWuIFQeuqabpmZoFgcTE1dSVjUOSugRNJmtESF5hEBru0
sFtvniJ2WJxu8GFY7aUg70ULpeOQ8OQBYzC0lhea8RI09gsPTKZO+XBQLBMER/Ro
+2KFC7eOrwePw2MpAGCGCsFsn+u/kVo1rNjNf4RQT+U9P8tSzFNmzpJrKSsZoKsz
CLtwZbfPyaJl4RsA/HM5dtKxVSIBunE/sUFYQrMadaWwLUtjDKKRfOUUEBmYlooX
T4UfFSAKUUA/lvQFohWLvNo4p4yJ4epFj4elSWedRdlerUYeETSJQImPSDsC0oV0
zyBN4TuTHCJQRXJ5OUVWfEMLBQBasZVY34lrSGkabslvtLUTOzYrVvZk/EYk1TQC
qHoFfRjL6YbFyetFIbqOcgubQnWPzzc9YRqYtfUXVZdDaAuClcRfNuN71KSNAyEH
gJJACRoSulp6AIyvncYIrZusj9gyPXvNOPJe7+t4g/exB+NqatYg2CAmjQbITDAC
95yvlAQnVum/dBiDt/ghrZRqHWDD7CyNVXFW1VEFb/BNAuY9tEg2pAt2uzCGnspH
kriSl2itWqZuq5dzwQZkBlhCPRcsNnmpo/dB7pTH09hDAUBP0recrdUB5fB+Pclp
6HEe6mV4LUVO9Id8ezNY0uOH6+FmmVa06mrDhpxOMAhRs2ZgcddpN5VsoWd8sfYD
YkEkwJgy9/wTM+mr1GydcBx0gmurKTVw9Es1fBWDB1MQp6SQ1KV/kzSJorFKBYZx
eos4BBUQBQWXrutDnnZlBKFbVvx/nfa2brOCfxVQCMMM28rN3Mqo7UQfYPpeF9M6
r2pN2uW1/Lhsf5dNCHeXE4EahcuU2kkmeQuS/1oDgeIfZui6gWEiz+JFBIgc9WfB
ehf6rNFny9gy1gqDD1+7He212ThCNtaHM8MAoGlmFCY0G4NQ9KIT25xXJhNmdUIG
FNhRsy2PALkCJ0c22TwJSI7JoOruxVDKFyRhxRDVmObux6bB91tvACdQ6TWc5MeN
p6aI15EQSi5301fGMr2A8ncNCrrkxZtWZNjqwpEGGBsIAAAAMgWCakvm+QWJAA0v
AAKbBCIhBlbBBdCZ2iX4UirrPZ3PiLzgafWjEReiu09WGr+r5hyhAAAAAKGUEIU6
0fNLpltiA1ri3UtvD9Y4eXpNb5ZLj2O5/4dsOeArs4sfybJcm1O8VZHw5UD4gbxF
7SFG2phVie+X+Mw8XDo9bBTjhf2M0RYycXu/I58E
-----END PGP PRIVATE KEY BLOCK-----
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:
-----BEGIN PGP PUBLIC KEY BLOCK-----
xioGakRYfxsAAAAgcRJVRUdqGTNMnwwTeQZv+o8XiaDdVTTpXnjPNH2FR4zCkgYf
GwgAAAAzBYJqRFh/ApsDAh4IIiEGVsEF0JnaJfhSKus9nc+IvOBp9aMRF6K7T1Ya
v6vmHKEDJwkCAAAAADqFENl3uzg/tNOjW2+khGm+tpsVwFezqZ9N64SfSylWouMq
267PJtdf8y+mx3g4BbY0R3N5eTZiIpscbzy8p+PJ5+Hh7edI6p1hrbFxVSY/SjUI
zsQKBmpEWH8jAAAEwMnQyYCYyPLlqXKM8d+oKEe+a1maw5IdqzQRl3fDQA8WlOlA
/Ywqa+MA9Ni7ZMBE9pBRUKefJGZOu2NuNIJSzsB4c1tYPDqrMSR29JqqnOxXpISJ
VOmIxhC1j5VAKqnO4AuJ8zEa3imhDxUr4JORP8eRi5gwkgu8BMQJfDA9kBgeYzQz
x5JMJ5Mh/dW8/WOLdzIE77I8L6dX2NB0v6uAV0A6eFy+LCuivxV/aDRH/9SW1tDG
WocNMYqQ75JkFSpE4RVcYvVBE1iO6XBInjGAm/hSzwE6RglwbpQdy3WaJfYsVuqL
QgRpqZhuKmu18vaij0JGHRhAEDNJuvmBtdgnCneezGtbOPF4zcax5Da+EekANUKh
aClxZjSAFpAcpii0GElEQIpYxaWas6C2fsNxmhsh57d/U0p0SAAiOrmVLrdCC6kp
CNuqRiQ8jAC0+/tmZRe3YVi6lBiNHlVXtcoUCOCH4jWiMAMB04sTb1uz+3EtAJkt
ECDJ5muyIHhCBBQMKBKI9rMCujJfIQApZ1IHq8qOl2G1NfcdGfsUQ9sbnKZRyik6
Gillmor, et al. Expires 7 January 2027 [Page 44]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
5FBMIOsco+Q7XppgxyehKSmEpxJfwCtfC6YIosud5GSDOZMzCVQViDUawRk58KII
S8YDRNq9SrdqY9uLx4gq23Jyvfmkald7EsbAaOKbPQNgPaRpJTO7W9QGmFdCL4Kk
O4hOoVZHltq5Pko+/zYQick7kro5pvPDUaVhxuEu/GIlZWNoR9fO4TIItZwmIjwR
5YN0MVC7CyFEaBySPHhYZDdJJ7dj+EKncGts02cO7HmM8WUDPAAELlViZ/k10KjH
5oO+jWM6YBZrkLOPVngJSMB43EpJICeYSsGc2qCNK5NMtLvNSGsvsuUdr/WDtANT
rWI2XOw9oVs9APpuiKrHT+OGQTKnK+lKhUlJMEV6Iqt/6jt2ereLCzgls8B1fceG
6disSDiz6jKn/1APsSInlcsQqyR8MwoaE5g1tKx8SGFL3xK3VvMrSMED/8g4bsGa
yfEOM7lKrOIrv8nCyXrINOdrW5SgmmmOl2GR63l0qdybFsqZ0BFmlWWlTRFKekRo
meMB21yZXbc/qVhqILS41oYtUhSxFjBBbClKcAlHIzxNJeJaofALanq2VbKEbnBT
pCm+0HhH8Xu+/ACtZew8QliFrcoRsPM2zcy/nqPAN4QsvRFkykoDiDcId3cjwfAA
EKWKIshR5jNZoSwS+fcKcGk1hoYBhVY0WhQiZTSwNZsOOqaujNNhLgKZ5bebExqz
AkIrEhozfSS0ZBtzjCs1IMRchHOhzgpv3HWl0ZuwtxKu9MY1h+dOjbqxFai7IwOs
3xC0PMN03GIWkcNL8UACrLNEFPW6sVwE1ROXcTy5Lde63WsmxipfJEtdWfEqrvxZ
97yDKfRMGILApbY2CFuAPkYLiQd+lFGwytNxYbqI7pJKOdlVZ5s/7kBhlCwSedZ9
1uK/3JijNotlNrt/7atasaSk2kKjFpRGpUvArJRJGdVJszm5sBZ0PTWn94Zxunaz
ICo15jhCENG++qdEJ6ZbGHwMX8O7LWNXHUClYtRVTUR0mSFE2mwxLPFeeRJlIOkY
FzqWfDCMwXTwl1BLbyLQWhk/JW9MNw+ewkrxPD7CiwYYGwgAAAAsBYJqRFh/ApsM
IiEGVsEF0JnaJfhSKus9nc+IvOBp9aMRF6K7T1Yav6vmHKEAAAAAuV0Qz5l1AOOR
vovCj4Bu3eC92HlxHDLjXEZq/38loDYMHyjrUBUxYFOr1tWqk8dsonwGn/hEzsW+
4T/1SDccLQchb/vD4GUd4v2JFW6eKNY+8wTOxAoGakVPeSMAAATAmCRkirW5CYNd
ucEJs50OewXTIDpd+1BRD883x65KmmpbY8VABXdlc4unIE7ynMNXTJvWkV8jUE3H
URen4k9UUlzRkF3uwKh46VCn94Shmw7rs5wU44QXc7ays0Ypa3XFVnjoMEo+C8N5
NqLQipIHpmJjgEjVGh8/E10g5FCTc2sx8XAjdzxpbLRclKagpAUlabPjYIOowoOI
ZTs9Cx05wgy491pEcFUvWAWbdLbxVh9tq1MdV2FJdiU8OhvIg2LHdK2KAK7h8gBQ
waSIy0n+mhy/1HJ3gcf8FxTKfMQPAh2Ym0W5oVqc1HTYAlEucgKVZZl55TX1bDnd
9QDr52rNEcf5FFIySbxZbDc/ummER8T6oIXXmbLtURKdind4WStWV4XEBGEvoB2g
65igKI+vl8bH8z0V2XznScIfKM5qNEm1e5JcugGaew9BxaNKuot6dLT+8n7IoTqO
LHQzg5SxccCNWsLStwHbQ2I2OXYPQCleRMwbOIDrUIsFqQzXd4nZN6S0y3gFOYig
Qcmmljx5A24eaam4pJ0I4APVlYnRypCyKWrMyiOYrKQZy3cYoUpycMMKwXR2YS9q
QawPI57Wso67KsQAjYvWB397t0sRzE3FF6eRwlkIZly32rJ86MDJ4FXoQWkE2YTG
Jrh3Co8K2cWWJYjzPDdAMJ6LksEb3LXYcGPhGT1mJaGY6wWLG083oJpIeDFMXBOe
CRfO5ouqRR8196wRySod5kRKKgKiqy4PIiLzIQCuSLcnCUBwqX47FLQBkbvG0M+c
sK6N1ykFVjCed4CDMyf5Acho8nH96XbdunPWWXzyas2boiLDx8HoQDdpkXepucWN
SQ+uoLViZLyW9Ypa+2mMCHroyRnJUywu1yUNpIB+x7KW4Fx0YD8kShJq1WBEuEH8
Am19mmUkk7ljBsdLG5o5QwkxiASBRWu42IH6hcF1q5TxZqwBmDxj5AKqUxDoyBLl
3EEdlnz/+MzwcAPxZQU/+VeEdbTHfLUI1CXtJCpVSMjJ83poSxPtfHx0Anc41wcT
+IRp8BJZtF2QCgZC8Q3I2rtsE7nIt4pZRYV0RbGvwMxznH2Z97P1cCmyccYJaXGW
kghwNb6dcInPtXr81WRxcIBx44ggWgFwkLdSho68pmg60cWcioEKxGwBBIcaQq+p
JDDoqVC2AU8cATkHdZhzrI8aRXffWX4xsJ0/4a/1NI0F0mxvZRfO1Qjg0ofYpkPS
OmnyjDlYKCmZRKvzlYkv0LL0V6RhCw2uaKDhg3siZzgfBUocGwZ8kaTY7K/60qC4
x5oqIlnctCN58chMOHU7YGNzaUCvgbUTUWsHIGt7yLf+AikpmTq9IjkyjLkuak0b
VCQpEwHyBSiRVqo2CFmGdzU6wR8dAFiusQfLYCLF8X85l4DkEYpwsYitUIs+PMB2
UoOVu1ZJhbB20rrmTMSZ92EGuBivy4rJos5tI3t7Z8gRkD9N2LymR3xT2xgv9p+R
NxglSM2WlxMzED/MqDq20apCd5pBQTdEq7ep3BTGtAtO5a2Y8sxrmcqD4TsPN7Cm
MVdSUXno9U1RKjKgOI+Xwn7MXAsNJ0df2ZnmozWT1I66ccOovlX5XMlghOsmtPBD
iZiJLCICOcKRBhgbCAAAADIFgmpFT3kFiQANLwACmwQiIQZWwQXQmdol+FIq6z2d
z4i84Gn1oxEXortPVhq/q+YcoQAAAAAcPRDjNtQHkZBvJC02Qn1fsEFWdrHIbvPZ
XkrPWa5CkP2yb2TMdEH8pqp3bIGapgzDoyvWZzlcBK6xxF+AVQqSrwOaHYx/Ahht
Gillmor, et al. Expires 7 January 2027 [Page 45]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
nMSP0IHrw5wmCc7ECgZqS+b5IwAABMCnOYxb/IKTctNNLWeRAsP5RriFg0AmkSqG
WZdeAcCPQkGIVtbEs9/LSNsQUOWswFWFcqCBvBW3BjNxtIYHLaLcqXEilhSwPCDk
FV0ajbEbdHAcQ5sxUA+BJ9yxfAYxeRxcrZint7hbTuUweHY5vmC5dk34dbDjSqX2
Papwx1jSWF8jABVHQ6WjeQtcwynST9TUyPtsDbpBxK2jTg9yb1XBd2wyU4x7swFZ
Vj8Lf7rDIiT2swY7qw4WRU/IeZ0JdQHYpbA4iNBSLCUmKz0KlETnrTdQEmvbqTUY
w9EkrQvZPvJnkQsjUR7rsWpIP45YEwuGpovsAj7KVxlqulwStCzsh+V8ObSnLbC4
eAM6JCdpE3doDrqGCvQrilnzM7VQzZFEHhs2qG/gsT6TKLBpAs0Dw5X8SeaTtrHk
QXcAOUi2jSjlWqapVFRQcu0ZNFsKVS+hN7l8EFT4LU4CVFdoTc2iJM6GsZ34LiOp
dfUAo8WYET4KO/lna1JafWt0eTWgoihpCfw6pomgD/kryM+HGmNBTd9IEvswA1JT
YLcaHCYwwvxxyDBHdV7Yj0H0r20qObSgl1DZCyp0DePgNo/xozISUY4mkH/Rbt3r
Fs1ztItxiW2kwaKpk5tbB3wEWwAqgCuRqEyGBBC8p9oKRY7ic4wMwoXkyINRU2TJ
kLICDvC4UFibGzGkdorCmFIixOWIdrFCRRonFFriBUHrqmm6ZmaBYHExNXUlY1Dk
roETSZrREheYRAa7tLBbb54idlicbvBhWO2lIO9FC6XjkPDkAWMwtJYXmvESNPYL
D0ymTvlwUCwTBEf0aPtihQu3jq8Hj8NjKQBghgrBbJ/rv5FaNazYzX+EUE/lPT/L
UsxTZs6SaykrGaCrMwi7cGW3z8miZeEbAPxzOXbSsVUiAbpxP7FBWEKzGnWlsC1L
YwyikXzlFBAZmJaKF0+FHxUgClFAP5b0BaIVi7zaOKeMieHqRY+HpUlnnUXZXq1G
HhE0iUCJj0g7AtKFdM8gTeE7kxwiUEVyeTlFVnxDCwUAWrGVWN+Ja0hpGm7Jb7S1
Ezs2K1b2ZPxGJNU0Aqh6BX0Yy+mGxcnrRSG6jnILm0J1j883PWEamLX1F1WXQ2gL
gpXEXzbje9SkjQMhB4CSQAkaErpaegCMr53GCK2brI/YMj17zTjyXu/reIP3sQfj
amrWINggJo0GyEwwAvecr5QEJ1bpv3QYg7f4Ia2Uah1gw+wsjVVxVtVRBW/wTQLm
PbRINqQLdrswhp7KR5K4kpdorVqmbquXc8EGZAZYQj0XLDZ5qaP3Qe6Ux9PYQwFA
T9K3nK3VAeXwfj3JaehxHupleC1FTvSHfHszWNLjh+vhZplWtOpqw4acTjAIUbNm
YHHXaTeVbKFnfLH2A2JBJMCYMvf8EzPpq9RsnXAcdIJrqyk1cPRLNXwVgwdTEKek
kNSlf5M0iaKxSgWGcXqLOAQVEAUFl67rQ552ZQShW1b8f532tm6zgn8VUAjDDNvK
zdzKqO1EH2D6XhfTOq9qTdrltfy4bH+XTQh3lxOBGoXLlNpJJnkLkv9aA4HiH2bo
uoFhIs/iRQSIHPVnwXoX+qzRZ8vYMtYKgw9fux3ttdk4QjbWhzPDwpEGGBsIAAAA
MgWCakvm+QWJAA0vAAKbBCIhBlbBBdCZ2iX4UirrPZ3PiLzgafWjEReiu09WGr+r
5hyhAAAAAKGUEIU60fNLpltiA1ri3UtvD9Y4eXpNb5ZLj2O5/4dsOeArs4sfybJc
m1O8VZHw5UD4gbxF7SFG2phVie+X+Mw8XDo9bBTjhf2M0RYycXu/I58E
-----END PGP PUBLIC KEY BLOCK-----
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 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_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.
Gillmor, et al. Expires 7 January 2027 [Page 46]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
-----BEGIN PGP PRIVATE KEY BLOCK-----
xUsGakRYfxsAAAAgcRJVRUdqGTNMnwwTeQZv+o8XiaDdVTTpXnjPNH2FR4wAET8I
Q3fQeNm71dOZSkB/260JmbL1QIX/q4ugYzBOFKLCkgYfGwgAAAAzBYJqRFh/ApsD
Ah4IIiEGVsEF0JnaJfhSKus9nc+IvOBp9aMRF6K7T1Yav6vmHKEDJwkCAAAAADqF
ENl3uzg/tNOjW2+khGm+tpsVwFezqZ9N64SfSylWouMq267PJtdf8y+mx3g4BbY0
R3N5eTZiIpscbzy8p+PJ5+Hh7edI6p1hrbFxVSY/SjUIx8RrBmpEWH8jAAAEwMnQ
yYCYyPLlqXKM8d+oKEe+a1maw5IdqzQRl3fDQA8WlOlA/Ywqa+MA9Ni7ZMBE9pBR
UKefJGZOu2NuNIJSzsB4c1tYPDqrMSR29JqqnOxXpISJVOmIxhC1j5VAKqnO4AuJ
8zEa3imhDxUr4JORP8eRi5gwkgu8BMQJfDA9kBgeYzQzx5JMJ5Mh/dW8/WOLdzIE
77I8L6dX2NB0v6uAV0A6eFy+LCuivxV/aDRH/9SW1tDGWocNMYqQ75JkFSpE4RVc
YvVBE1iO6XBInjGAm/hSzwE6RglwbpQdy3WaJfYsVuqLQgRpqZhuKmu18vaij0JG
HRhAEDNJuvmBtdgnCneezGtbOPF4zcax5Da+EekANUKhaClxZjSAFpAcpii0GElE
QIpYxaWas6C2fsNxmhsh57d/U0p0SAAiOrmVLrdCC6kpCNuqRiQ8jAC0+/tmZRe3
YVi6lBiNHlVXtcoUCOCH4jWiMAMB04sTb1uz+3EtAJktECDJ5muyIHhCBBQMKBKI
9rMCujJfIQApZ1IHq8qOl2G1NfcdGfsUQ9sbnKZRyik65FBMIOsco+Q7Xppgxyeh
KSmEpxJfwCtfC6YIosud5GSDOZMzCVQViDUawRk58KIIS8YDRNq9SrdqY9uLx4gq
23Jyvfmkald7EsbAaOKbPQNgPaRpJTO7W9QGmFdCL4KkO4hOoVZHltq5Pko+/zYQ
ick7kro5pvPDUaVhxuEu/GIlZWNoR9fO4TIItZwmIjwR5YN0MVC7CyFEaBySPHhY
ZDdJJ7dj+EKncGts02cO7HmM8WUDPAAELlViZ/k10KjH5oO+jWM6YBZrkLOPVngJ
SMB43EpJICeYSsGc2qCNK5NMtLvNSGsvsuUdr/WDtANTrWI2XOw9oVs9APpuiKrH
T+OGQTKnK+lKhUlJMEV6Iqt/6jt2ereLCzgls8B1fceG6disSDiz6jKn/1APsSIn
lcsQqyR8MwoaE5g1tKx8SGFL3xK3VvMrSMED/8g4bsGayfEOM7lKrOIrv8nCyXrI
NOdrW5SgmmmOl2GR63l0qdybFsqZ0BFmlWWlTRFKekRomeMB21yZXbc/qVhqILS4
1oYtUhSxFjBBbClKcAlHIzxNJeJaofALanq2VbKEbnBTpCm+0HhH8Xu+/ACtZew8
QliFrcoRsPM2zcy/nqPAN4QsvRFkykoDiDcId3cjwfAAEKWKIshR5jNZoSwS+fcK
cGk1hoYBhVY0WhQiZTSwNZsOOqaujNNhLgKZ5bebExqzAkIrEhozfSS0ZBtzjCs1
IMRchHOhzgpv3HWl0ZuwtxKu9MY1h+dOjbqxFai7IwOs3xC0PMN03GIWkcNL8UAC
rLNEFPW6sVwE1ROXcTy5Lde63WsmxipfJEtdWfEqrvxZ97yDKfRMGILApbY2CFuA
PkYLiQd+lFGwytNxYbqI7pJKOdlVZ5s/7kBhlCwSedZ91uK/3JijNotlNrt/7ata
saSk2kKjFpRGpUvArJRJGdVJszm5sBZ0PTWn94ZxunazICo15jhCENG++qdEJ6Zb
GHwMX8O7LWNXHUClYtRVTUR0mSFE2mwxLPFeeRJlIOkYFzqWfDCMwXTwl1BLbyLQ
Whk/JW9MNw+ewkrxPD4AaGZh9fcInOX2yYpJXNKEnHCNh08uWEosBWRDzpeOVGja
b3dBAAafhaFGEhx4WqVYOan5ZDw/WNqlTVIRdLWvDuQjHvRMLCoqgQ/E+04G6uS6
arNh3q8Bzija4mELayyhwosGGBsIAAAALAWCakRYfwKbDCIhBlbBBdCZ2iX4Uirr
PZ3PiLzgafWjEReiu09WGr+r5hyhAAAAALldEM+ZdQDjkb6Lwo+Abt3gvdh5cRwy
41xGav9/JaA2DB8o61AVMWBTq9bVqpPHbKJ8Bp/4RM7FvuE/9Ug3HC0HIW/7w+Bl
HeL9iRVunijWPvMEx8RrBmpL5vkjAAAEwKc5jFv8gpNy000tZ5ECw/lGuIWDQCaR
KoZZl14BwI9CQYhW1sSz38tI2xBQ5azAVYVyoIG8FbcGM3G0hgctotypcSKWFLA8
IOQVXRqNsRt0cBxDmzFQD4En3LF8BjF5HFytmKe3uFtO5TB4djm+YLl2Tfh1sONK
pfY9qnDHWNJYXyMAFUdDpaN5C1zDKdJP1NTI+2wNukHEraNOD3JvVcF3bDJTjHuz
AVlWPwt/usMiJPazBjurDhZFT8h5nQl1AdilsDiI0FIsJSYrPQqUROetN1ASa9up
NRjD0SStC9k+8meRCyNRHuuxakg/jlgTC4ami+wCPspXGWq6XBK0LOyH5Xw5tKct
sLh4AzokJ2kTd2gOuoYK9CuKWfMztVDNkUQeGzaob+CxPpMosGkCzQPDlfxJ5pO2
seRBdwA5SLaNKOVapqlUVFBy7Rk0WwpVL6E3uXwQVPgtTgJUV2hNzaIkzoaxnfgu
I6l19QCjxZgRPgo7+WdrUlp9a3R5NaCiKGkJ/DqmiaAP+SvIz4caY0FN30gS+zAD
UlNgtxocJjDC/HHIMEd1XtiPQfSvbSo5tKCXUNkLKnQN4+A2j/GjMhJRjiaQf9Fu
3esWzXO0i3GJbaTBoqmTm1sHfARbACqAK5GoTIYEELyn2gpFjuJzjAzCheTIg1FT
Gillmor, et al. Expires 7 January 2027 [Page 47]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
ZMmQsgIO8LhQWJsbMaR2isKYUiLE5Yh2sUJFGicUWuIFQeuqabpmZoFgcTE1dSVj
UOSugRNJmtESF5hEBru0sFtvniJ2WJxu8GFY7aUg70ULpeOQ8OQBYzC0lhea8RI0
9gsPTKZO+XBQLBMER/Ro+2KFC7eOrwePw2MpAGCGCsFsn+u/kVo1rNjNf4RQT+U9
P8tSzFNmzpJrKSsZoKszCLtwZbfPyaJl4RsA/HM5dtKxVSIBunE/sUFYQrMadaWw
LUtjDKKRfOUUEBmYlooXT4UfFSAKUUA/lvQFohWLvNo4p4yJ4epFj4elSWedRdle
rUYeETSJQImPSDsC0oV0zyBN4TuTHCJQRXJ5OUVWfEMLBQBasZVY34lrSGkabslv
tLUTOzYrVvZk/EYk1TQCqHoFfRjL6YbFyetFIbqOcgubQnWPzzc9YRqYtfUXVZdD
aAuClcRfNuN71KSNAyEHgJJACRoSulp6AIyvncYIrZusj9gyPXvNOPJe7+t4g/ex
B+NqatYg2CAmjQbITDAC95yvlAQnVum/dBiDt/ghrZRqHWDD7CyNVXFW1VEFb/BN
AuY9tEg2pAt2uzCGnspHkriSl2itWqZuq5dzwQZkBlhCPRcsNnmpo/dB7pTH09hD
AUBP0recrdUB5fB+Pclp6HEe6mV4LUVO9Id8ezNY0uOH6+FmmVa06mrDhpxOMAhR
s2ZgcddpN5VsoWd8sfYDYkEkwJgy9/wTM+mr1GydcBx0gmurKTVw9Es1fBWDB1MQ
p6SQ1KV/kzSJorFKBYZxeos4BBUQBQWXrutDnnZlBKFbVvx/nfa2brOCfxVQCMMM
28rN3Mqo7UQfYPpeF9M6r2pN2uW1/Lhsf5dNCHeXE4EahcuU2kkmeQuS/1oDgeIf
Zui6gWEiz+JFBIgc9WfBehf6rNFny9gy1gqDD1+7He212ThCNtaHM8MAoGlmFCY0
G4NQ9KIT25xXJhNmdUIGFNhRsy2PALkCJ0c22TwJSI7JoOruxVDKFyRhxRDVmObu
x6bB91tvACdQ6TWc5MeNp6aI15EQSi5301fGMr2A8ncNCrrkxZtWZNjqwpEGGBsI
AAAAMgWCakvm+QWJAA0vAAKbBCIhBlbBBdCZ2iX4UirrPZ3PiLzgafWjEReiu09W
Gr+r5hyhAAAAAKGUEIU60fNLpltiA1ri3UtvD9Y4eXpNb5ZLj2O5/4dsOeArs4sf
ybJcm1O8VZHw5UD4gbxF7SFG2phVie+X+Mw8XDo9bBTjhf2M0RYycXu/I58E
-----END PGP PRIVATE KEY BLOCK-----
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 [RFC9980]
Gillmor, et al. Expires 7 January 2027 [Page 48]
Internet-Draft Autocrypt v2 Certificates and TSKs July 2026
* 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
Authors' Addresses
Daniel Kahn Gillmor
American Civil Liberties Union
Email: dkg@fifthhorseman.net
Holger Krekel
merlinux gmbh
Email: holger@merlinux.eu
Friedel Ziegelmayer
n0 Inc.
Email: me@dignifiedquire.com
Gillmor, et al. Expires 7 January 2027 [Page 49]