Recommend PubSub access model 'open' for public key data node and metadata node.
Fix 'to'-attribute requirements: All content elements which are signed using OpenPGP need that attribute to prevent Surreptitious Forward Attacks. The <crypt/> element does not require one, as the intented recipient is established by the encryption itself. The XEP had the requirements for <sign/> and <crypt/> mixed up.
Update acknowledgements.
Minior editorial fixes.
Minior editorial fixes.
Initial published version approved by the XMPP Council.
First draft.
This XMPP extension protocol specifies the foundations of
end-to-end encryption and authentication, based on digital
signatures, of data with the help of OpenPGP. Additional XEPs will
use this extension protocol as building block when specifying their
own OpenPGP profile suiting their use case. One such profile is the
Instant Messaging Profile specified in OpenPGP for XMPP Instant Messaging (XEP-0374)
XMPP provides the mechanisms to solve a lot of issues that come
with modern day OpenPGP usage. For example, based on Personal Eventing Protocol (XEP-0163)
OpenPGP in return allows for end-to-end encrypted data to be
exchanged between one, two or even multiple entities
(multi-end-to-multi-end encryption). Therefore this XEP can be used
for example to implement end-to-end encrypted Multi-User Chat (XEP-0045)
The <openpgp/> extension element qualified by the 'urn:xmpp:openpgp:0' namespace is used in order to exchange encrypted and signed data.
The text content of <openpgp/> ("BASE64_OPENPGP_MESSAGE") is a
Base64 encoded (RFC 4648
In case of a <signcrypt/> element, the OpenPGP message embedded in the <openpgp/> element MUST be encrypted and signed, and SHOULD also be encrypted to self. In case of a <sign/> element, the OpenPGP message MUST be signed and MUST NOT be encrypted. In case of <crypt/> the OpenPGP message MUST NOT be signed, but MUST be encrypted.
OpenPGP content elements MUST possess exactly one 'time'
element as direct child elements. The <signcrypt/> and <sign/>
content elements MUST contain at least one 'to' element(s), which
MUST have a 'jid' attribute containing the intended recipient's
XMPP address of the signed and/or encrypted data to prevent
Surreptitious Forward Attacks
| Content Element | 'to' Element | 'time' Element | <rpad/> Element | <payload/> Element |
|---|---|---|---|---|
| <signcrypt/> | MUST have at least one | MUST have exactly one | SHOULD have exactly one | MUST have exactly one |
| <sign/> | MUST have at least one | MUST have exactly one | OPTIONAL | MUST have exactly one |
| <crypt/> | OPTIONAL | MUST have exactly one | SHOULD have exactly one | MUST have exactly one |
OpenPGP content elements MUST possess exactly one <payload/>
element. The child elements of <payload/> can be seen as OpenPGP
secured Stanza extension elements which are encrypted and/or
signed. After the <openpgp/> element and the including <signcrypt/>,
<sign/> or <crypt/> element was verified, they are processed
according to the specification of the relevant OpenPGP for XMPP
profile (see for example OpenPGP for XMPP Instant Messaging (XEP-0374)
Recipients MUST verify that the signature is valid, that the signature's key corresponds to the sender's key, and that the sender's key has a User ID containing the sender's XMPP address in the form "xmpp:juliet@example.org" (for details see "OpenPGP User IDs"). Thus, the recipient may need to retrieve the key from the Personal Eventing Protocol node as described above. At least one of the XMPP addresses found in the 'to' elements contained in OpenPGP content element MUST correspond to the outer 'to' of the XMPP <message/>. Furthermore, recipients are RECOMMENDED to verify the 'time' element for plausibility or to display it to a user for verification.
Parties interested in exchanging encrypted data between each other via OpenPGP need to know the public key(s) of the recipients. The following section specifies a mechanism to announce and discover public keys.
Two PEP node types are invovled: A "medatata node" is used to store meta information about OpenPGP keys used by an entity while the actual public keys are stored in "data nodes".
The public key data, as specified in RFC 4880
In absence of a use-case specific access model, it is RECOMMENDED to use the 'open' access model for the public key data node in order to give entities without presence subscription read access to the public key.
The access model can be changed efficiently by using publish-options.
The OpenPGP v4 fingerprint string is obtained as follows: First the raw bytes of the
fingerprint are computed as specified in RFC 4880 § 12.2.. Then the bytes are
encoded as a hexadecimal string using upper case characters
The publishing entity SHOULD set the PubSub item ID to the time the item is published encoded
as DateTime format specified in XMPP Date and Time Profiles (XEP-0082)
The data node MUST contain an <pubkey/> element qualified by the 'urn:xmpp:openpgp:0' namespace. The element MUST include a <data/> element which contains the data of the key Base64 encoded.
To update the public keys used by an entity, the metadata node is updated. Before adding a OpenPGP key fingerprint to the metadata node, the publisher MUST ensure that the public key is available at the corresponding data node.
Just like with the public key data node, in absence of a use-case specific access model, it is RECOMMENDED to set the access model of the metadata node to 'open', such that entities without mutual presence subscription are still able to access the node items.
The ID of the metadata node is 'urn:xmpp:openpgp:0:public-keys'. It contains a
<public-keys-list/> element qualified by the 'urn:xmpp:openpgp:0' namespace containing one
or more <pubkey-metadata/> elements. Every pubkey-metadata element MUST have a
'v4-fingerprint' attribute, containing the OpenPGP v4 fingerprint string, and a 'date'
attribute, containing the time the key was published or updated in DateTime format of
XMPP Date and Time Profiles (XEP-0082)
In order to discover the OpenPGP public keys of a remote entity, the interested entity first queries the remote entity's metadata note to learn about the currently annouced OpenPGP keys.
OpenPGP key(s) can be retrieved by querying the data node for a specific fingerprint.
Note that the result may contain multiple pubkey elements. Only
the public keys found in the most recent item MUST be used. Requesters
may want to limit the results to the most recent item using the
'max_items' attribute set to '1'. Clients could alternatively use
Result Set Management (XEP-0059)
Some XMPP services may not provide the Personal Eventing Protocol feature required to provide the mechanism described here. If so, they will return an <iq/> error of type service-unavailable.
Entities creating PEP nodes defined herein SHOULD configure the nodes as notification-only nodes by setting 'pubsub#deliver_payloads" configuration field to 'false'.
Entities which are subscribed to the metadata node or advertise the
"urn:xmpp:openpgp:0:public-keys+notify" feature via Service Discovery (XEP-0030)
A private PEP node is used to allow XMPP clients to synchronize
the user's secret OpenPGP key. Where private PEP node is defined: A
PEP node in whitelist mode where only the bare JID of the key
owner is whitelisted as described in Best Practices for Persistent Storage of Private Data via Publish-Subscribe (XEP-0223)
The used PEP server MUST support PEP and the whitelist access model. It SHOULD also support persistent items.
The service discovery result must contain a PEP identity '<identity category='pubsub' type='pep'/>, and the 'http://jabber.org/protocol/pubsub#access-whitelist' feature. Ideally it also contains the 'http://jabber.org/protocol/pubsub#persistent-items' feature
In order to synchronize the secret key over a private PEP node, clients first need to discover and verify the node for the correct settings.
If the node does not exist the service will return an <iq/> error indicating the item-not-found error condition. The client MUST then create it with an whitelist access model.
The service will return a service-unavailable error <iq/> if it does not support PEP.
The node is now created and the only affiliated entity is the bare JID of the user, who created the node, with an affiliation as 'owner'.
In order to set a new secret key, clients store the encrypted secret key as Base64 encoded raw OpenPGP message within an <secretkey/> element qualified by the 'urn:xmpp:openpgp:0' namespace. These secret key backups are created as follows:
Implementations of this XEP MUST generate and accept only version 4 (or higher) OpenPGP packets. Lower version OpenPGP packets are insecure in many aspects (see for example RFC 4880 § 5.5.2.).
The Public-Key metadata node and the Secret-Key node SHOULD be configured to either
never send the latest item, or to send the latest item only when a new entity subscribed. Thus
the nodes 'send_last_published_item' configuration option SHOULD be set to either 'never' or
'on_sub' (see Publish-Subscribe (XEP-0060)
Whenever an entity becomes aware that the metadata node has changed (e.g., by receiving a PEP update from their own account), it SHOULD check that the list contains the key they use. If the key has been removed, the entity SHOULD reannounce it.
OpenPGP implementations have a sad history of being not very
user-friendly which results in users either not using OpenPGP or in
users wrongly using OpenPGP. Implementors of this XEP, and
additional future XEPs based on this XEP, therefore should read
STEED
Furthermore implementors should design the user interface for effective security by following the design principles and techniques for security mentioned in "Why Johnny Can't Encrypt".
Implementors should be aware that the size OpenPGP public and secret keys is somewhere in the range of tens of kilobytes. Applying Base64 encoding on keys, as it is described herein, further increases the size. The formula to determine the Base64 encoded size is: ceil(bytes / 3) * 4. Thus the lower bound for the maximum stanza size of 10000 bytes, as specified in RFC 6120 § 13.12. 4., is usually exceeded. However all XMPP server implementations, the authors are aware of, follow the recommendation of the RFC and do not blindly set the maximum stanza size to such a low value, but use a much higher threshold. Therefore, this should hardly be an issue for implementations. Nevertheless, it is advised to keep the size of OpenPGP keys small by removing all signatures except the most recent self-signature on each User ID before exporting the key (cf. GnuPG's --export-options export-minimal). In addition, implementors are advised to handle <policy-violation/> error responses when trying to transmit Base64 encoded keys.
The format of XMPP addresses, sometimes called JIDs, is well
defined. Thus they need to be normalized, as defined in
RFC 7622
This specification intentionally does not specify if the used OpenPGP key should be a primary key or a subkey. It is even possible to announce multiple public keys in the Personal Eventing Protocol node. Implementations MUST be prepared to find multiple public keys. The authors however believe that for ease of use only one OpenPGP key specially crafted for the XMPP use case should be created, announced and used.
The <openpgp/> and OpenPGP content elements are container
elements for arbitrary signed and encrypted data and can thus act
as building blocks for encrypted data included in Message, IQ and
Presence stanzas. For example, future specifications may use them
to implement encrypted versions of In-Band Bytestreams (XEP-0047)
Note that signed OpenPGP messages already contain a timestamp as per the OpenPGP specification. OpenPGP content elements nevertheless require the 'time' element because not every OpenPGP API may provide access to the embedded OpenPGP timestamp.
The 'rpad' element of the OpenPGP content elements exists to prevent length-based side channel attacks.
This specification addresses all relevant issues of Current Jabber OpenPGP Usage (XEP-0027)
Features like signed presences, which is provided by Current Jabber OpenPGP Usage (XEP-0027)
We decided against OpenPGP ASCII Armor (which contains an
additional checksum) and in favor for Base64, because
encoding should be part of the network application rather than the
crypto layer. Also XMPP, needs no additional error correction of payload.
In "MIME Security with OpenPGP" (RFC 3156
OpenPGP User IDs normally consist of a name - email address pair, e.g.,
"Juliet <juliet@example.org>" (RFC 4880
The scope of this XEP is intentionally limited, so that the specification just defines way for XMPP entities to discover, announce and synchronize OpenPGP keys, and how to exchange signed and encrypted data between two or more parties. Everything else is outside its scope. For example, how 'secure' the key material is protected on the endpoints is up to the implementation.
And while this XEP specifies a mechanism how to discover and retrieve a public key, it does not define how the trust relation to this key should be established. Even if key discovery and retrieval over XMPP provides a stronger coupling between the possessing entity (the XMPP address) and the key, as compared to the OpenPGP keyservers, how a XMPP server authenticates a remote server is a server policy, which does vary from server to server. Implementation MUST provide a way for the user to establish and assign trust to a public key. For example by using a QR code shown on the recipient's device screen.
Besides the protocol defined herein, OpenPGP implementations are another big attack surface. Needless to say that the security of encrypted data exchanged using this protocol depends on the security of the used OpenPGP implementation. It is strongly RECOMMENED to use existing implementations instead of writing your own. OpenPGP implementations have suffered from various vulnerabilities in the past which opened up DoS attack vectors. For example CVE-2013-4402 and CVE-2014-4717.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA)
The XMPP Registrar
TODO: Add after the XEP leaves the 'experimental' state.
Thanks to Emmanuel Gil Peyrot, Sergei Golovan, Marc Laporte, Georg Lukas, Adithya Abraham Philip, Brian Cully, fiaxh, Paul Schaub, Philipp Hörist and Stefan Kropp for their feedback.
The first draft of this specification was worked out and written on the wall of the 'Kymera' room in one of Google's buildings by the authors, consisting of members of the XMPP Standards Foundation and the OpenKeychain project, at the GSOC Mentors Summit 2015. The authors would like to thank Google for making it possible by bringing the right people together.