draft-ietf-xmpp-e2e-04.txt   draft-ietf-xmpp-e2e-05.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Jabber Software Foundation Internet-Draft Jabber Software Foundation
Expires: December 28, 2003 June 29, 2003 Expires: February 20, 2004 August 22, 2003
End-to-End Object Encryption in XMPP End-to-End Object Encryption in XMPP
draft-ietf-xmpp-e2e-04 draft-ietf-xmpp-e2e-05
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 30 skipping to change at page 1, line 30
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 28, 2003. This Internet-Draft will expire on February 20, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document defines a method for end-to-end object signing and This document defines a method for end-to-end object signing and
encryption in the Extensible Messaging and Presence Protocol (XMPP). encryption in the Extensible Messaging and Presence Protocol (XMPP).
skipping to change at page 2, line 23 skipping to change at page 2, line 23
4. Securing Presence . . . . . . . . . . . . . . . . . . . . . . 8 4. Securing Presence . . . . . . . . . . . . . . . . . . . . . . 8
5. Securing Arbitrary XMPP Data . . . . . . . . . . . . . . . . . 10 5. Securing Arbitrary XMPP Data . . . . . . . . . . . . . . . . . 10
6. Rules for S/MIME Generation and Handling . . . . . . . . . . . 12 6. Rules for S/MIME Generation and Handling . . . . . . . . . . . 12
6.1 Certificate Enrollment . . . . . . . . . . . . . . . . . . . . 12 6.1 Certificate Enrollment . . . . . . . . . . . . . . . . . . . . 12
6.2 Certificate Retrieval . . . . . . . . . . . . . . . . . . . . 12 6.2 Certificate Retrieval . . . . . . . . . . . . . . . . . . . . 12
6.3 Certificate Names . . . . . . . . . . . . . . . . . . . . . . 12 6.3 Certificate Names . . . . . . . . . . . . . . . . . . . . . . 12
6.4 Transfer Encoding . . . . . . . . . . . . . . . . . . . . . . 13 6.4 Transfer Encoding . . . . . . . . . . . . . . . . . . . . . . 13
6.5 Attachment of Signatures . . . . . . . . . . . . . . . . . . . 13 6.5 Attachment of Signatures . . . . . . . . . . . . . . . . . . . 13
6.6 Inclusion of Certificates . . . . . . . . . . . . . . . . . . 13 6.6 Inclusion of Certificates . . . . . . . . . . . . . . . . . . 13
6.7 Mandatory to Implement Technologies . . . . . . . . . . . . . 13 6.7 Mandatory to Implement Technologies . . . . . . . . . . . . . 13
7. Secure Communications Through a Gateway . . . . . . . . . . . 14 7. Secure Communications Through a Gateway . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1 Content-type Registration for "application/xmpp+xml" . . . . . 15 8.1 Content-type Registration for "application/xmpp+xml" . . . . . 16
8.2 XML Namespace Name for e2e Data in XMPP . . . . . . . . . . . 15 8.2 XML Namespace Name for e2e Data in XMPP . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
Normative References . . . . . . . . . . . . . . . . . . . . . 18 Normative References . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19 Informative References . . . . . . . . . . . . . . . . . . . . 21
A. Schema for urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21
B. Revision History . . . . . . . . . . . . . . . . . . . . . . . 21 A. Schema for urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . . 22
B.1 Changes from draft-ietf-xmpp-e2e-03 . . . . . . . . . . . . . 21 B. Revision History . . . . . . . . . . . . . . . . . . . . . . . 23
B.2 Changes from draft-ietf-xmpp-e2e-02 . . . . . . . . . . . . . 21 B.1 Changes from draft-ietf-xmpp-e2e-04 . . . . . . . . . . . . . 23
B.3 Changes from draft-ietf-xmpp-e2e-01 . . . . . . . . . . . . . 21 B.2 Changes from draft-ietf-xmpp-e2e-03 . . . . . . . . . . . . . 23
B.4 Changes from draft-ietf-xmpp-e2e-00 . . . . . . . . . . . . . 21 B.3 Changes from draft-ietf-xmpp-e2e-02 . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 23 B.4 Changes from draft-ietf-xmpp-e2e-01 . . . . . . . . . . . . . 23
B.5 Changes from draft-ietf-xmpp-e2e-00 . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 25
1. Introduction 1. Introduction
This document define a method for end-to-end signing and encryption This document define a method for end-to-end signing and encryption
in the Extensible Messaging and Presence Protocol (XMPP). (For in the Extensible Messaging and Presence Protocol (XMPP). (For
information about XMPP, see XMPP Core [1] and XMPP IM [2].) The information about XMPP, see XMPP Core [1] and XMPP IM [2].) The
method defined herein enables a sender to encrypt and/or sign an method defined herein enables a sender to encrypt and/or sign an
instant message sent to a specific recipient, encrypt and/or sign instant message sent to a specific recipient, encrypt and/or sign
presence information that is directed to a specific user, and sign presence information that is directed to a specific user, and sign
presence information that is broadcasted to a specific user. This presence information that is broadcasted to a specific user. This
skipping to change at page 6, line 25 skipping to change at page 6, line 25
3. Provide the resulting multipart S/MIME object (see RFC 1847 [12]) 3. Provide the resulting multipart S/MIME object (see RFC 1847 [12])
as the CDATA of an <e2e/> child of a <message/> stanza, with the as the CDATA of an <e2e/> child of a <message/> stanza, with the
<e2e/> element scoped by the 'urn:ietf:params:xml:ns:xmpp-e2e' <e2e/> element scoped by the 'urn:ietf:params:xml:ns:xmpp-e2e'
namespace (note that this namespace name adheres to the format namespace (note that this namespace name adheres to the format
defined in The IANA XML Registry [13]). defined in The IANA XML Registry [13]).
Example 1: Sender generates "Message/CPIM" object: Example 1: Sender generates "Message/CPIM" object:
Content-type: Message/CPIM Content-type: Message/CPIM
From: Juliet Capulet <im:juliet@capulet.com> From: Juliet Capulet <im:juliet@example.com>
To: Romeo Montague <im:romeo@montague.net> To: Romeo Montague <im:romeo@example.net>
DateTime: 2003-05-14T11:45:36Z DateTime: 2003-05-14T11:45:36Z
Subject: Imploring Subject: Imploring
Content-type: text/plain; charset=utf-8 Content-type: text/plain; charset=utf-8
Content-ID: <1234567890@capulet.com> Content-ID: <1234567890@example.com>
Wherefore art thou, Romeo? Wherefore art thou, Romeo?
Example 2: Sender generates signed message (the 'from' address on the Example 2: Sender generates signed message (the 'from' address on the
XMPP message stanza is stamped by sender's server): XMPP message stanza is stamped by sender's server):
<message to='romeo@montague.net/orchard' type='chat'> <message to='romeo@example.net/orchard' type='chat'>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'> <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
<![CDATA[ <![CDATA[
Content-Type: multipart/signed; boundary=next; Content-Type: multipart/signed; boundary=next;
micalg=sha1; micalg=sha1;
protocol=application/pkcs7-signature protocol=application/pkcs7-signature
--next --next
Content-type: Message/CPIM Content-type: Message/CPIM
From: Juliet Capulet <im:juliet@capulet.com> From: Juliet Capulet <im:juliet@example.com>
To: Romeo Montague <im:romeo@montague.net> To: Romeo Montague <im:romeo@example.net>
DateTime: 2003-05-14T23:45:36Z DateTime: 2003-05-14T23:45:36Z
Subject: Imploring Subject: Imploring
Content-type: text/plain; charset=utf-8 Content-type: text/plain; charset=utf-8
Content-ID: <1234567890@capulet.com> Content-ID: <1234567890@example.com>
Wherefore art thou, Romeo? Wherefore art thou, Romeo?
--next --next
Content-Type: application/pkcs7-signature Content-Type: application/pkcs7-signature
[signed body part] [signed body part]
--next-- --next--
]]> ]]>
</e2e> </e2e>
skipping to change at page 8, line 28 skipping to change at page 8, line 28
namespace name adheres to the format defined in The IANA XML namespace name adheres to the format defined in The IANA XML
Registry [13]). The <presence/> stanza MUST include a 'to' Registry [13]). The <presence/> stanza MUST include a 'to'
attribute, i.e., it must be an instance of directed presence as attribute, i.e., it must be an instance of directed presence as
defined in XMPP IM [2]. defined in XMPP IM [2].
Example 3: Sender generates "application/pidf+xml" object: Example 3: Sender generates "application/pidf+xml" object:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:im="urn:ietf:params:xml:ns:pidf:im" xmlns:im="urn:ietf:params:xml:ns:pidf:im"
entity="pres:juliet@capulet.com"> entity="pres:juliet@example.com">
<tuple id="h40zny" <tuple id="h40zny"
<status> <status>
<basic>open</basic> <basic>open</basic>
<im:im>away</im:im> <im:im>away</im:im>
</status> </status>
<note xml:lang="en">retired to the chamber</note> <note xml:lang="en">retired to the chamber</note>
<timestamp>2003-05-14T23:53:11Z</timestamp> <timestamp>2003-05-14T23:53:11Z</timestamp>
</tuple> </tuple>
</presence> </presence>
Example 4: Sender generates signed presence (the 'from' address on Example 4: Sender generates signed presence (the 'from' address on
the XMPP presence stanza is stamped by sender's server): the XMPP presence stanza is stamped by sender's server):
<presence to='romeo@montague.net/orchard'> <presence to='romeo@example.net/orchard'>
<e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'> <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
<![CDATA[ <![CDATA[
Content-Type: multipart/signed; boundary=next; Content-Type: multipart/signed; boundary=next;
micalg=sha1; micalg=sha1;
protocol=application/pkcs7-signature protocol=application/pkcs7-signature
--next --next
Content-type: application/pidf+xml Content-type: application/pidf+xml
Content-ID: <2345678901@capulet.com> Content-ID: <2345678901@example.com>
<xml version="1.0" encoding="UTF-8"?> <xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:im="urn:ietf:params:xml:ns:pidf:im" xmlns:im="urn:ietf:params:xml:ns:pidf:im"
entity="pres:juliet@capulet.com"> entity="pres:juliet@example.com">
<tuple id="h40zny" <tuple id="hr0zny">
<status> <status>
<basic>open</basic> <basic>open</basic>
<im:im>away</im:im> <im:im>away</im:im>
</status> </status>
<note xml:lang="en">retired to the chamber</note> <note xml:lang="en">retired to the chamber</note>
<timestamp>2003-05-14T23:53:11Z</timestamp> <timestamp>2003-05-14T23:53:11Z</timestamp>
</tuple> </tuple>
</presence> </presence>
--next --next
Content-Type: application/pkcs7-signature Content-Type: application/pkcs7-signature
skipping to change at page 10, line 34 skipping to change at page 10, line 34
The following examples illustrate the structure of the "application/ The following examples illustrate the structure of the "application/
xmpp+xml" MIME type. xmpp+xml" MIME type.
Example 5: Message stanza with extended data contained in Example 5: Message stanza with extended data contained in
"application/xmpp+xml" MIME type: "application/xmpp+xml" MIME type:
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<xmpp xmlns='jabber:client'> <xmpp xmlns='jabber:client'>
<message <message
from='iago@shakespeare.lit/pda' from='iago@example.com/pda'
to='emilia@shakespeare.lit/cell'> to='emilia@example.com/cell'>
<body> <body>
I told him what I thought, and told no more I told him what I thought, and told no more
Than what he found himself was apt and true. Than what he found himself was apt and true.
</body> </body>
<evil xmlns='http://jabber.org/protocol/evil'/> <evil xmlns='http://jabber.org/protocol/evil'/>
</message> </message>
</xmpp> </xmpp>
Example 6: Presence stanza with extended data contained in Example 6: Presence stanza with extended data contained in
"application/xmpp+xml" MIME type: "application/xmpp+xml" MIME type:
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<xmpp xmlns='jabber:client'> <xmpp xmlns='jabber:client'>
<presence from='iago@shakespeare.lit/pda'> <presence from='iago@example.com/pda'>
<show>dnd</show> <show>dnd</show>
<status>Fomenting dissension</status> <status>Fomenting dissension</status>
<evil xmlns='http://jabber.org/protocol/evil'/> <evil xmlns='http://jabber.org/protocol/evil'/>
</presence> </presence>
</xmpp> </xmpp>
Example 7: IQ stanza with extended data contained in "application/ Example 7: IQ stanza with extended data contained in "application/
xmpp+xml" MIME type: xmpp+xml" MIME type:
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<xmpp xmlns='jabber:client'> <xmpp xmlns='jabber:client'>
<iq type='result' <iq type='result'
from='iago@shakespeare.lit/pda' from='iago@example.com/pda'
to='emilia@shakespeare.lit/cell' to='emilia@example.com/cell'
id='evil1'> id='evil1'>
<query xmlns='jabber:iq:version'> <query xmlns='jabber:iq:version'>
<name>Stabber</name> <name>Stabber</name>
<version>666</version> <version>666</version>
<os>FiendOS</os> <os>FiendOS</os>
</query> </query>
<evil xmlns='http://jabber.org/protocol/evil'/> <evil xmlns='http://jabber.org/protocol/evil'/>
</iq> </iq>
</xmpp> </xmpp>
skipping to change at page 12, line 34 skipping to change at page 12, line 34
At a minimum, for initial S/MIME deployment, a user agent could At a minimum, for initial S/MIME deployment, a user agent could
automatically generate a message to an intended recipient requesting automatically generate a message to an intended recipient requesting
that recipient's certificate in a signed return message. Receiving that recipient's certificate in a signed return message. Receiving
and sending agents SHOULD also provide a mechanism to allow a user to and sending agents SHOULD also provide a mechanism to allow a user to
"store and protect" certificates for correspondents in such a way so "store and protect" certificates for correspondents in such a way so
as to guarantee their later retrieval. as to guarantee their later retrieval.
6.3 Certificate Names 6.3 Certificate Names
End-entity certificates used in the context of this document SHOULD End-entity certificates used in the context of this document SHOULD a
contain a XMPP address as described in XMPP Core [1]. The address valid instant messaging address. The address SHOULD be one of the
SHOULD be in the form of a "bare JID", i.e., <node@domain>, although following:
any valid JID form MAY be used. The JID SHOULD be in the
subjectAltName extension, and SHOULD NOT be in the subject 1. An "instant inbox address" as defined in RFC 2778 [5] and MSGFMT
distinguished name. [8]. As explained in XMPP CPIM Mapping [16], an instant inbox
address maps to a "bare JID" (XMPP <node@domain>) once the 'im:'
URI scheme has been removed. The appropriate container for
instant inbox address shall be defined in MSGFMT [8].
2. An XMPP address (JID) as defined in XMPP Core [1]; the address
should be of the form <node@domain> (i.e., a "bare JID"),
although any valid JID form MAY be used. The JID SHOULD be
contained in the subjectAltName extension, and SHOULD NOT be in
the subject distinguished name.
The value of the JID contained in the XMPP 'from' attribute SHOULD The value of the JID contained in the XMPP 'from' attribute SHOULD
match the JID provided in the signer's certificate, with the match the JID provided in the signer's certificate, with the
exception that the resource identifier portion of the JID contained exception that the resource identifier portion of the JID contained
in the 'from' attribute MAY be ignored for matching purposes. in the 'from' attribute MAY be ignored for matching purposes.
Receiving agents MUST recognize XMPP addresses (JIDs) in the Receiving agents MUST recognize XMPP addresses (JIDs) in the
subjectAltName field. subjectAltName field.
Receiving agents SHOULD check that sending JID matches a JID provided Receiving agents SHOULD check that sending JID matches a JID provided
skipping to change at page 14, line 25 skipping to change at page 15, line 25
+-------------+ +-------------+ +------------+ +-------------+ +-------------+ +------------+
| | | | | | | | | | | |
| XMPP | | XMPP-CPIM | | Non-XMPP | | XMPP | | XMPP-CPIM | | Non-XMPP |
| Service | <----> | Gateway | <----> | Service | | Service | <----> | Gateway | <----> | Service |
| | | | | | | | | | | |
+-------------+ +-------------+ +------------+ +-------------+ +-------------+ +------------+
The end-to-end encryption method defined herein enables the exchange The end-to-end encryption method defined herein enables the exchange
of encrypted and/or signed instant messages and presence through an of encrypted and/or signed instant messages and presence through an
XMPP-CPIM gateways. In particular: XMPP-CPIM gateway. In particular:
o When a gateway receives a secured XMPP message or presence stanza o When a gateway receives a secured XMPP message or presence stanza
from the XMPP service that is addressed to a user on the non-XMPP from the XMPP service that is addressed to a user on the non-XMPP
service, it MUST remove the XMPP "wrapper" (everything down to and service, it MUST remove the XMPP "wrapper" (everything down to and
including the <e2e> and </e2e> tags) in order to reveal the including the <e2e> and </e2e> tags) in order to reveal the
multipart S/MIME object, then route the object to the non-XMPP multipart S/MIME object, then route the object to the non-XMPP
service (first wrapping it in the protocol used by the non-XMPP service (first wrapping it in the protocol used by the non-XMPP
service if necessary). service if necessary).
o When a gateway receives a secured non-XMPP instant message or o When a gateway receives a secured non-XMPP instant message or
skipping to change at page 18, line 8 skipping to change at page 19, line 8
The end-to-end security method defined here MAY result in exchanging The end-to-end security method defined here MAY result in exchanging
secured instant messages and presence information through a gateway secured instant messages and presence information through a gateway
that implements the CPIM specifications. Such a gateway MUST be that implements the CPIM specifications. Such a gateway MUST be
compliant with the minimum security requirements of the instant compliant with the minimum security requirements of the instant
messaging and presence protocols with which it interfaces. messaging and presence protocols with which it interfaces.
Normative References Normative References
[1] Saint-Andre, P. and J. Miller, "XMPP Core", [1] Saint-Andre, P. and J. Miller, "XMPP Core",
draft-ietf-xmpp-core-15 (work in progress), June 2003. draft-ietf-xmpp-core-17 (work in progress), August 2003.
[2] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging", [2] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging",
draft-ietf-xmpp-im-14 (work in progress), June 2003. draft-ietf-xmpp-im-16 (work in progress), August 2003.
[3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / [3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
Presence Protocol Requirements", RFC 2779, February 2000. Presence Protocol Requirements", RFC 2779, February 2000.
[4] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC [4] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999. 2633, June 1999.
[5] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and [5] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000, <http:// Instant Messaging", RFC 2778, February 2000, <http://
www.ietf.org/rfc/rfc2778.txt>. www.ietf.org/rfc/rfc2778.txt>.
skipping to change at page 19, line 9 skipping to change at page 21, line 5
[13] Mealling, M., "The IANA XML Registry", [13] Mealling, M., "The IANA XML Registry",
draft-mealling-iana-xmlns-registry-05 (work in progress), June draft-mealling-iana-xmlns-registry-05 (work in progress), June
2003. 2003.
[14] Ramsdell, B., "S/MIME Version 3 Certificate Handling", RFC [14] Ramsdell, B., "S/MIME Version 3 Certificate Handling", RFC
2632, June 1999. 2632, June 1999.
[15] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", [15] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms",
RFC 3370, August 2002. RFC 3370, August 2002.
Informative References
[16] Saint-Andre, P. and T. Bamonti, "XMPP CPIM Mapping",
draft-ietf-xmpp-cpim-02 (work in progress), August 2003.
Author's Address Author's Address
Peter Saint-Andre Peter Saint-Andre
Jabber Software Foundation Jabber Software Foundation
EMail: stpeter@jabber.org EMail: stpeter@jabber.org
Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-e2e Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-e2e
The following XML schema is descriptive, not normative. The following XML schema is descriptive, not normative.
skipping to change at page 21, line 10 skipping to change at page 23, line 10
<xs:element name='e2e' type='xs:string'/> <xs:element name='e2e' type='xs:string'/>
</xs:schema> </xs:schema>
Appendix B. Revision History Appendix B. Revision History
Note to RFC Editor: please remove this entire appendix, and the Note to RFC Editor: please remove this entire appendix, and the
corresponding entries in the table of contents, prior to publication. corresponding entries in the table of contents, prior to publication.
B.1 Changes from draft-ietf-xmpp-e2e-03 B.1 Changes from draft-ietf-xmpp-e2e-04
o Added text about instant inbox addresses.
B.2 Changes from draft-ietf-xmpp-e2e-03
o Specified that S/MIME multipart objects are enclosed in a CDATA o Specified that S/MIME multipart objects are enclosed in a CDATA
section. section.
o Changed "text/xml" to "text/plain" for message examples. o Changed "text/xml" to "text/plain" for message examples.
o Specified must-implement technologies, transfer encodings, o Specified must-implement technologies, transfer encodings,
certificate enrollment, certificate retrieval, and certificate certificate enrollment, certificate retrieval, and certificate
names (including subjectAltName for JIDs). names (including subjectAltName for JIDs).
o Specified requirements regarding attachment of signatures and o Specified requirements regarding attachment of signatures and
inclusion of certificates. inclusion of certificates.
o Fixed some small terminological errors. o Fixed some small terminological errors.
B.2 Changes from draft-ietf-xmpp-e2e-02 B.3 Changes from draft-ietf-xmpp-e2e-02
o Completely revised to use formats defined in the CPIM o Completely revised to use formats defined in the CPIM
specifications. specifications.
B.3 Changes from draft-ietf-xmpp-e2e-01 B.4 Changes from draft-ietf-xmpp-e2e-01
o Removed old Section 6 (Signalling Support via Presence) -- the o Removed old Section 6 (Signalling Support via Presence) -- the
ability to sign broadcasted presence made it redundant. ability to sign broadcasted presence made it redundant.
o Made small editorial changes to address RFC Editor requirements. o Made small editorial changes to address RFC Editor requirements.
B.4 Changes from draft-ietf-xmpp-e2e-00 B.5 Changes from draft-ietf-xmpp-e2e-00
o Added support for all stanza types. o Added support for all stanza types.
o Specified that the full stanza is encrypted. o Specified that the full stanza is encrypted.
o Added support for S/MIME in addition to OpenPGP. o Added support for S/MIME in addition to OpenPGP.
o Specified that encrypted presence must be directed to a specific o Specified that encrypted presence must be directed to a specific
recipient. recipient.
skipping to change at page 24, line 7 skipping to change at page 26, line 7
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 30 change blocks. 
50 lines changed or deleted 71 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/