Autocrypt v2 OpenPGP Certificates and Transferable Secret Keys

1.1. Requirements Language

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

1.2. Terminology

• "OpenPGP certificate" or just "certificate" refers to an OpenPGP Transferable Public Key (see Section 10.1 of [RFC9580]). This specification distinguishes between outgoing certificates as distributed by the keyholder, with a fixed structure and size, and incoming certificates as received and stored by a peer. This specification does not prescribe any particular mechanism for how certificates are transferred between parties.¶

• "Transferable Secret Key" or just "TSK" refers to an OpenPGP Transferable Secret Key (see Section 10.2 of [RFC9580]).¶

• "Component key" refers to a single cryptographic object found within an OpenPGP certificate. A certificate's primary key is a "component key", and any subkey in the certificate is also a "component key".¶

• "Keyholder" is the party that has legitimate access to the secret key material corresponding to the component keys in a certificate. The keyholder can sign messages that can be verified with the certificate, decrypt messages that were encrypted to the certificate, and update the certificate itself over time.¶

• "User Messaging Agent" or UMA refers to a program used to compose, send, receive, and render messages. This term is similar to "Mail User Agent" (MUA), but the variation in naming emphasizes that Autocrypt v2 certificates do not prescribe a specific transport mechanism nor do they prescribe a particular message content format. A Keyholder may have one or more UMAs that share access to the same secret key material, messaging inbox, and other account details.¶

• "Peer" means a party who communicates with the keyholder via messages, as well as potentially with other peers. The peer does not have access to the keyholder's asymmetric secret key material, but typically has access to a copy of each message exchanged between the peer and keyholder.¶

• "Reliable Deletion" refers to the property that enables a keyholder to render a message unrecoverable after deletion, even if an attacker has archived all messages in transit and subsequently obtains the keyholder's secret key material and message archive. Reliable deletion therefore requires the destruction of both secret key material and message cleartext. This property is commonly referred to as "Forward Secrecy"; however, this specification uses the term "Reliable Deletion" to emphasize the keyholder's ability to permanently delete messages.¶

1.3. Goals

A certificate following this specification has the following goals:¶

• Post-quantum confidentiality. It should defend against a store-now-decrypt-later attack from a cryptographically relevant quantum computer.¶

• Size matters. When network conditions are constrained by limited bandwidth, high latency, or intermittent connectivity, there often is a heightened need for encryption with reliably deletable messages. To preserve availability under such conditions, the size of cryptographic material should be minimized and it should be possible to include transmission of a few dozen certificates in a single message without impairing common messaging infrastructure.¶

• Computational resources matter. It should be possible to promptly encrypt a single message to up to a few dozen of these certificates with low-powered devices. The same hardware should be able to quickly and cheaply verify a signature from one of these certificates. And with access to the corresponding secret keys, it should be inexpensive to decrypt a message encrypted to one, or to sign a message with one.¶

• Reliable deletion. The keyholder should be able to robustly and permanently delete an encrypted message received some time in the past, rendering it unrecoverable even to a powerful attacker in the future (see Section 5.1).¶

• No network synchronization needed. The keyholder should be able to encrypt and decrypt messages with local key material only, without requiring network synchronization between their own devices or with peers. To the extent that a keyholder has multiple UMAs of their own, each UMA should be able to operate independently with no ongoing network synchronization between them beyond the initial configuration.¶

• Backward compatibility. It must be possible for a keyholder with an Autocrypt v1 key to sign a message that is encrypted to an Autocrypt v2 certificate, and vice versa. It must also be possible to encrypt a message to a mixed group of Autocrypt v1 and v2 certificates (though such a message may not meet the "Reliable deletion" goal).¶

• Drop-in OpenPGP replacement for existing peers. The keyholder might need to update their OpenPGP implementation, UMA(s), and regular workflow to use the secret key material to meet these goals successfully. But a peer whose UMA supports Autocrypt v1.1 already only needs to update their OpenPGP implementation in order to interoperate.¶

1.4. Non-Goals

This specification does not attempt to accommodate all possible scenarios that might occur with OpenPGP, email, or other messaging systems. The following concerns are explicitly not in-scope for this specification:¶

• No support for legacy OpenPGP clients. The keyholder needs to use an up-to-date OpenPGP implementation, and expects their peers to do the same. There is no attempt at backward compatibility for a peer with a legacy OpenPGP implementation.¶

• No in-cert human-readable identifiers. There is no attempt to store a “real name" or other human-readable identity information in the certificate. If human-readable identity information is to be associated with the certificate, it is expected to be supplied elsewhere, such as with a local petname system, or some external cryptographic bindings.¶

• No in-cert transport-layer addressing. There is no attempt to bind transport-layer routing information (e.g., email addresses) to the certificate. Information about how to get an encrypted message to the keyholder is presumed to be transmitted via some other channel, such as the Autocrypt header field.¶

• No defense against quantum impersonation. While the certificate is designed to defend against store-now-decrypt-later attacks, it does not defend against an adversary with a cryptographically relevant quantum computer that breaks the signing key and updates the certificate in order to compromise future messages encrypted to the certificate. Such an attacker must expose themselves to the peer at least (putting the attacker at risk due to visibility), and these attacks cannot take place retroactively.¶

• No transitioning from old certs. There is no specific support for transitioning older or alternative OpenPGP certificate formats to the structure defined in this specification. Such a migration path may be defined in future specifications, but this document is limited to new adopters going forward.¶

• No certificate discovery and no refresh. This specification does not define a mechanism to request a refreshed certificate from a peer. Reliable message deletion depends on timely updates of each correspondent's certificate, but imposing a particular mechanism is unlikely to accommodate the constraints of diverse messaging implementations. That said, this specification does not preclude the use of discovery or refresh mechanisms.¶

• No coordinated deletion of messages. This specification addresses unilateral deletability, protecting against a future attacker who compromises the keyholder's UMA or secret key storage. Messages are typically stored in multiple locations, across peers, devices, and UMAs. Guaranteeing deletion of all copies of a message, including through negotiated “disappearing messages” mechanisms, is outside the scope of this draft.¶

• No post-compromise security. Some messaging schemes attempt to defend against an attacker who has compromised the user's secret key material at some point in the past, typically by regularly mixing new entropy into the secret key material and coordinating those updates across the user's shared devices. This specification does not defend against such an attacker. In the case of past key compromise, the user may need to move to an entirely new certificate.¶

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

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

• B. Direct Key Signature (packet type ID 2), version 6, signature type 0x1f, hashed subpackets include:¶

  • signature creation time (probably T)¶

  • key flags: certify, sign¶

  • issuer fingerprint (fingerprint of A)¶

  • features: SEIPDv2¶

  • preferred AEAD ciphersuites: AES-256+OCB ## TBD: do we need this?¶

  • no expiration subpacket¶

• C. "Fallback" Public Subkey Packet (packet type 14), version 6, public key algorithm ML-KEM-768+X25519 (algorithm ID 35) (see Section 4.2 of [I-D.ietf-openpgp-pqc-14]), creation time T¶

• D. Subkey binding signature (packet type ID 2), version 6, signature type 0x18, hashed subpackets include:¶

  • signature creation time (probably matching time in B)¶

  • 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 [I-D.ietf-openpgp-pqc-14]), creation time T or later¶

• F. Subkey binding signature (packet type ID 2), version 6, signature type 0x18, hashed subpackets:¶

  • signature creation time (same as creation time of E)¶

  • key expiration time: max_rd (by convention, 10 days = 864000 seconds)¶

  • key flags: encrypt to comms¶

  • issuer fingerprint (fingerprint of A)¶

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

2.4. 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.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.2. The keyholder's UMA must recognize this structure to perform the aligned key ratcheting necessary for reliable deletion.¶

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

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 possible time that the peer can send a reliably deletable message to the keyholder, starting from when the peer retrieves a fresh copy of the keyholder's certificate.¶

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 possible time that the peer will be able to send a reliably deletable message to the keyholder, starting from when the peer retrieves a fresh copy of the keyholder's certificate.¶

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

AC2_Ratchet(secret_key
            start)
            -> (next_secret_subkey, subkey_binding_sig):
  primary_key = get_primary_key(secret_key)
  (base_subkey, oldsbs) = get_last_rotating_subkey(secret_key)
  max_rd = get_expiration_duration(oldsbs)

  salt = start || get_public(base_key)
  info = "Autocrypt_v2_ratchet" || get_public(primary_key) || max_rd
  IKM = extract_secret_key_material(base_key)
  IKM = normalize_x25519_scalar(IKM)
  L = 160
  ks = HKDF_SHA2_512(salt, info, IKM, L)
  bssalt = SHA2_512(ks[0:64])[0:16]
  new_secret = normalize_x25519_scalar(ks[64:160])
  new_subkey = make_secret_subkey(new_secret, start)
  subp = replace_creation_time(get_hashed_subpackets(oldsbs), start)
  binding_sig = bind_subkey(primary_key,
                            get_public(new_subkey),
                            subp, bssalt)
  return (new_subkey, binding_sig)

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