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 (&rfc4648; § 4) OpenPGP message as specified in &rfc4880; which contains an encrypted and/or signed UTF-8 (&rfc3629;) encoded string. This string MUST correspond to exactly one OpenPGP content element, that is, it represents either a &signcrypt;, a &sign; or a &crypt; extension element qualified by the 'urn:xmpp:openpgp:0' namespace. Note that OpenPGP's ASCII Armor is not used, instead the XMPP client MUST encode the raw bytes of OpenPGP message using Base64.

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 &crypt; 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 AttacksJee Hea An, Yevgeniy Dodis, and Tal Rabin. 2002. On the Security of Joint Signature and Encryption. In Proceedings of the International Conference on the Theory and Applications of Cryptographic Techniques: Advances in Cryptology (EUROCRYPT '02), Lars R. Knudsen (Ed.). Springer-Verlag, London, UK, UK, 83-107. <https://www.iacr.org/archive/eurocrypt2002/23320080/adr.pdf>. The XMPP address found in the 'to' element's 'jid' attribute SHOULD be without Resourcepart (i.e., a bare JID). A &sign; content element may not carry a 'to' attribute. The 'time' element MUST have a 'stamp' attribute which contains the timestamp when the OpenPGP content element was signed and/or encrypted in the DateTime format as specified in &xep0082; § 3.2. The &signcrypt; and &crypt; elements SHOULD furthermore contain a 'rpad' element which text content is a random-length random-content padding.

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 &xep0374;).

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.

In order to announce the public key, the client needs to store it in a PEP node. The public key data, as specified in RFC 4880, is stored within a <pubkey/> element which is a child element of the <pubkeys/> element qualified by the 'urn:xmpp:openpgp:0' namespace. Note that OpenPGP's ASCII Armor is not used, instead the XMPP client MUST encode the public key using Base64. Clients MAY only try to store the public key if the Personal Eventing Protocol service supports persistent-items, thus they possibly check if the service reports the 'http://jabber.org/protocol/pubsub#persistent-items' feature.

In order to discover the public key of an XMPP entity, clients send a PubSub &IQ; request to the entity's bare JID of which it wants to know the public key.

Note that the result may contain multiple pubkey elements. Only the public keys found in the most recent 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 &xep0059; as an alternative to 'max_items' but accoding to XEP-0060 RSM is not (yet) mandatory for PubSub services.

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.

The used PEP server MUST support PEP and the whitelist access model. It SHOULD also support persistent items.

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.

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:

1. All secret keys that should be included in the backup MUST be concatenated in their transferable key format (RFC 4880 § 11.1).
2. A backup code is generated from secure random: The backup code consists of 24 upper case characters from the Latin alphabet and numbers without 'O' ("LATIN CAPITAL LETTER O") and '0' ("DIGIT ZERO") (alphabet: 123456789ABCDEFGHIJKLMNPQRSTUVWXYZ) grouped into 4-character chunks, e.g., TWNK-KD5Y-MT3T-E1GS-DRDB-KVTW. The characters MUST be generated from cryptographically secure random. For example getrandom(2), SecureRandom or /dev/urandom. More information about the randomness requirements for security can be found in &rfc4086;
3. The whole backup code including the dashes is directly used as a string to encrypt the concatenated transferable keys as an OpenPGP message. More precisely: It is used as the symmetric-key for a Symmetric-Key Encrypted Session Key Packet according to RFC 4880 § 5.3; the symmetric-key is thus 29 characters long including the dashes. The encryption algorithm MUST be one of the standardized OpenPGP symmetric algorithms, e.g, AES-128.

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 PubSub nodes specified by herein 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 XEP-0060 § 16.4.4).

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 STEEDKoch, Werner, and Marcus Brinkman "STEED — Usable End-to-End Encryption", White Paper, g10 GmbH, 2011-10-17. <http://g10code.com/steed.html> and "Why Johnny can't encrypt"Whitten, Alma, and J. Doug Tygar. "Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0." Usenix Security. Vol. 1999. 1999. <https://www.cs.berkeley.edu/~tygar/papers/Why_Johnny_Cant_Encrypt/OReilly.pdf>. Implementors of this XEP are encouraged to provide the concepts described in STEED:

• Automatic key generation
• Automatic key distribution
• Opportunistic encryption
• Trust upon first contact

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 &rfc7622;. When implementations are required to compare XMPP addresses for equality, as it is the case in "Verification of &openpgp; Content", then they also have to compare the normalized versions of the addresses.

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 &xep0047; or &xep0261;.

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 &xep0027; (§ 4, § 5). It mitigates replay attacks by including the recipient's address and a timestamp in the OpenPGP content elementFull Replay attack prevention would require a counter based approach.. It allows for both, signing and encrypting of the element. The scope of the specification was deliberately limited to OpenPGP.

Features like signed presences, which is provided by XEP-0027, may be added later on as add-on XEP to this.

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" (&rfc3156;), ASCII Armor has only been chosen to be backwards compatible with legacy applications supporting non-MIME OpenPGP emails only.

OpenPGP User IDs normally consist of a name - email address pair, e.g., "Juliet <juliet@example.org>" (RFC 4880 § 5.11). For this XEP, we require User IDs of the format "xmpp:juliet@example.org". First, it is required to have at least one User ID indicating the use of this OpenPGP key. When doing certification of keys (key signing), the partner must know what User ID she actually certifies. Second, this format uses the standardized URI from XEP-0147 to indicate that this User ID corresponds to a key that is used for XMPP. Third, having the Real Name inside provides no additional security or guideline if this key should be certified. The XMPP address is the only trust anchor here.

The ®ISTRAR; includes 'urn:xmpp:openpgp:0' in its registry of protocol namespaces (see &NAMESPACES;).