[Pidgin] EndToEndXMPPCrypto modified

Sat Jan 25 21:28:45 EST 2014

Page "EndToEndXMPPCrypto" was changed by elb
Diff URL: <https://developer.pidgin.im/wiki/EndToEndXMPPCrypto?action=diff&version=7>
Revision 7
Changes:
-------8<------8<------8<------8<------8<------8<------8<------8<--------
Index: EndToEndXMPPCrypto
=========================================================================

--- EndToEndXMPPCrypto (version: 6)
+++ EndToEndXMPPCrypto (version: 7)
@@ -28,3 +28,16 @@
  * '''Streamlined one-on-one Chat.'''  An equivalent protocol to the XMPP simple <message> stanza with a cleartext <body>, only encrypted and authenticated.  The point of this protocol is to minimize overhead for typical one-on-one chat, for the benefit of mobile and bandwidth- or computationally-constrained clients.
  * '''Arbitrary protected stanzas.'''  A method should be provided for protecting arbitrary end-to-end XMPP stanzas, either with only authentication or with both authentication and encryption.  An example mechanism supporting this point would be an e2e encrypted data stanza simply containing a standard XMPP stanza that has been encrypted and authenticated that is unwrapped at the receiving client and then processed as if it had been in place of the encrypted stanza.  Existing standards and best practices for encrypting partial XML documents should be consulted.
  * '''A plurality of key authentication mechanisms.'''  The public key exchange mechanism should allow for multiple disparate authentication methods to be communicated.  For example, an S/MIME signature using a PKI x.509 certificate and a GPG signature of the same key material might be provided, along side whatever native signing protocol is used.  These authentication mechanisms should be readily extensible and have enough structure that useful mechanisms can be clearly defined.  Note that the client itself need not handle mechanisms it does not understand, but mechanisms should be designed such that the client can present the information to the user in a form that lends itself to validation -- ''e.g.'', a GPG signature might simply be presented as an ASCII armored text block.
+ * '''Opportunistic encryption.'''  Indication of encryption and authentication capabilities should be provided in some way to clients who are not on our roster or who do not have us in their roster, so that encryption may be used opportunistically.  This should include a way to exchange keys and key authentication materials.  Some sort of access control may be required to prevent automated exchanges from becoming a DoS or privacy attack vector.
+
+== Relevant Protocols ==
+
+ * '''OTR:''' https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html
+
+ The gold standard in open IM encryption protocols.  There's plenty to learn here.  I'm personally not interested in the non-repudiation aspect.  Wholly protocol-independent, so does not provide any presence integration or protection of XMPP stanzas.  Does include key authentication and negotation, opportunistic encryption, etc.
+ * '''OpenPGP on Jabber:''' http://xmpp.org/extensions/xep-0027.html
+
+ Not exactly a standardized protocol, ''per se'', so much as simply documentation of existing clients.  Provides a mechanism for both authenticating and encrypting certain stanzas.  Does not provide key exchange or presence integration.
+ * '''XMPP XTLS:''' https://tools.ietf.org/id/draft-meyer-xmpp-e2e-encryption-02.txt
+
+ Provides e2e encryption between XML endpoints over Jingle.  Appears to be a dead effort.
-------8<------8<------8<------8<------8<------8<------8<------8<--------

--
Page URL: <https://developer.pidgin.im/wiki/EndToEndXMPPCrypto>
Pidgin <https://pidgin.im>
Pidgin

This is an automated message. Someone added your email address to be
notified of changes on 'EndToEndXMPPCrypto' page.
If it was not you, please report to datallah at pidgin.im.
