mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-22 07:38:52 -05:00
29bee13867
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@320 4b5297f7-1745-476d-ba37-a9c6900126ab
185 lines
9.6 KiB
XML
185 lines
9.6 KiB
XML
<?xml version='1.0' encoding='UTF-8'?>
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
|
%ents;
|
|
]>
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
|
<xep>
|
|
<header>
|
|
<title>Current Jabber OpenPGP Usage</title>
|
|
<abstract>This document outlines the current usage of OpenPGP for messaging and presence.</abstract>
|
|
&LEGALNOTICE;
|
|
<number>0027</number>
|
|
<status>Active</status>
|
|
<type>Historical</type>
|
|
<sig>Standards</sig>
|
|
<dependencies>
|
|
<spec>XMPP Core</spec>
|
|
</dependencies>
|
|
<supersedes/>
|
|
<supersededby/>
|
|
<shortname>openpgp</shortname>
|
|
<schemaloc>
|
|
<ns>jabber:x:encrypted</ns>
|
|
<url>http://www.xmpp.org/schemas/x-encrypted.xsd</url>
|
|
</schemaloc>
|
|
<schemaloc>
|
|
<ns>jabber:x:signed</ns>
|
|
<url>http://www.xmpp.org/schemas/x-signed.xsd</url>
|
|
</schemaloc>
|
|
&temas;
|
|
<revision>
|
|
<version>1.3</version>
|
|
<date>2006-11-29</date>
|
|
<initials>psa</initials>
|
|
<remark>Removed the unnecessary requirement that the presence status or message body must contain XML character data, since an empty string can be signed.</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>1.2</version>
|
|
<date>2004-03-08</date>
|
|
<initials>psa</initials>
|
|
<remark>Clarified the text in several places; added several more security considerations and known issues.</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>1.1</version>
|
|
<date>2004-01-06</date>
|
|
<initials>psa</initials>
|
|
<remark>Added XML schemas; added security, IANA, and XMPP Registrar considerations.</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>1.0</version>
|
|
<date>2002-04-23</date>
|
|
<initials>psa</initials>
|
|
<remark>Changed status to Active.</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.2</version>
|
|
<date>2002-04-11</date>
|
|
<initials>tjm</initials>
|
|
<remark>Merged DW's comments on key usage as well as more known issues.</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.1</version>
|
|
<date>2002-03-12</date>
|
|
<initials>tjm</initials>
|
|
<remark>First draft.</remark>
|
|
</revision>
|
|
</header>
|
|
<section1 topic='Introduction' anchor='intro'>
|
|
<p>The Jabber community has long acknowledged the need for privacy and security features in a well-rounded instant messaging system. Unfortunately, finding a consensus solution to the problem of end-to-end encryption during the community's younger days was not easy. Eventually, early contributors created a quick solution using OpenPGP. This specification documents the OpenPGP solution as it is used today, so that others may interoperate with clients that support it. This document is not intended to present a standard, because more complete solutions are being investigated.</p>
|
|
<p>All operations described here are done with standard OpenPGP software such as <link url='http://www.gnupg.org/'>GnuPG</link>. All program output is US-ASCII armored output with the headers removed. This allows for easy transportation of the program output directly in the XML. All keys are exchanged using OpenPGP key servers, and usually are retrieved when a signed &PRESENCE; stanza is received (key retrieval does not happen in-band).</p>
|
|
</section1>
|
|
<section1 topic='Signing' anchor='signing'>
|
|
<p>Signing enables a sender to verify that they sent a certain block of text. In Jabber, signing uses the 'jabber:x:signed' namespace, and is primarily used with &PRESENCE;, but may also be used with &MESSAGE;. The text that is signed MAY be the empty string. When signing presence, the sender SHOULD sign the XML character data of the <status> element. The sender SHOULD sign presence using the private key whose KeyID corresponds to the public key to be used in encrypting messages (see below).</p>
|
|
<example caption='A signed presence stanza'>
|
|
<presence from='pgmillard@jabber.org/wj_dev2' to='jer@jabber.org'>
|
|
<status>Online</status>
|
|
<x xmlns='jabber:x:signed'>
|
|
iQA/AwUBOjU5dnol3d88qZ77EQI2JACfRngLJ045brNnaCX78ykKNUZaTIoAoPHI
|
|
2uJxPMGR73EBIvEpcv0LRSy+
|
|
=45f8
|
|
</x>
|
|
</presence>
|
|
</example>
|
|
</section1>
|
|
<section1 topic='Encrypting' anchor='encrypting'>
|
|
<p>Encryption enables the sender to encrypt a message to a specific recipient. This is accomplished using the 'jabber:x:encrypted' namespace in conjunction with &MESSAGE; stanzas. Because a block of text is necessary in order to have something to encrypt, &MESSAGE; stanzas intended to be encrypted have the same restrictions as signing (see above). The data encrypted MUST be the XML character data of the <body> element. The sender SHOULD encrypt the message body using the public key whose KeyID corresponds to the private key used in signing presence (see above).</p>
|
|
<example caption='An encrypted message stanza'>
|
|
<message to='reatmon@jabber.org/jarl' from='pgmillard@jabber.org/wj_dev2'>
|
|
<body>This message is encrypted.</body>
|
|
<x xmlns='jabber:x:encrypted'>
|
|
qANQR1DBwU4DX7jmYZnncmUQB/9KuKBddzQH+tZ1ZywKK0yHKnq57kWq+RFtQdCJ
|
|
WpdWpR0uQsuJe7+vh3NWn59/gTc5MDlX8dS9p0ovStmNcyLhxVgmqS8ZKhsblVeu
|
|
IpQ0JgavABqibJolc3BKrVtVV1igKiX/N7Pi8RtY1K18toaMDhdEfhBRzO/XB0+P
|
|
AQhYlRjNacGcslkhXqNjK5Va4tuOAPy2n1Q8UUrHbUd0g+xJ9Bm0G0LZXyvCWyKH
|
|
kuNEHFQiLuCY6Iv0myq6iX6tjuHehZlFSh80b5BVV9tNLwNR5Eqz1klxMhoghJOA
|
|
w7R61cCPt8KSd8Vcl8K+StqOMZ5wkhosVjUqvEu8uJ9RupdpB/4m9E3gOQZCBsmq
|
|
OsX4/jJhn2wIsfYYWdqkbNKnuYoKCnwrlmn6I+wX72p0R8tTv8peNCwK9bEtL/XS
|
|
mhn4bCxoUkCITv3k8a+Jdvbov9ucduKSFuCBq4/l0fpHmPhHQjkFofxmaWJveFfF
|
|
619NXyYyCfoLTmWk2AaTHVCjtKdf1WmwcTa0vFfk8BuFHkdah6kJJiJ7w/yNwa/E
|
|
O6CMymuZTr/LpcKKWrWCt+SErxqmq8ekPI8h7oNwMxZBYAa7OJ1rXWKNgL9pDtNI
|
|
824Mf0mXj7q5N1eMHvX1QEoKLAda/Ae3TTEevOyeUK1DEgvxfM2KRZ11RzU+XtIE
|
|
My/bJk7EycAw8P/QKyeNlO1fxP58VEd6Gb8NCPqKOYn/LKh1O+c20ZNVEPFM4bNV
|
|
XA4hB4UtFF7Ao8kpdlrUqdKyw4lEtnmdemYQ6+iIIVPEarWl9PxOMY90KAnZrSAq
|
|
bt9uRY/1rPgelRaWblMKvxgpRO8++Y8VjdEyGgMOXxOiE851Ve72ftGzkSxDH8mW
|
|
TgY3pf2aATmBp3lagQ1COkGS/xupovT5AQPA3RzbCxDvc6s6eGYKmVVQVj5vmSj1
|
|
WULad5MB9KT1DzCm6FOSy063nWGBYYMWiejRvGLpo1j4eAnj0qOt7rTWmgv3RkYF
|
|
Oin0vDOhW7aC
|
|
=CvnG</x>
|
|
</message>
|
|
</example>
|
|
<p>It is considered polite to include an unencrypted message <body/> explaining that the actual message body is encrypted. This helps if the client experiences an error while decrypting the message, or if the user's a client that does not support encryption (although generally this should not happen, since the signed presence can be used to indicate that a client accepts encrypted messages).</p>
|
|
</section1>
|
|
<section1 topic='Security Considerations' anchor='security'>
|
|
<p>The method defined herein has the following security issues:</p>
|
|
<ul>
|
|
<li>Key exchange relies on the web of trust model used on the OpenPGP keys network.</li>
|
|
<li>There is no mechanism for checking a fingerprint or ownership of a key other than checking the user IDs on a key.</li>
|
|
<li>When the recipient is not mentioned in the encrypted body, replay attacks are possible on messages.</li>
|
|
<li>Replay of the signed &PRESENCE; status is possible.</li>
|
|
<li>It relies on signing or encryption of XML character data; therefore, it does not support signing or encryption of &IQ; stanzas, and it allows signing of the presence <status/> element and encryption of the message <body/> element only. Thus the method is not acceptable when signing or encryption of full stanzas is required.</li>
|
|
<li>It does not enable both signing and encryption of a stanza, only signing of the presence status and encryption of the message body.</li>
|
|
</ul>
|
|
</section1>
|
|
<section1 topic='Other Known Issues' anchor='issues'>
|
|
<p>In addition to the security considerations listed above, there are several other known issues with this method:</p>
|
|
<ul>
|
|
<li>It is limited to PGP keys and does not support X.509 certificates, Kerberos, RSA keys, etc.</li>
|
|
<li>It does not include feature negotiation; instead, signed &PRESENCE; is used as an indicator of support. Because of the lack of negotiation it is possible for encrypted &MESSAGE; elements to be stored offline and then read by a client that cannot support them.</li>
|
|
<li>It is verbose (the example encrypted &MESSAGE; is "Hi").</li>
|
|
</ul>
|
|
</section1>
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
|
<p>This document requires no interaction with &IANA;.</p>
|
|
</section1>
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
|
<p>The ®ISTRAR; shall register the 'jabber:x:encrypted' and 'jabber:x:signed' namespaces as a result of this document.</p>
|
|
</section1>
|
|
<section1 topic='XML Schemas' anchor='schemas'>
|
|
<section2 topic='jabber:x:encrypted' anchor='schemas-encrypted'>
|
|
<code><![CDATA[
|
|
<?xml version='1.0' encoding='UTF-8'?>
|
|
|
|
<xs:schema
|
|
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
|
targetNamespace='jabber:x:encrypted'
|
|
xmlns='jabber:x:encrypted'
|
|
elementFormDefault='qualified'>
|
|
|
|
<xs:annotation>
|
|
<xs:documentation>
|
|
The protocol documented by this schema is defined in
|
|
XEP-0027: http://www.xmpp.org/extensions/xep-0027.html
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
|
|
<xs:element name='x' type='xs:string'/>
|
|
|
|
</xs:schema>
|
|
]]></code>
|
|
</section2>
|
|
<section2 topic='jabber:x:signed' anchor='schemas-signed'>
|
|
<code><![CDATA[
|
|
<?xml version='1.0' encoding='UTF-8'?>
|
|
|
|
<xs:schema
|
|
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
|
targetNamespace='jabber:x:signed'
|
|
xmlns='jabber:x:signed'
|
|
elementFormDefault='qualified'>
|
|
|
|
<xs:annotation>
|
|
<xs:documentation>
|
|
The protocol documented by this schema is defined in
|
|
XEP-0027: http://www.xmpp.org/extensions/xep-0027.html
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
|
|
<xs:element name='x' type='xs:string'/>
|
|
|
|
</xs:schema>
|
|
]]></code>
|
|
</section2>
|
|
</section1>
|
|
</xep>
|