draft-ietf-xmpp-e2e-01.txt   draft-ietf-xmpp-e2e-02.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Jabber Software Foundation Internet-Draft Jabber Software Foundation
Expires: October 6, 2003 J. Hildebrand Expires: October 20, 2003 J. Hildebrand
Jabber, Inc. Jabber, Inc.
April 7, 2003 April 21, 2003
End-to-End Object Encryption in XMPP End-to-End Object Encryption in XMPP
draft-ietf-xmpp-e2e-01 draft-ietf-xmpp-e2e-02
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
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 October 6, 2003. This Internet-Draft will expire on October 20, 2003.
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 describes an end-to-end object signing and encryption This document describes an end-to-end object signing and encryption
method for use in the Extensible Messaging and Presence Protocol method for use in the Extensible Messaging and Presence Protocol
(XMPP). (XMPP).
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1.2 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Intellectual Property Notice . . . . . . . . . . . . . . . . . 3 1.3 Intellectual Property Notice . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Encrypting Stanzas . . . . . . . . . . . . . . . . . . . . . . 5 3. Encrypting Stanzas . . . . . . . . . . . . . . . . . . . . . . 5
3.1 General Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 General Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Encrypting Messages . . . . . . . . . . . . . . . . . . . . . 6 3.2 Encrypting Messages . . . . . . . . . . . . . . . . . . . . . 6
3.3 Encrypting Presence . . . . . . . . . . . . . . . . . . . . . 7 3.3 Encrypting Presence . . . . . . . . . . . . . . . . . . . . . 7
3.4 Encrypting IQs . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4 Encrypting IQs . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Signing Encrypted Content . . . . . . . . . . . . . . . . . . 9 4. Signing Encrypted Content . . . . . . . . . . . . . . . . . . 9
5. Signing Broadcasted Presence . . . . . . . . . . . . . . . . . 10 5. Signing Broadcasted Presence . . . . . . . . . . . . . . . . . 10
6. Signalling Support via Presence . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 Normative References . . . . . . . . . . . . . . . . . . . . . 13
References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Informative References . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
A. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 15 A. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 15
A.1 urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . . . . . . . 15 A.1 urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . . . . . . . 15
A.2 urn:ietf:params:xml:ns:xmpp-e2e#payload . . . . . . . . . . . 16 A.2 urn:ietf:params:xml:ns:xmpp-e2e#payload . . . . . . . . . . . 16
B. Revision History . . . . . . . . . . . . . . . . . . . . . . . 17 B. Revision History . . . . . . . . . . . . . . . . . . . . . . . 17
B.1 Changes from draft-ietf-xmpp-e2e-00 . . . . . . . . . . . . . 17 B.1 Changes from draft-ietf-xmpp-e2e-01 . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 18 B.2 Changes from draft-ietf-xmpp-e2e-00 . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
This document describes an end-to-end signing and encryption method This document describes an end-to-end signing and encryption method
for use in the Extensible Messaging and Presence Protocol (XMPP) as for use in the Extensible Messaging and Presence Protocol (XMPP) as
defined by XMPP Core [1] and XMPP IM [2]. Object signing and defined by XMPP Core [1] and XMPP IM [2]. Object signing and
encryption enables a sender to encrypt an XML stanza sent to a encryption enable a sender to encrypt an XML stanza sent to a
specific recipient, sign such a stanza, sign broadcasted presence, specific recipient, sign such a stanza, sign broadcasted presence,
and signal support for the method defined herein. This document and signal support for the method defined herein. This document
thereby helps the XMPP specifications meet the requirements defined thereby helps the XMPP specifications meet the requirements defined
in RFC 2779 [3]. in RFC 2779 [6].
1.1 Terminology 1.1 Terminology
This document inherits the terminology defined in XMPP Core [1]. This document inherits the terminology defined in XMPP Core [1].
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [4]. 2119 [3].
1.2 Discussion Venue 1.2 Discussion Venue
The authors welcome discussion and comments related to the topics The authors welcome discussion and comments related to the topics
presented in this document. The preferred forum is the presented in this document. The preferred forum is the
<xmppwg@jabber.org> mailing list, for which archives and subscription <xmppwg@jabber.org> mailing list, for which archives and subscription
information are available at <http://www.jabber.org/cgi-bin/mailman/ information are available at <http://www.jabber.org/cgi-bin/mailman/
listinfo/xmppwg/>. listinfo/xmppwg/>.
1.3 Intellectual Property Notice 1.3 Intellectual Property Notice
skipping to change at page 4, line 15 skipping to change at page 4, line 15
2. Requirements 2. Requirements
For the purposes of this document, we stipulate the following For the purposes of this document, we stipulate the following
requirements: requirements:
1. Encryption must work with any stanza type (message, presence, or 1. Encryption must work with any stanza type (message, presence, or
IQ). IQ).
2. The full XML stanza must be encrypted. 2. The full XML stanza must be encrypted.
3. Encryption must be possible using either OpenPGP [5] or S/MIME 3. Encryption must be possible using either OpenPGP [4] or S/MIME
[6]. [5].
4. It must be possible to sign encrypted content. 4. It must be possible to sign encrypted content.
5. It must be possible to sign broadcasted presence. 5. It must be possible to sign broadcasted presence.
6. Any namespaces used must conform to The IETF XML Registry [7]. 6. Any namespaces used must conform to The IETF XML Registry [7].
3. Encrypting Stanzas 3. Encrypting Stanzas
3.1 General Syntax 3.1 General Syntax
Any stanza may be encrypted. The full stanza must be inserted as a Any stanza MAY be encrypted. The full stanza MUST be inserted as a
direct child of a <payload/> element scoped by the direct child of a <payload/> element scoped by the
'urn:ietf:params:xml:ns:xmpp-e2e#payload' namespace. The stanza data 'urn:ietf:params:xml:ns:xmpp-e2e#payload' namespace. The stanza data
MUST be preceded by another direct child of the <payload/> element, MUST be preceded by another direct child of the <payload/> element,
namely an <id/> element. The CDATA of the <id/> element MUST be namely an <id/> element. The CDATA of the <id/> element MUST be
constructed according to the following algorithm: constructed according to the following algorithm:
1. concatenate the sender's full JID (user@host/resource) with the 1. concatenate the sender's full JID (user@host/resource) with the
recipient's full JID recipient's full JID
2. concatenate the resulting string with a full ISO-8601 UTC 2. concatenate the resulting string with a full ISO-8601 UTC
skipping to change at page 5, line 39 skipping to change at page 5, line 39
following form: following form:
<payload xmlns='urn:ietf:params:xml:ns:xmpp-e2e#payload'> <payload xmlns='urn:ietf:params:xml:ns:xmpp-e2e#payload'>
<id>someID</id> <id>someID</id>
[stanza] [stanza]
</payload> </payload>
The full <payload/> element (including all XML tag names and angle The full <payload/> element (including all XML tag names and angle
brackets) MUST then be encrypted using either OpenPGP or S/MIME. The brackets) MUST then be encrypted using either OpenPGP or S/MIME. The
output MUST be armored US-ASCII with any headers removed. The output MUST be armored US-ASCII with any headers removed. The
resulting cipher text MUST then be provided as the CDATA of a resulting cipher text MUST then be provided as the CDATA of the
<stanza/> child of an <x/> element scoped by the <stanza/> child of an <x/> element scoped by the
'urn:ietf:params:xml:ns:xmpp-e2e' namespace, with the value of the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace, with the value of the
'type' attribute set to either "openpgp" or "smime" depending on 'type' attribute set to either "openpgp" or "smime" depending on
which method was used. which method was used.
The format of the stanza that results from the foregoing procedure is The format of the stanza that results from the foregoing procedure is
as follows (no 'from' address is included in the stanza to be as follows (no 'from' address is included in the stanza to be
encrypted, since that is stamped by the sender's server): encrypted, since that is stamped by the sender's server):
<[stanza-name] <[stanza-name]
skipping to change at page 9, line 14 skipping to change at page 9, line 14
4. Signing Encrypted Content 4. Signing Encrypted Content
OpenPGP and S/MIME both allow an entity to either encrypt then sign, OpenPGP and S/MIME both allow an entity to either encrypt then sign,
or sign then encrypt. When signing first, the signatories are or sign then encrypt. When signing first, the signatories are
obscured by the encryption; when encrypting first, the signatories obscured by the encryption; when encrypting first, the signatories
are exposed but the signatures can be verified without decrypting. are exposed but the signatures can be verified without decrypting.
Because in XMPP the signatories are exposed by the very act of Because in XMPP the signatories are exposed by the very act of
exchanging a stanza (since the 'from' and 'to' addresses must be exchanging a stanza (since the 'from' and 'to' addresses must be
exposed for routing purposes), there would be no use in signing first exposed for routing purposes), there would be no use in signing first
and encrypting second. Therefore, if signing is desired, it SHOULD be and encrypting second. Therefore, if signing is desired, it SHOULD
performed after encrypting. be performed after encrypting.
5. Signing Broadcasted Presence 5. Signing Broadcasted Presence
An entity may want to sign presence information for broadcasting to An entity may want to sign presence information for broadcasting to
all subscribers (i.e., the presence stanza is not directed to a all subscribers (i.e., the presence stanza is not directed to a
particular recipient, but is sent to all other entites that that have particular recipient, but is sent to all other entites that that have
subscribed to the sender's presence). Because encrypted presence MUST subscribed to the sender's presence). Because encrypted presence
be directed to a particular recipient, signed presence for MUST be directed to a particular recipient, signed presence for
broadcasting MUST NOT be encrypted, only signed. However, there is broadcasting MUST NOT be encrypted, only signed. However, there is
little to no value in signing the entire stanza; therefore it is little to no value in signing the entire stanza; therefore it is
enough to sign only the user-provided CDATA of the <status/> element enough to sign only the user-provided CDATA of the <status/> element
(note that this requires a signed presence broadcast to include some (note that this requires a signed presence broadcast to include some
CDATA in the <status/> element). The process is as follows: CDATA in the <status/> element). The process is as follows:
1. User provides CDATA for the <status/> element. 1. User provides CDATA for the <status/> element.
2. Client application signs CDATA using OpenPGP or S/MIME. 2. Client application signs CDATA using OpenPGP or S/MIME.
3. Client application inserts signed ASCII output as CDATA of an <x/ 3. Client application inserts signed ASCII output as CDATA of the
> element scoped by the 'urn:ietf:params:xml:ns:xmpp-e2e' <signed/> child of an <x/> element that is scoped by the
namespace (including a 'type' attribute whose value is either 'urn:ietf:params:xml:ns:xmpp-e2e' namespace and that includes a
"openpgp" or "smime"). 'type' attribute whose value is either "openpgp" or "smime".
4. Client application adds <x/> element to remainder of presence 4. Client application adds <x/> element to remainder of presence
stanza and sends to server with no 'to' attribute. stanza and sends to server with no 'to' attribute.
5. Server stamps 'from' address, enabling recipient to check bare
JID (user@domain) of 'from' address against User-IDs defined in
the sender's key or certificate.
Example: Sender generates signed presence: Example: Sender generates signed presence:
<presence> <presence>
<show>away</show> <show>away</show>
<status>retired to the chamber</status> <status>retired to the chamber</status>
<x type='openpgp' xmlns='urn:ietf:params:xml:ns:xmpp-e2e'> <x type='openpgp' xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
<signed> <signed>
iD8DBQE+kgpNEWF4x4jKHUYRAuthAJ9L1BjML9GIpagVGbEEJr0C7F3k9ACeJRL4 iD8DBQE+kgpNEWF4x4jKHUYRAuthAJ9L1BjML9GIpagVGbEEJr0C7F3k9ACeJRL4
obxiSG72h3ggH0Xr3BmGyjE= obxiSG72h3ggH0Xr3BmGyjE=
=T4rw =T4rw
</signed> </signed>
</x> </x>
</presence> </presence>
6. Signalling Support via Presence 6. IANA Considerations
In order to signal support for this protocol, an entity MAY broadcast
its credentials (KeyID and/or certificate subject) in all outgoing
presence stanzas. If included, this information MUST be contained in
a <support/> child of an <x/> element scoped by the
'urn:ietf:params:xml:ns:xmpp-e2e' namespace. An entity MAY include
more than one instance (e.g., one for OpenPGP and one for S/MIME).
KeyIDs SHOULD be 64-bit rather than 32-bit.
<presence>
<x type='openpgp' xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
<support>[KeyID]</support>
</x>
<x type='smime' xmlns='urn:ietf:params:xml:ns:xmpp-e2e'>
<support>[certificate subject]</support>
</x>
</presence>
7. IANA Considerations
A URN sub-namespace for XMPP encrypted content is defined as follows. A URN sub-namespace for signed and encrypted content in the
Extensible Messaging and Presence Protocol (XMPP) is defined as
follows.
URI: urn:ietf:params:xml:ns:xmpp-e2e URI: urn:ietf:params:xml:ns:xmpp-e2e
Specification: [RFCXXXX] Specification: [RFCXXXX]
Description: This is the XML namespace name for XMPP encrypted Description: This is the XML namespace name for signed and encrypted
content as defined by [RFCXXXX]. content in the Extensible Messaging and Presence Protocol as
defined by [RFCXXXX].
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org> Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
8. Security Considerations 7. Security Considerations
Replay attacks are made more difficult using this method because of Replay attacks are made more difficult using this method because of
the inclusion of a unique ID in the encrypted object. Key exchange the inclusion of a unique ID in the encrypted object. Key exchange
may rely on the web of trust model used on the OpenPGP keys network. may rely on the web of trust model used on the OpenPGP keys network.
There is no method to check a fingerprint or ownership of a key other There is no method to check a fingerprint or ownership of a key other
than checking the user IDs on a key. A key or certificate SHOULD have than checking the user IDs on a key. A key or certificate SHOULD
associated with it the Jabber ID of the sender. have associated with it the Jabber ID of the sender. One of the
User-IDs defined in a sender's key or certificate MUST be the bare
References JID (user@domain) of the 'from' address stamped by the sender's
server on the XML stanzas that the sender generates; a client that
receives signed or encypted stanzas from the sender MUST check the
sender's bare JID against the User-IDs defined in the sender's key or
certificate, and SHOULD discard the stanza or warn the recipient
before presenting the stanza to the recipient if the bare JID does
not match.
[1] Saint-Andre, P. and J. Miller, "XMPP Core Normative References
(draft-ietf-xmpp-core-08, work in progress)", April 2003.
[2] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging [1] Saint-Andre, P. and J. Miller, "XMPP Core (draft-ietf-xmpp-core-
(draft-ietf-xmpp-im-08, work in progress)", April 2003. 10, work in progress)", April 2003.
[3] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for [2] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging (draft-
Presence and Instant Messaging", RFC 2779, February 2000, ietf-xmpp-im-09, work in progress)", April 2003.
<http://www.ietf.org/rfc/rfc2779.txt>.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[5] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP [4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
Message Format", RFC 2440, November 1998. Message Format", RFC 2440, November 1998.
[6] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC [5] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
2633, June 1999. 2633, June 1999.
[7] Mealling, M., "The IANA XML Registry", Informative References
draft-mealling-iana-xmlns-registry-04 (work in progress), June
2002. [6] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for
Presence and Instant Messaging", RFC 2779, February 2000,
<http://www.ietf.org/rfc/rfc2779.txt>.
[7] Mealling, M., "The IANA XML Registry", draft-mealling-iana-
xmlns-registry-04 (work in progress), June 2002.
Authors' Addresses Authors' Addresses
Peter Saint-Andre Peter Saint-Andre
Jabber Software Foundation Jabber Software Foundation
EMail: stpeter@jabber.org EMail: stpeter@jabber.org
URI: http://www.jabber.org/people/stpeter.php URI: http://www.jabber.org/people/stpeter.php
Joe Hildebrand Joe Hildebrand
skipping to change at page 15, line 24 skipping to change at page 15, line 24
xmlns:xs='http://www.w3.org/2001/XMLSchema' xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-e2e' targetNamespace='urn:ietf:params:xml:ns:xmpp-e2e'
xmlns='urn:ietf:params:xml:ns:xmpp-e2e' xmlns='urn:ietf:params:xml:ns:xmpp-e2e'
elementFormDefault='qualified'> elementFormDefault='qualified'>
<xs:element name='x'> <xs:element name='x'>
<xs:complexType> <xs:complexType>
<xs:choice> <xs:choice>
<xs:element ref='signed' minOccurs='0' maxOccurs='1'/> <xs:element ref='signed' minOccurs='0' maxOccurs='1'/>
<xs:element ref='stanza' minOccurs='0' maxOccurs='1'/> <xs:element ref='stanza' minOccurs='0' maxOccurs='1'/>
<xs:element ref='support' minOccurs='0' maxOccurs='1'/>
</xs:choice> </xs:choice>
<xs:attribute name='type' use='required'/> <xs:attribute name='type' use='required'/>
<xs:simpleType> <xs:simpleType>
<xs:restriction base='xs:NCName'> <xs:restriction base='xs:NCName'>
<xs:enumeration value='openpgp'/> <xs:enumeration value='openpgp'/>
<xs:enumeration value='smime'/> <xs:enumeration value='smime'/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name='signed' type='xs:string'/> <xs:element name='signed' type='xs:string'/>
<xs:element name='stanza' type='xs:string'/> <xs:element name='stanza' type='xs:string'/>
<xs:element name='support' type='xs:string'/>
</xs:schema> </xs:schema>
A.2 urn:ietf:params:xml:ns:xmpp-e2e#payload A.2 urn:ietf:params:xml:ns:xmpp-e2e#payload
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<xs:schema <xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema' xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-e2e#payload' targetNamespace='urn:ietf:params:xml:ns:xmpp-e2e#payload'
skipping to change at page 17, line 7 skipping to change at page 17, line 7
<xs:any namespace='jabber:client' maxOccurs='1'/> <xs:any namespace='jabber:client' maxOccurs='1'/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name='id' type='xs:string'/> <xs:element name='id' 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-00 B.1 Changes from draft-ietf-xmpp-e2e-01
o Removed old Section 6 (Signalling Support via Presence) -- the
ability to sign broadcasted presence made it redundant.
o Made small editorial changes to address RFC Editor requirements.
B.2 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.
o Specified order of encrypting and signing. o Specified order of encrypting and signing.
o Added support for signing broadcasted presence. o Added support for signing broadcasted presence.
o Added IANA considerations. o Added IANA considerations.
o Changed namespace to 'urn:ietf:params:xml:ns:xmpp-e2e'. o Changed namespace to 'urn:ietf:params:xml:ns:xmpp-e2e'.
o Added XML schema. o Added XML schema.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
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 assigns.
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 Acknowledgement
 End of changes. 35 change blocks. 
95 lines changed or deleted 77 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/