draft-ietf-xmpp-e2e-06.txt   draft-ietf-xmpp-e2e-07.txt 
XMPP Working Group P. Saint-Andre XMPP Working Group P. Saint-Andre
Internet-Draft Jabber Software Foundation Internet-Draft Jabber Software Foundation
Expires: May 20, 2004 November 20, 2003 Expires: June 29, 2004 December 30, 2003
End-to-End Object Encryption in the Extensible Messaging and Presence End-to-End Object Encryption in the Extensible Messaging and Presence
Protocol (XMPP) Protocol (XMPP)
draft-ietf-xmpp-e2e-06 draft-ietf-xmpp-e2e-07
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 31 skipping to change at page 1, line 31
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 May 20, 2004. This Internet-Draft will expire on June 29, 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 memo defines a method for end-to-end object signing and This memo 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).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Securing Messages . . . . . . . . . . . . . . . . . . . . . . 5 3. Securing Messages . . . . . . . . . . . . . . . . . . . . . . 5
4. Securing Presence . . . . . . . . . . . . . . . . . . . . . . 6 4. Securing Presence . . . . . . . . . . . . . . . . . . . . . . 6
5. Securing Arbitrary XMPP Data . . . . . . . . . . . . . . . . . 8 5. Securing Arbitrary XMPP Data . . . . . . . . . . . . . . . . . 8
6. Rules for S/MIME Generation and Handling . . . . . . . . . . . 9 6. Rules for S/MIME Generation and Handling . . . . . . . . . . . 9
7. Secure Communications Through a Gateway . . . . . . . . . . . 11 7. Secure Communications Through a Gateway . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
Normative References . . . . . . . . . . . . . . . . . . . . . 14 Normative References . . . . . . . . . . . . . . . . . . . . . 14
Informative References . . . . . . . . . . . . . . . . . . . . 15 Informative References . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
A. Schema for urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . . 15 A. Schema for urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . . 16
B. Revision History . . . . . . . . . . . . . . . . . . . . . . . 16 B. Revision History . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19
1. Introduction 1. Introduction
This memo define a method for end-to-end signing and encryption in This memo define a method for end-to-end signing and encryption in
the Extensible Messaging and Presence Protocol (XMPP). (For the Extensible Messaging and Presence Protocol (XMPP). (For
information about XMPP, see [XMPP-CORE] and [XMPP-IM].) The method information about XMPP, see [XMPP-CORE] and [XMPP-IM].) The method
defined herein enables a sender to encrypt and/or sign an instant defined herein enables a sender to encrypt and/or sign an instant
message sent to a specific recipient, encrypt and/or sign presence 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 memo information that is broadcasted to a specific user. This memo
skipping to change at page 4, line 48 skipping to change at page 4, line 48
* The protocol MUST provide A means of ensuring that no other * The protocol MUST provide A means of ensuring that no other
PRINCIPAL C can tamper with M, and B means to verify that no PRINCIPAL C can tamper with M, and B means to verify that no
tampering has occurred. (Section 5.4.7) tampering has occurred. (Section 5.4.7)
2. The method defined MUST enable interoperability with non-XMPP 2. The method defined MUST enable interoperability with non-XMPP
messaging systems that support the Common Presence and Instant messaging systems that support the Common Presence and Instant
Messaging (CPIM) specifications defined by the Instant Messaging Messaging (CPIM) specifications defined by the Instant Messaging
and Presence (IMPP) Working Group. Therefore: and Presence (IMPP) Working Group. Therefore:
* Prior to encrypting or signing, the format of an instant * Prior to encrypting or signing, the format of an instant
message must conform to the CPIM Message Format defined in message MUST conform to the CPIM Message Format defined in
[MSGFMT]. [MSGFMT].
* Prior to encrypting or signing, the format of presence * Prior to encrypting or signing, the format of presence
information must conform to the CPP Presence Information Data information MUST conform to the CPP Presence Information Data
Format defined in [PIDF]. Format defined in [PIDF].
3. The method MUST follow the required procedures (including the 3. The method MUST follow the required procedures (including the
specific algorithms) defined in [CPIM] and [CPP]. In particular, specific algorithms) defined in [CPIM] and [CPP]. In particular,
these documents specify: these documents specify:
* Encryption MUST use [SMIME] encryption with [CMS] * Encryption MUST use [SMIME] encryption with [CMS]
EnvelopeData. EnvelopeData.
* Signing MUST use [SMIME] signatures with [CMS] SignedData. * Signing MUST use [SMIME] signatures with [CMS] SignedData.
4. In order to enable interoperable implementations, sending and 4. In order to enable interoperable implementations, sending and
receiving applications MUST implement the algorithms defined receiving applications MUST implement the algorithms defined
under Section 6.7. under Section 6.9.
3. Securing Messages 3. Securing Messages
In order to encrypt a message, a sending entity MUST use the In order to encrypt a message, a sending entity MUST use the
following procedure: following procedure:
1. Generate a "Message/CPIM" object as defined in [MSGFMT]. 1. Generate a "Message/CPIM" object as defined in [MSGFMT].
2. Encrypt and/or sign both the headers and content of the "Message/ 2. Encrypt and/or sign both the headers and content of the "Message/
CPIM" object as specified in Requirement 3 of Section 2 above. CPIM" object as specified in Requirement 3 of Section 2 above.
3. Provide the resulting multipart S/MIME object (see [MULTI]) 3. Provide the resulting multipart [SMIME] object (see [MULTI])
within a CDATA section of an <e2e/> child of a <message/> stanza, within a CDATA section of an <e2e/> child of a <message/> stanza,
where the <e2e/> element is qualified by the where the <e2e/> element is qualified by the
'urn:ietf:params:xml:ns:xmpp-e2e' namespace. 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
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@example.com> From: Juliet Capulet <im:juliet@example.com>
To: Romeo Montague <im:romeo@example.net> To: Romeo Montague <im:romeo@example.net>
DateTime: 2003-05-14T11:45:36Z DateTime: 2003-12-09T11:45:36.66Z
Subject: Imploring Subject: Imploring
Content-type: text/plain; charset=utf-8 Content-type: text/plain; charset=utf-8
Content-ID: <1234567890@example.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):
skipping to change at page 6, line 17 skipping to change at page 6, line 17
<![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@example.com> From: Juliet Capulet <im:juliet@example.com>
To: Romeo Montague <im:romeo@example.net> To: Romeo Montague <im:romeo@example.net>
DateTime: 2003-05-14T23:45:36Z DateTime: 2003-12-09T23:45:36.66Z
Subject: Imploring Subject: Imploring
Content-type: text/plain; charset=utf-8 Content-type: text/plain; charset=utf-8
Content-ID: <1234567890@example.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
Content-Disposition: attachment;handling=required;filename=smime.p7s
[signed body part] [signed body part]
--next-- --next--
]]> ]]>
</e2e> </e2e>
</message> </message>
4. Securing Presence 4. Securing Presence
In order to encrypt presence information, a sending entity MUST use In order to encrypt presence information, a sending entity MUST use
the following procedure: the following procedure:
1. Generate an "application/pidf+xml" object as defined in [PIDF]. 1. Generate an "application/pidf+xml" object as defined in [PIDF].
2. Encrypt and/or sign the "application/pidf+xml" object as 2. Encrypt and/or sign the "application/pidf+xml" object as
specified in Requirement 3 of Section 2 above. specified in Requirement 3 of Section 2 above.
3. Provide the resulting S/MIME object within a CDATA section of an 3. Provide the resulting [SMIME] object within a CDATA section of an
<e2e/> child of a <presence/> stanza, where the <e2e/> element is <e2e/> child of a <presence/> stanza, where the <e2e/> element is
qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace. qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
The <presence/> stanza MUST include a 'to' attribute, i.e., it The <presence/> stanza MUST include a 'to' attribute, i.e., it
must be an instance of directed presence as defined in [XMPP-IM]. must be an instance of directed presence as defined in [XMPP-IM].
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@example.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-12-09T23:53:11.31</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@example.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;
skipping to change at page 7, line 43 skipping to change at page 7, line 45
<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@example.com"> entity="pres:juliet@example.com">
<tuple id="hr0zny"> <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-12-09T23:53:11.31Z</timestamp>
</tuple> </tuple>
</presence> </presence>
--next --next
Content-Type: application/pkcs7-signature Content-Type: application/pkcs7-signature
Content-Disposition: attachment;handling=required;filename=smime.p7s
[signed body part] [signed body part]
--next-- --next--
]]> ]]>
</e2e> </e2e>
</presence> </presence>
5. Securing Arbitrary XMPP Data 5. Securing Arbitrary XMPP Data
The foregoing sections of this memo describe how to secure "least The foregoing sections of this memo describe how to secure "least
common denominator" messaging and presence data of the kind that can common denominator" messaging and presence data of the kind that can
be directly translated into the MSGFMT or PIDF formats. However, be directly translated into the MSGFMT or PIDF formats. However,
skipping to change at page 9, line 32 skipping to change at page 9, line 34
<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>
6. Rules for S/MIME Generation and Handling 6. Rules for S/MIME Generation and Handling
6.1 Certificate Enrollment 6.1 Certificate Enrollment
S/MIME v3 does not specify how to obtain a certificate from a [SMIME] does not specify how to obtain a certificate from a
certificate authority, but instead mandates that every sending agent certificate authority, but instead mandates that every sending agent
must already have a certificate. The PKIX Working Group has, at the must already have a certificate. The PKIX Working Group has, at the
time of this writing, produced two separate standards for certificate time of this writing, produced two separate standards for certificate
enrollment: [CMP] and [CMC]. Which method to use for certificate enrollment: [CMP] and [CMC]. Which method to use for certificate
enrollment is outside the scope of this memo. enrollment is outside the scope of this memo.
6.2 Certificate Retrieval 6.2 Certificate Retrieval
A receiving agent MUST provide some certificate retrieval mechanism A receiving agent MUST provide some certificate retrieval mechanism
in order to gain access to certificates for recipients of digital in order to gain access to certificates for recipients of digital
skipping to change at page 10, line 10 skipping to change at page 10, line 12
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 memo SHOULD a End-entity certificates used by XMPP entities in the context of this
valid instant messaging address. The address SHOULD be one of the memo SHOULD contain a valid instant messaging and presence address.
following: The address SHOULD be specified as both an 'im:' URI (for instant
messaging, as defined in [CPIM]) and a 'pres:' URI (for presence, as
1. An XMPP address (also referred to as a Jabber Identifier or JID) defined in [CPP]); each of these URIs SHOULD be specified in a
as defined in [XMPP-CORE]; the address should be of the form separate GeneralName entry of type uniformResourceIdentifier inside
<node@domain> (i.e., a "bare JID"), although any valid JID form the subjectAltName (i.e., two separate entries). Information in the
MAY be used. The JID SHOULD be contained in the subjectAltName subject distinguished name SHOULD be ignored.
extension, and SHOULD NOT be in the subject distinguished name.
2. An "instant inbox address" as defined in [IMP-MODEL] and Each URI MUST be of the form <im:address> or <pres:address>, where
[MSGFMT]. As explained in [XMPP-CPIM], an instant inbox address the "address" portion is an XMPP address (also referred to as a
maps to a "bare JID" (<node@domain>) once the 'im:' URI scheme Jabber Identifier or JID) as defined in [XMPP-CORE], prepended with
has been removed. The appropriate container for instant inbox the 'im:' or 'pres:' URI scheme. The address SHOULD be of the form
address shall be defined in [MSGFMT]. <node@domain> (i.e., a "bare JID"), although any valid JID form MAY
be used.
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 SHOULD be ignored for matching purposes.
Receiving agents MUST recognize XMPP addresses (JIDs) in the
subjectAltName field.
Receiving agents SHOULD check that sending JID matches a JID provided Receiving agents SHOULD check that sending JID matches a JID provided
in the signer's certificate, with the exception that the resource in the signer's certificate, with the exception that the resource
identifier portion of the JID contained in the 'from' attribute MAY identifier portion of the JID contained in the 'from' attribute MAY
be ignored for matching purposes. A receiving agent SHOULD provide be ignored for matching purposes. A receiving agent SHOULD provide
some explicit alternate processing of the message if this comparison some explicit alternate processing of the message if this comparison
fails, which may be to display a message that shows the recipient the fails, which may be to display a message that shows the recipient the
addresses in the certificate or other certificate details. addresses in the certificate or other certificate details.
The subject alternative name extension is used in S/MIME as the The subject alternative name extension is used in S/MIME as the
preferred means to convey the JID that corresponds to the entity for preferred means to convey the instant messaging and presence address
this certificate. Any JIDs present SHOULD be encoded using the that corresponds to the entity for this certificate. Any instant
otherName CHOICE of the subjectAltName type, where the type-id is messaging or presence address present in the certificate SHOULD be
"xmpp" and the value is the bare JID of the entity. encoded using the otherName choice of the subjectAltName type along
with a type-id of "xmpp" (as these terms are profiled in [X509]).
6.4 Transfer Encoding 6.4 Transfer Encoding
According to various S/MIME specifications for message wrapping, Because it is expected that XMPP applications will not interface with
[CMS] objects MAY optionally be wrapped in MIME to dynamically older 7-bit systems, the transfer encoding (as defined in Section
support 7-bit transport. Because it is expected that XMPP will not 3.1.2 of [SMIME]) MUST be "binary".
be used to interface with older 7-bit systems, this outer wrapping is
NOT REQUIRED for XMPP transport, and generally SHOULD NOT be applied
in a homogeneous XMPP environment or in an environment that supports
XMPP-CPIM gateways.
6.5 Attachment of Signatures 6.5 Attachment of Signatures
Sending agents SHOULD attach a signature to each encrypted message or Sending agents SHOULD attach a signature to each encrypted message or
presence stanza, but are NOT REQUIRED to do so. presence stanza. If a signature is attached, a Content-Disposition
header field (as defined in [DISP]) SHOULD be included to specify how
the signature is to be handled by the receiving application.
6.6 Inclusion of Certificates 6.6 Inclusion of Certificates
Sending agents are NOT REQUIRED to include the sender's certificate If the sender and recipient are involved in an active messaging
along with each encrypted message or presence stanza. session over a period of time, the sending agent SHOULD include the
sender's certificate along with at least one encrypted message stanza
every five minutes. Outside the context of an active messaging
session, the sending agent SHOULD include the sender's certificate
along with each encrypted message stanza. A sending agent MAY
include the sender's certificate along with each encrypted presence
stanza. However, a sending agent SHOULD NOT include a certificate
more than once every five minutes.
6.7 Mandatory to Implement Technologies 6.7 Order of Signing and Encrypting
If a stanza is both signed and encrypted, it SHOULD be signed first,
then encrypted.
6.8 Checking of Timestamps
Timestamps are included in "Message/CPIM" and "application/pidf+xml"
objects to help prevent replay attacks. All timestamps MUST conform
to [DATETIME] and be presented as UTC with no offset, including
fractions of a second as appropriate. Absent a local adjustment to
the sending application's perceived time or the underlying clock
time, the sending application MUST ensure that the timestamps it
sends to the receiver increase monotonically (if necessary by
incrementing the seconds fraction in the timestamp if the clock
returns the same time for multiple requests). The following rules
apply to the receiving application:
o it MUST verify that the timestamp received is within five minutes
of the current time
o it SHOULD verify that the timestamp received is greater than any
timestamp received in the last 10 minutes which passed the
previous check
o if any of the foregoing checks fails, the timestamp SHOULD be
presented to the receiving entity (human or via an API) marked as
"old timestamp", "future timestamp", or "decreasing timestamp"
6.9 Mandatory to Implement Technologies
At a minimum, all implementations MUST support the following CMS At a minimum, all implementations MUST support the following CMS
algorithms as defined in [CMS-ALG]: algorithms as defined in [CMS-ALG]:
for digest: DIGEST-MD5 for digest: SHA-1
for signing: RSA for signing: RSA
for content encryption: Triple-DES CBC for content encryption: AES
7. Secure Communications Through a Gateway 7. Secure Communications Through a Gateway
A common method for achieving interoperability between two disparate A common method for achieving interoperability between two disparate
services is through the use of a "gateway" that interprets the services is through the use of a "gateway" that interprets the
protocols of each service and translates them into the protocols of protocols of each service and translates them into the protocols of
the other. The CPIM specifications (specifically [MSGFMT] and [PIDF] the other. The CPIM specifications (specifically [MSGFMT] and [PIDF]
define the common profiles to be used for interoperability between define the common profiles to be used for interoperability between
instant messaging and presence services that comply with [IMP-REQS]. instant messaging and presence services that comply with [IMP-REQS].
In the case of communications between an XMPP service and a non-XMPP In the case of communications between an XMPP service and a non-XMPP
skipping to change at page 14, line 29 skipping to change at page 15, line 17
Algorithms", RFC 3370, August 2002. Algorithms", RFC 3370, August 2002.
[CPIM] Crocker, D. and J. Peterson, "Common Profile for Instant [CPIM] Crocker, D. and J. Peterson, "Common Profile for Instant
Messaging (CPIM)", draft-ietf-impp-im-03 (work in Messaging (CPIM)", draft-ietf-impp-im-03 (work in
progress), May 2003. progress), May 2003.
[CPP] Crocker, D. and J. Peterson, "Common Profile for Presence [CPP] Crocker, D. and J. Peterson, "Common Profile for Presence
(CPP)", draft-ietf-impp-pres-03 (work in progress), May (CPP)", draft-ietf-impp-pres-03 (work in progress), May
2003. 2003.
[DATETIME]
Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002.
[DISP] Troost, R., Dorner, S. and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997.
[IMP-MODEL] [IMP-MODEL]
Day, M., Rosenberg, J. and H. Sugano, "A Model for Day, M., Rosenberg, J. and H. Sugano, "A Model for
Presence and Instant Messaging", RFC 2778, February 2000, Presence and Instant Messaging", RFC 2778, February 2000,
<http://www.ietf.org/rfc/rfc2778.txt>. <http://www.ietf.org/rfc/rfc2778.txt>.
[IMP-REQS] [IMP-REQS]
Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
Presence Protocol Requirements", RFC 2779, February 2000. Presence Protocol Requirements", RFC 2779, February 2000.
[MSGFMT] Atkins, D. and G. Klyne, "Common Presence and Instant [MSGFMT] Atkins, D. and G. Klyne, "Common Presence and Instant
skipping to change at page 15, line 8 skipping to change at page 16, line 5
[PIDF] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W. [PIDF] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W.
and J. Peterson, "Presence Information Data Format", and J. Peterson, "Presence Information Data Format",
draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003.
[SMIME] Ramsdell, B., "S/MIME Version 3 Message Specification", [SMIME] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999. RFC 2633, June 1999.
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate [TERMS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[X509] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[XMPP-CORE] [XMPP-CORE]
Saint-Andre, P., "XMPP Core", draft-ietf-xmpp-core-20 Saint-Andre, P., "XMPP Core", draft-ietf-xmpp-core-21
(work in progress), November 2003. (work in progress), December 2003.
[XMPP-IM] Saint-Andre, P., "XMPP Instant Messaging", [XMPP-IM] Saint-Andre, P., "XMPP Instant Messaging",
draft-ietf-xmpp-im-19 (work in progress), November 2003. draft-ietf-xmpp-im-20 (work in progress), December 2003.
Informative References Informative References
[XML-REG] Mealling, M., "The IANA XML Registry", [XML-REG] Mealling, M., "The IANA XML Registry",
draft-mealling-iana-xmlns-registry-05 (work in progress), draft-mealling-iana-xmlns-registry-05 (work in progress),
June 2003. June 2003.
[XMPP-CPIM] [XMPP-CPIM]
Saint-Andre, P., "Mapping the Extensible Messaging and Saint-Andre, P., "Mapping the Extensible Messaging and
Presence Protocol (XMPP) to Common Presence and Instant Presence Protocol (XMPP) to Common Presence and Instant
skipping to change at page 16, line 10 skipping to change at page 17, 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-05 B.1 Changes from draft-ietf-xmpp-e2e-06
o Specified use of SHA-1 for digest and AES for content encryption.
o Specified order of signing then encrypting.
o Specified format and checking of timestamps.
o Clarified use of subjectAltName field, where the GeneralName
content is a URI of the form im:user@host and pres:user@host.
o Clarified circumstances under which certificates should be
attached.
o Added Content-Disposition header field to examples.
B.2 Changes from draft-ietf-xmpp-e2e-05
o Addressed I-D nits and RFC Editor formatting. o Addressed I-D nits and RFC Editor formatting.
B.2 Changes from draft-ietf-xmpp-e2e-04 B.3 Changes from draft-ietf-xmpp-e2e-04
o Added text about instant inbox addresses. o Added text about instant inbox addresses.
B.3 Changes from draft-ietf-xmpp-e2e-03 B.4 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.4 Changes from draft-ietf-xmpp-e2e-02 B.5 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, S/MIME only, etc.
B.5 Changes from draft-ietf-xmpp-e2e-01 B.6 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.6 Changes from draft-ietf-xmpp-e2e-00 B.7 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.
 End of changes. 39 change blocks. 
67 lines changed or deleted 129 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/