mirror of
https://github.com/moparisthebest/xeps
synced 2024-10-31 15:35:07 -04:00
261 lines
9.4 KiB
XML
261 lines
9.4 KiB
XML
<?xml version='1.0' encoding='UTF-8'?>
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
<!ENTITY signcrypt "<signcrypt/>">
|
|
<!ENTITY sign "<sign/>">
|
|
<!ENTITY crypt "<crypt/>">
|
|
<!ENTITY openpgp "<openpgp/>">
|
|
<!ENTITY payload "<payload/>">
|
|
<!ENTITY rfc3629 "<span class='ref'><link url='http://tools.ietf.org/html/rfc3629'>RFC 3629</link></span> <note>RFC 3629: UTF-8, a transformation format of ISO 10646 <<link url='http://tools.ietf.org/html/rfc3629'>http://tools.ietf.org/html/rfc3629</link>>.</note>" >
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
|
%ents;
|
|
]>
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
|
<xep>
|
|
<header>
|
|
<title>OpenPGP for XMPP Instant Messaging</title>
|
|
<abstract>Specifies a OpenPGP for XMPP (XEP-0373) profile for the Instant
|
|
Messaging (IM) use case.</abstract>
|
|
&LEGALNOTICE;
|
|
<number>0374</number>
|
|
<status>Deferred</status>
|
|
<type>Standards Track</type>
|
|
<sig>Standards</sig>
|
|
<approver>Council</approver>
|
|
<dependencies>
|
|
<spec>XMPP Core</spec>
|
|
<spec>XEP-0030</spec>
|
|
<spec>XEP-0373</spec>
|
|
</dependencies>
|
|
<supersedes/>
|
|
<supersededby/>
|
|
<shortname>oxim</shortname>
|
|
&flow;
|
|
<author>
|
|
<firstname>Dominik</firstname>
|
|
<surname>Schürmann</surname>
|
|
<email>dominik@dominikschuermann.de</email>
|
|
<jid>dominik@dominikschuermann.de</jid>
|
|
</author>
|
|
<author>
|
|
<firstname>Vincent</firstname>
|
|
<surname>Breitmoser</surname>
|
|
<email>look@my.amazin.horse</email>
|
|
<jid>valodim@stratum0.org</jid>
|
|
</author>
|
|
<revision>
|
|
<version>0.2.0</version>
|
|
<date>2018-01-25</date>
|
|
<initials>XEP Editor (jwi)</initials>
|
|
<remark>Defer due to lack of activity.</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.1.2</version>
|
|
<date>2017-01-20</date>
|
|
<initials>fs</initials>
|
|
<remark><p>Make use of XEP-0380: Explicit Message Encryption.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.1.1</version>
|
|
<date>2016-06-04</date>
|
|
<initials>fs</initials>
|
|
<remark><p>Minior editorial fixes.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.1</version>
|
|
<date>2016-05-10</date>
|
|
<initials>XEP Editor (ssw)</initials>
|
|
<remark><p>Initial published version approved by the XMPP Council.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.1</version>
|
|
<date>2016-03-25</date>
|
|
<initials>fs</initials>
|
|
<remark><p>First draft.</p></remark>
|
|
</revision>
|
|
</header>
|
|
|
|
<section1 topic='Introduction' anchor='intro'>
|
|
|
|
<p>This XMPP extension protocol specifies a profile of &xep0373; for OpenPGP
|
|
secured Instant Messaging (IM).</p>
|
|
|
|
<p>Unlike similar XEPs, e.g., &xep0384;, this XEP <em>does not</em>
|
|
provide Forward Secrecy (FS), but as an advantage in return, allows
|
|
users to read their archived conversations (respectively their
|
|
encrypted data) later on. Of course, only as long as they still
|
|
possess the according secret key. FS and being able to decrypt
|
|
archived messages are mutually exclusive, i.e., one can not have
|
|
both. The authors therefore consider this XEP complementary to
|
|
similar ones which also provide end-to-end encryption but with a
|
|
different feature set.</p>
|
|
|
|
</section1>
|
|
|
|
<section1 topic='OX Instant Messaging Profile' anchor='ox-im-profile'>
|
|
|
|
<section2 topic='Discovering Support' anchor='disco'>
|
|
|
|
<p>If an entity supports exchanging OpenPGP encrypted and signed
|
|
instant messages over XMPP, i.e., what is specified herein, it MUST
|
|
advertise that fact by announcing a &xep0030; feature of
|
|
'urn:xmpp:openpgp:im:0'. It thus includes this feature in response
|
|
to a service discovery request.</p>
|
|
|
|
<example caption="Service Discovery information request"><![CDATA[
|
|
<iq type='get'
|
|
from='juliet@example.org/balcony'
|
|
to='romeo@example.org/orchard'
|
|
id='disco1'>
|
|
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
|
</iq>]]></example>
|
|
<example caption="Service Discovery information response"><![CDATA[
|
|
<iq type='result'
|
|
from='romeo@example.org/orchard'
|
|
to='juliet@example.org/balcony'
|
|
id='disco1'>
|
|
<query xmlns='http://jabber.org/protocol/disco#info'>
|
|
...
|
|
<feature var='urn:xmpp:openpgp:im:0'/>
|
|
...
|
|
</query>
|
|
</iq>]]></example>
|
|
|
|
<p>Because of possible downgrade attacks, users should be given an
|
|
option to force the usage of the protocol defined herein no matter
|
|
if the remote announces support or not.</p>
|
|
|
|
</section2>
|
|
|
|
<section2 topic='OpenPGP Secured Instant Messaging' anchor='openpgp-secured-im'>
|
|
|
|
<p>In order to establish an OpenPGP secured IM communication, IM
|
|
clients first need to determine the public key of their
|
|
interlocutor(s). OpenPGP historically provides public keyservers
|
|
which can be used for key retrieval. Additional there are methods
|
|
to store OpenPGP key information in the Domain Name
|
|
System (DNS). This specification does not restrict the mechanism
|
|
of key discovery and retrieval, but compliant clients MUST support
|
|
the public key announcement as described in <cite>XEP-0373</cite>
|
|
<link url='./xep-0373.html#announcing-discover-pubkey'>§ 4</link>.</p>
|
|
|
|
<p>After the required public keys have been discovered, XMPP
|
|
clients engage in an OpenPGP secured IM
|
|
conversation by exchanging &openpgp; extension elements. They MUST
|
|
use the &signcrypt; OpenPGP content element specified in
|
|
<cite>XEP-0373</cite><link url='./xep-0373.html#exchange'>§ 3.1</link>.</p>
|
|
|
|
<p>The child elements of the OpenPGP content element's &payload;
|
|
can be seen as stanza extension elements which are encrypted and
|
|
signed. After the &openpgp; element and the including &signcrypt;,
|
|
element was verified, they SHOULD be processed similar as if they
|
|
had been direct extension elements of the stanza. For example,
|
|
direct child elements found in &payload; in the context of IM
|
|
could be:</p>
|
|
|
|
<ul>
|
|
<li>Message bodies (&rfc6121; § 5.2.3): <body xmlns='jabber:client'/> </li>
|
|
<li>&xep0085;: <active xmlns='http://jabber.org/protocol/chatstates'/></li>
|
|
<li>&xep0071;: <html xmlns='http://jabber.org/protocol/xhtml-im'/></li>
|
|
</ul>
|
|
|
|
<p>But just as with stanza extension elements, child elements of
|
|
&payload; can be any extension element. The example above uses
|
|
the <body/> element as defined in RFC 6121. Note that it
|
|
uses 'jabber:client' as namespace, but since the same
|
|
<body/> element is also defined in the 'jabber:server'
|
|
namespace, recipients MUST accept both.</p>
|
|
|
|
</section2>
|
|
|
|
<section2 topic='OpenPGP Key Handling' anchor='openpgp-key-handling'>
|
|
|
|
<section3 topic='Choosing Public Keys' anchor='choose-pubkey'>
|
|
|
|
<p>Clients MUST expect multiple public keys to be announced for a single remote entity. In this case all keys MUST be used for encryption.</p>
|
|
|
|
</section3>
|
|
|
|
<section3 topic='OpenPGP Secret Key Synchronization' anchor='openpgp-secret-key-sync'>
|
|
|
|
<p>Clients MAY want to use the mechanism in <cite>XEP-0373 § 5</cite> to
|
|
synchronize their secret key(s) over multiple devices. Thus, they
|
|
should query the user's PEP service for an eventually stored
|
|
encrypted secret key.</p>
|
|
|
|
</section3>
|
|
|
|
</section2>
|
|
|
|
</section1>
|
|
|
|
<section1 topic='Business Rules' anchor='rules'>
|
|
|
|
<section2 topic='Always Use &signcrypt;' anchor='signcrypt-im-use-case'>
|
|
|
|
<p>Only &signcrypt; MUST be used for the IM
|
|
use case. Encrypted but unsigned messages (&crypt;) do not provide
|
|
an advantage over unencrypted ones since the sender can not be
|
|
verified. As result of this rule, the user interface of
|
|
IM clients implementing the protocol defined herein MUST NOT
|
|
provide an option for the user to select between sign+crypt, sign
|
|
or crypt. This also increases the usability.</p>
|
|
|
|
</section2>
|
|
|
|
<section2 topic='Provide Hints' anchor='hint-im-use-case'>
|
|
|
|
<p>In the IM use case every &MESSAGE; equipped with &openpgp;
|
|
SHOULD include an unencrypted <body/> explaining that the actual
|
|
message is encrypted. Furthermore the message SHOULD contain a
|
|
'store' hint as defined in &xep0334; <link
|
|
url='https://xmpp.org/extensions/xep-0334.html#sect-idp1502160'>§
|
|
4.4</link> and a "this message contains an encrypted body text" hint
|
|
in form of an <encryption/> extension element as specified by
|
|
&xep0380;.</p>
|
|
|
|
<example caption='An encrypted and signed message with hints.'><![CDATA[
|
|
<message to='juliet@example.org'>
|
|
<body>This message is encrypted using OpenPGP.</body>
|
|
<store xmlns='urn:xmpp:hints'/>
|
|
<encryption xmlns='urn:xmpp:eme:0' namespace='urn:xmpp:openpgp:0'/>
|
|
<openpgp xmlns='urn:xmpp:openpgp:0'>
|
|
BASE64_OPENPGP_MESSAGE_CONTAINING_CONTENT_ELEMENT
|
|
</openpgp>
|
|
</message>]]></example>
|
|
|
|
</section2>
|
|
|
|
</section1>
|
|
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
|
|
|
<p>This document requires no interaction with &IANA;.</p>
|
|
|
|
</section1>
|
|
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
|
|
|
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
|
|
|
|
<p>The ®ISTRAR; includes 'urn:xmpp:openpgp:0' in its registry of protocol namespaces (see &NAMESPACES;).</p>
|
|
|
|
</section2>
|
|
|
|
</section1>
|
|
|
|
<section1 topic='XML Schema' anchor='schema'>
|
|
|
|
<p>This XEP does not define a Schema, since it exclusively uses elements from
|
|
<cite>XEP-0373</cite> and other XEPs.</p>
|
|
|
|
</section1>
|
|
|
|
<section1 topic='Acknowledgements' anchor='acknowledgements'>
|
|
<p>
|
|
Please refer to the
|
|
<link url='./xep-0373.html#acknowledgements'>Acknowledgements section</link>
|
|
of <cite>XEP-0373</cite> since the two XEPs where designed together.
|
|
</p>
|
|
</section1>
|
|
</xep>
|