draft-ietf-xmpp-e2e-09.txt   rfc3923.txt 
XMPP Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Jabber Software Foundation Request for Comments: 3923 Jabber Software Foundation
Expires: January 10, 2005 July 12, 2004 Category: Standards Track October 2004
End-to-End Signing and Object Encryption in the Extensible Messaging End-to-End Signing and Object Encryption for the
and Presence Protocol (XMPP) Extensible Messaging and Presence Protocol (XMPP)
draft-ietf-xmpp-e2e-09
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document specifies an Internet standards track protocol for the
patent or other IPR claims of which I am aware have been disclosed, Internet community, and requests discussion and suggestions for
and any of which I become aware will be disclosed, in accordance with improvements. Please refer to the current edition of the "Internet
RFC 3668. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
Abstract Abstract
This memo defines a method for end-to-end signing and object This memo defines methods of end-to-end signing and object encryption
encryption in the Extensible Messaging and Presence Protocol (XMPP). for the Extensible Messaging and Presence Protocol (XMPP).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Securing Messages . . . . . . . . . . . . . . . . . . . . . 5 3. Securing Messages . . . . . . . . . . . . . . . . . . . . . 4
4. Securing Presence . . . . . . . . . . . . . . . . . . . . . 9 4. Securing Presence . . . . . . . . . . . . . . . . . . . . . 9
5. Securing Arbitrary XMPP Data . . . . . . . . . . . . . . . . 13 5. Securing Arbitrary XMPP Data . . . . . . . . . . . . . . . . 13
6. Rules for S/MIME Generation and Handling . . . . . . . . . . 15 6. Rules for S/MIME Generation and Handling . . . . . . . . . . 15
7. Recipient Error Handling . . . . . . . . . . . . . . . . . . 18 7. Recipient Error Handling . . . . . . . . . . . . . . . . . . 18
8. Secure Communications Through a Gateway . . . . . . . . . . 20 8. Secure Communications Through a Gateway . . . . . . . . . . 20
9. urn:ietf:params:xml:xmpp-e2e Namespace . . . . . . . . . . . 20 9. urn:ietf:params:xml:xmpp-e2e Namespace . . . . . . . . . . . 21
10. application/xmpp+xml Media Type . . . . . . . . . . . . . . 21 10. application/xmpp+xml Media Type . . . . . . . . . . . . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . 22
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.1 Normative References . . . . . . . . . . . . . . . . . . . 22 A. Schema for urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . 26
13.2 Informative References . . . . . . . . . . . . . . . . . . 24 Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . 25 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 27
A. Schema for urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . 25
B. Revision History . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . 28
1. Introduction 1. Introduction
This memo define a method for end-to-end signing and object This memo defines methods of end-to-end signing and object encryption
encryption in the Extensible Messaging and Presence Protocol (XMPP). for the Extensible Messaging and Presence Protocol (XMPP). (For
(For information about XMPP, see [XMPP-CORE] and [XMPP-IM].) The information about XMPP, see [XMPP-CORE] and [XMPP-IM].) The method
method specified herein enables a sender to sign and/or encrypt an specified herein enables a sender to sign and/or encrypt an instant
instant message sent to a specific recipient, sign and/or encrypt message sent to a specific recipient, sign and/or encrypt presence
presence information that is directed to a specific user, and sign information that is directed to a specific user, and sign and/or
and/or encrypt any arbitrary XMPP stanza directed to a specific user. encrypt any arbitrary XMPP stanza directed to a specific user. This
This memo thereby helps the XMPP specifications meet the requirements memo thereby helps the XMPP specifications meet the requirements
specified in [IMP-REQS]. specified in [IMP-REQS].
1.1 Terminology 1.1. Terminology
This document inherits terminology defined in [CMS], [IMP-MODEL], This document inherits terminology defined in [CMS], [IMP-MODEL],
[SMIME], and [XMPP-CORE]. [SMIME], and [XMPP-CORE].
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 "OPTIONAL" in this document are to be interpreted as described in BCP
[TERMS]. 14, RFC 2119 [TERMS].
2. Requirements 2. Requirements
For the purposes of this memo, we stipulate the following For the purposes of this memo, we stipulate the following
requirements: requirements:
1. The method defined MUST address signing and encryption 1. The method defined MUST address signing and encryption
requirements for minimal instant messaging and presence, as those requirements for minimal instant messaging and presence, as those
are defined in [IMP-REQS]. In particular, the method MUST are defined in [IMP-REQS]. In particular, the method MUST
address the following requirements, which are copied here address the following requirements, which are copied here
skipping to change at page 4, line 47 skipping to change at page 4, line 16
for this memo: for this memo:
o Discovery of support for this protocol. An entity could discover o Discovery of support for this protocol. An entity could discover
whether another entity supports this protocol by (1) attempting to whether another entity supports this protocol by (1) attempting to
send signed or encrypted stanzas and receiving an error stanza send signed or encrypted stanzas and receiving an error stanza
("technical" discovery) or a textual message in reply ("social" ("technical" discovery) or a textual message in reply ("social"
discovery) if the protocol is not supported, or (2) using a discovery) if the protocol is not supported, or (2) using a
dedicated service discovery protocol, such as [DISCO] or [CAPS]. dedicated service discovery protocol, such as [DISCO] or [CAPS].
However, the definition of a service discovery protocol is out of However, the definition of a service discovery protocol is out of
scope for this memo. scope for this memo.
o Signing or encryption of XMPP groupchat messages, which are o Signing or encryption of XMPP groupchat messages, which are
mentioned in [XMPP-IM] but not defined therein since they are not mentioned in [XMPP-IM] but not defined therein since they are not
required by [IMP-REQS]; such messages are best specified in [MUC]. required by [IMP-REQS]; such messages are best specified in [MUC].
o Signing or encryption of broadcasted presence as described in o Signing or encryption of broadcasted presence as described in
[XMPP-IM] (the methods defined herein apply to directed presence [XMPP-IM] (the methods defined herein apply to directed presence
only). only).
o Signing or encryption of communications that occur within the o Signing or encryption of communications that occur within the
context of applications other than instant messaging and presence context of applications other than instant messaging and presence
as those are described in [IMP-MODEL] and [IMP-REQS]. as those are described in [IMP-MODEL] and [IMP-REQS].
3. Securing Messages 3. Securing Messages
3.1 Process for Securing Messages 3.1. Process for Securing Messages
In order to sign and/or encrypt a message, a sending agent MUST use In order to sign and/or encrypt a message, a sending agent MUST use
the following procedure: the following procedure:
1. Generate a "Message/CPIM" object as defined in [MSGFMT]. 1. Generate a "Message/CPIM" object as defined in [MSGFMT].
2. Sign and/or encrypt both the headers and content of the "Message/
CPIM" object as specified in Requirement 3 of Section 2 above. 2. Sign and/or encrypt both the headers and content of the
"Message/CPIM" object as specified in Requirement 3 of Section 2
above.
3. Provide the resulting signed and/or encrypted object within an 3. Provide the resulting signed and/or encrypted object within an
XML CDATA section (see Section 2.7 of [XML]) contained in an XML CDATA section (see Section 2.7 of [XML]) contained in an
<e2e/> child of a <message/> stanza, where the <e2e/> element is <e2e/> child of a <message/> stanza, where the <e2e/> element is
qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace as qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace as
specified more fully in Section 9 below. specified more fully in Section 9 below.
3.2 Example of a Signed Message 3.2. Example of a Signed Message
The following example illustrates the defined steps for signing a The following example illustrates the defined steps for signing a
message. message.
First, the sending agent generates a "Message/CPIM" object in First, the sending agent generates a "Message/CPIM" object in
accordance with the rules and formats specified in [MSGFMT]. accordance with the rules and formats specified in [MSGFMT].
Example 1: Sender generates "Message/CPIM" object: Example 1: Sender generates "Message/CPIM" object:
| Content-type: Message/CPIM | Content-type: Message/CPIM
skipping to change at page 6, line 32 skipping to change at page 6, line 32
| 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;\ | Content-Disposition: attachment;handling=required;\
| filename=smime.p7s | filename=smime.p7s
| |
| [signed body part] | [signed body part]
| |
| --next-- | --next--
The sending agent now wraps the "mulipart/signed" object in an XML The sending agent now wraps the "multipart/signed" object in an XML
CDATA section, which is contained in an <e2e/> element that is CDATA section, which is contained in an <e2e/> element that is
included as a child element of the XMPP message stanza and that is included as a child element of the XMPP message stanza and that is
qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace. qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
Example 3: Sender generates XMPP message stanza: Example 3: Sender generates XMPP message stanza:
| <message to='romeo@example.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;
skipping to change at page 7, line 38 skipping to change at page 7, line 38
| Content-Disposition: attachment;handling=required;\ | Content-Disposition: attachment;handling=required;\
| filename=smime.p7s | filename=smime.p7s
| |
| [signed body part] | [signed body part]
| |
| --next-- | --next--
| ]]> | ]]>
| </e2e> | </e2e>
| </message> | </message>
3.3 Example of an Encrypted Message 3.3. Example of an Encrypted Message
The following example illustrates the defined steps for encrypting a The following example illustrates the defined steps for encrypting a
message. message.
First, the sending agent generates a "Message/CPIM" object in First, the sending agent generates a "Message/CPIM" object in
accordance with the rules and formats specified in [MSGFMT]. accordance with the rules and formats specified in [MSGFMT].
Example 4: Sender generates "Message/CPIM" object: Example 4: Sender generates "Message/CPIM" object:
| Content-type: Message/CPIM | Content-type: Message/CPIM
skipping to change at page 9, line 7 skipping to change at page 9, line 7
| Igc1Vzs5/5JecegMieNY24SlNyX9HMFRNFpbI64vLxYEk55A+3IYbZsluCFT31+a | Igc1Vzs5/5JecegMieNY24SlNyX9HMFRNFpbI64vLxYEk55A+3IYbZsluCFT31+a
| +GeAvJkvH64LRV4mPbUhENTQ2wbAwnOTvbLIaQEQrii78xNEh+MK8Bx7TBTvi4yH | +GeAvJkvH64LRV4mPbUhENTQ2wbAwnOTvbLIaQEQrii78xNEh+MK8Bx7TBTvi4yH
| Ddzf9Sim6mtWsXaCAvWSyp0X91d7xRJ4JIgKfPzkxNsWJFCLthQS1p734eDxXVd3 | Ddzf9Sim6mtWsXaCAvWSyp0X91d7xRJ4JIgKfPzkxNsWJFCLthQS1p734eDxXVd3
| i08lEHzyll6htuEr59ZDAw== | i08lEHzyll6htuEr59ZDAw==
| ]]> | ]]>
| </e2e> | </e2e>
| </message> | </message>
4. Securing Presence 4. Securing Presence
4.1 Process for Securing Presence Information 4.1. Process for Securing Presence Information
In order to sign and/or encrypt presence information, a sending agent In order to sign and/or encrypt presence information, a sending agent
MUST use the following procedure: MUST use 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. Sign and/or encrypt the "application/pidf+xml" object as 2. Sign and/or encrypt 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 signed and/or encrypted object within an 3. Provide the resulting signed and/or encrypted object within an
XML CDATA section (see Section 2.7 of [XML]) contained in an XML CDATA section (see Section 2.7 of [XML]) contained in 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
The <presence/> stanza MUST include a 'to' attribute, i.e., it <presence/> stanza MUST include a 'to' attribute, i.e., it must
must be an instance of directed presence as defined in [XMPP-IM]. be an instance of directed presence as defined in [XMPP-IM].
4.2 Example of Signed Presence Information 4.2. Example of Signed Presence Information
The following example illustrates the defined steps for signing The following example illustrates the defined steps for signing
presence information. presence information.
First, the sending agent generates an "application/pidf+xml" object First, the sending agent generates an "application/pidf+xml" object
in accordance with the rules and formats specified in [PIDF]. in accordance with the rules and formats specified in [PIDF].
Example 7: Sender generates "application/pidf+xml" object: Example 7: Sender generates "application/pidf+xml" object:
| <?xml version="1.0" encoding="UTF-8"?> | <?xml version="1.0" encoding="UTF-8"?>
skipping to change at page 9, line 48 skipping to change at page 9, line 48
| <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-12-09T23:53:11.31</timestamp> | <timestamp>2003-12-09T23:53:11.31</timestamp>
| </tuple> | </tuple>
| </presence> | </presence>
Once the sending agent has generated the "application/pidf+xml" Once the sending agent has generated the "application/pidf+xml"
object, the sending agent may sign it. The result is a multipart object, the sending agent may sign it. The result is a multipart
[SMIME] object (see [MULTI]) that has a Content-Type of "multipart/ [SMIME] object (see [MULTI]) that has a Content-Type of
signed" and includes two parts: one whose Content-Type is "multipart/signed" and includes two parts: one whose Content-Type is
"application/pidf+xml" and another whose Content-Type is "application/pidf+xml" and another whose Content-Type is
"application/pkcs7-signature". "application/pkcs7-signature".
Example 8: Sender generates multipart/signed object: Example 8: Sender generates multipart/signed object:
| 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
skipping to change at page 10, line 37 skipping to change at page 10, line 37
| </presence> | </presence>
| --next | --next
| Content-Type: application/pkcs7-signature | Content-Type: application/pkcs7-signature
| Content-Disposition: attachment;handling=required;\ | Content-Disposition: attachment;handling=required;\
| filename=smime.p7s | filename=smime.p7s
| |
| [signed body part] | [signed body part]
| |
| --next-- | --next--
The sending agent now wraps the "mulipart/signed" object in an XML The sending agent now wraps the "multipart/signed" object in an XML
CDATA section, which is contained in an <e2e/> element that is CDATA section, which is contained in an <e2e/> element that is
included as a child element of the XMPP message stanza and that is included as a child element of the XMPP message stanza and that is
qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace. qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
Example 9: Sender generates XMPP presence stanza: Example 9: Sender generates XMPP presence stanza:
| <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 11, line 43 skipping to change at page 11, line 43
| Content-Disposition: attachment;handling=required;\ | Content-Disposition: attachment;handling=required;\
| filename=smime.p7s | filename=smime.p7s
| |
| [signed body part] | [signed body part]
| |
| --next-- | --next--
| ]]> | ]]>
| </e2e> | </e2e>
| </presence> | </presence>
4.3 Example of Encrypted Presence Information 4.3. Example of Encrypted Presence Information
The following example illustrates the defined steps for encrypting The following example illustrates the defined steps for encrypting
presence information. presence information.
First, the sending agent generates an "application/pidf+xml" object First, the sending agent generates an "application/pidf+xml" object
in accordance with the rules and formats specified in [PIDF]. in accordance with the rules and formats specified in [PIDF].
Example 10: Sender generates "application/pidf+xml" object: Example 10: Sender generates "application/pidf+xml" object:
| <?xml version="1.0" encoding="UTF-8"?> | <?xml version="1.0" encoding="UTF-8"?>
skipping to change at page 13, line 31 skipping to change at page 13, line 31
| </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,
XMPP possesses a third base-level stanza type (<iq/>) in addition to XMPP possesses a third base-level stanza type (<iq/>) in addition to
<message/> and <presence/>, as well as the ability to include <message/> and <presence/>, as well as the ability to include
extended XML data within arbitrary child elements of the three core extended XML data within arbitrary child elements of the three core
stanza types. Therefore it would be desirable to secure such data if stanza types. Therefore, it would be desirable to secure such data
possible. if possible.
Because [MSGFMT] specifies the ability to encapsulate any MIME type, Because [MSGFMT] specifies the ability to encapsulate any MIME type,
the approach taken in this memo is to include arbitrary XMPP data in the approach taken in this memo is to include arbitrary XMPP data in
an XML media type named "application/xmpp+xml" as specified more an XML media type named "application/xmpp+xml" as specified more
fully in Section 10 below. fully in Section 10 below.
The following examples illustrate the structure of the "application/ The following examples illustrate the structure of the
xmpp+xml" MIME type. (Note: The 'http://jabber.org/protocol/evil' "application/xmpp+xml" MIME type. (Note: The
namespace used in these examples is associated with an April Fool's 'http://jabber.org/protocol/evil' namespace used in these examples is
protocol written to be the instant messaging equivalent of RFC 3514; associated with an April Fool's protocol written to be the instant
it is included only as an instance of extended information included messaging equivalent of RFC 3514; it is included only as an instance
in an XML stanza and should not be taken seriously as a functional of extended information included in an XML stanza and should not be
XMPP extension.) taken seriously as a functional XMPP extension.)
Example 13: Message stanza with extended data contained in Example 13: 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@example.com/pda' | from='iago@example.com/pda'
| to='emilia@example.com/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
skipping to change at page 14, line 49 skipping to change at page 15, line 4
| to='emilia@example.com/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>
Just as with the "Message/CPIM" and "application/pidf+xml" objects, Just as with the "Message/CPIM" and "application/pidf+xml" objects,
the "application/xmpp+xml" object would be signed and/or encrypted, the "application/xmpp+xml" object would be signed and/or encrypted,
then encapsulated within an XML CDATA section (see Section 2.7 of then encapsulated within an XML CDATA section (see Section 2.7 of
[XML]) contained in an <e2e/> child of a <presence/> stanza, where [XML]) contained in an <e2e/> child of a <presence/> stanza, where
the <e2e/> element is qualified by the the <e2e/> element is qualified by the
'urn:ietf:params:xml:ns:xmpp-e2e' namespace. 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
6. Rules for S/MIME Generation and Handling 6. Rules for S/MIME Generation and Handling
6.1 Certificate Enrollment 6.1. Certificate Enrollment
[SMIME] 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
envelopes. This memo does not address how S/MIME agents handle envelopes. This memo does not address how S/MIME agents handle
certificates, only what they do after a certificate has been certificates, only what they do after a certificate has been
validated or rejected. S/MIME certification issues are covered in validated or rejected. S/MIME certification issues are covered in
[CERT]. [CERT].
However, at a minimum, for initial S/MIME deployment, a user agent However, at a minimum, for initial S/MIME deployment, a user agent
SHOULD automatically generate a message to an intended recipient SHOULD automatically generate a message to an intended recipient
requesting that recipient's certificate in a signed return message. requesting that recipient's certificate in a signed return message.
Receiving and sending agents SHOULD also provide a mechanism to allow Receiving and sending agents SHOULD also provide a mechanism to allow
a user to "store and protect" certificates for correspondents in such a user to "store and protect" certificates for correspondents in such
a way so as to guarantee their later retrieval. a way so as to guarantee their later retrieval.
6.3 Certificate Names 6.3. Certificate Names
End-entity certificates used by XMPP entities in the context of this End-entity certificates used by XMPP entities in the context of this
memo SHOULD contain a valid instant messaging and presence address. memo SHOULD contain a valid instant messaging and presence address.
The address SHOULD be specified as both an 'im:' URI (for instant The address SHOULD be specified as both an 'im:' URI (for instant
messaging, as defined in [CPIM]) and a 'pres:' URI (for presence, as messaging, as defined in [CPIM]) and a 'pres:' URI (for presence, as
defined in [CPP]); each of these URIs SHOULD be specified in a defined in [CPP]); each of these URIs SHOULD be specified in a
separate GeneralName entry of type uniformResourceIdentifier inside separate GeneralName entry of type uniformResourceIdentifier inside
the subjectAltName (i.e., two separate entries). Information in the the subjectAltName (i.e., two separate entries). Information in the
subject distinguished name SHOULD be ignored. subject distinguished name SHOULD be ignored.
skipping to change at page 16, line 27 skipping to change at page 16, line 29
the recipient of the addresses in the certificate or other the recipient of the addresses in the certificate or other
certificate details. 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 instant messaging and presence address preferred means to convey the instant messaging and presence address
that corresponds to the entity for this certificate. Any XMPP that corresponds to the entity for this certificate. Any XMPP
address present in the certificate MUST be encoded using the ASN.1 address present in the certificate MUST be encoded using the ASN.1
Object Identifier "id-on-xmppAddr" as specified in Section 5.1.1 of Object Identifier "id-on-xmppAddr" as specified in Section 5.1.1 of
[XMPP-CORE]. [XMPP-CORE].
6.4 Transfer Encoding 6.4. Transfer Encoding
Because it is expected that XMPP applications will not interface with Because it is expected that XMPP applications will not interface with
older 7-bit systems, the transfer encoding (as defined in Section older 7-bit systems, the transfer encoding (as defined in Section
3.1.2 of [SMIME]) MUST be "binary". 3.1.2 of [SMIME]) MUST be "binary".
6.5 Order of Signing and Encrypting 6.5. Order of Signing and Encrypting
If a stanza is both signed and encrypted, it SHOULD be signed first, If a stanza is both signed and encrypted, it SHOULD be signed first,
then encrypted. then encrypted.
6.6 Inclusion of Certificates 6.6. Inclusion of Certificates
If the sender and recipient are involved in an active messaging If the sender and recipient are involved in an active messaging
session over a period of time, the sending agent SHOULD include the session over a period of time, the sending agent SHOULD include the
sender's certificate along with at least one encrypted message stanza sender's certificate along with at least one encrypted message stanza
every five minutes. Outside the context of an active messaging every five minutes. Outside the context of an active messaging
session, the sending agent SHOULD include the sender's certificate session, the sending agent SHOULD include the sender's certificate
along with each encrypted message stanza. A sending agent MAY along with each encrypted message stanza. A sending agent MAY
include the sender's certificate along with each encrypted presence include the sender's certificate along with each encrypted presence
stanza. However, a sending agent SHOULD NOT include a certificate stanza. However, a sending agent SHOULD NOT include a certificate
more than once every five minutes. more than once every five minutes.
6.7 Attachment and Checking of Signatures 6.7. Attachment and Checking of Signatures
Sending agents SHOULD attach a signature to each encrypted XML Sending agents SHOULD attach a signature to each encrypted XML
stanza. If a signature is attached, a Content-Disposition header stanza. If a signature is attached, a Content-Disposition header
field (as defined in [DISP]) SHOULD be included to specify how the field (as defined in [DISP]) SHOULD be included to specify how the
signature is to be handled by the receiving application. signature is to be handled by the receiving application.
If the receiving agent determines that the signature attached to an If the receiving agent determines that the signature attached to an
encrypted XML stanza is invalid, it SHOULD NOT present the stanza to encrypted XML stanza is invalid, it SHOULD NOT present the stanza to
the intended recipient (human or application), SHOULD provide some the intended recipient (human or application), SHOULD provide some
explicit alternate processing of the stanza (which may be to display explicit alternate processing of the stanza (which may be to display
a message informing the recipient that the attached signature is a message informing the recipient that the attached signature is
invalid), and MAY return a stanza error to the sender as described invalid), and MAY return a stanza error to the sender as described
under Recipient Error Handling (Section 7). under Recipient Error Handling (Section 7).
6.8 Decryption 6.8. Decryption
If the receiving agent is unable to decrypt the encrypted XML stanza, If the receiving agent is unable to decrypt the encrypted XML stanza,
it SHOULD NOT present the stanza to the intended recipient (human or it SHOULD NOT present the stanza to the intended recipient (human or
application), SHOULD provide some explicit alternate processing of application), SHOULD provide some explicit alternate processing of
the stanza (which may be to display a message informing the recipient the stanza (which may be to display a message informing the recipient
that it has received a stanza that cannot be decrypted), and MAY that it has received a stanza that cannot be decrypted), and MAY
return a stanza error to the sender as described under Recipient return a stanza error to the sender as described under Recipient
Error Handling (Section 7). Error Handling (Section 7).
6.9 Inclusion and Checking of Timestamps 6.9. Inclusion and Checking of Timestamps
Timestamps are included in "Message/CPIM" and "application/pidf+xml" Timestamps are included in "Message/CPIM" and "application/pidf+xml"
objects to help prevent replay attacks. All timestamps MUST conform objects to help prevent replay attacks. All timestamps MUST conform
to [DATETIME] and be presented as UTC with no offset, including to [DATETIME] and be presented as UTC with no offset, including
fractions of a second as appropriate. Absent a local adjustment to fractions of a second as appropriate. Absent a local adjustment to
the sending agent's perceived time or the underlying clock time, the the sending agent's perceived time or the underlying clock time, the
sending agent MUST ensure that the timestamps it sends to the sending agent MUST ensure that the timestamps it sends to the
receiver increase monotonically (if necessary by incrementing the receiver increase monotonically (if necessary by incrementing the
seconds fraction in the timestamp if the clock returns the same time seconds fraction in the timestamp if the clock returns the same time
for multiple requests). The following rules apply to the receiving for multiple requests). The following rules apply to the receiving
skipping to change at page 17, line 45 skipping to change at page 17, line 45
fractions of a second as appropriate. Absent a local adjustment to fractions of a second as appropriate. Absent a local adjustment to
the sending agent's perceived time or the underlying clock time, the the sending agent's perceived time or the underlying clock time, the
sending agent MUST ensure that the timestamps it sends to the sending agent MUST ensure that the timestamps it sends to the
receiver increase monotonically (if necessary by incrementing the receiver increase monotonically (if necessary by incrementing the
seconds fraction in the timestamp if the clock returns the same time seconds fraction in the timestamp if the clock returns the same time
for multiple requests). The following rules apply to the receiving for multiple requests). The following rules apply to the receiving
application: application:
o It MUST verify that the timestamp received is within five minutes o It MUST verify that the timestamp received is within five minutes
of the current time. of the current time.
o It SHOULD verify that the timestamp received is greater than any o It SHOULD verify that the timestamp received is greater than any
timestamp received in the last 10 minutes which passed the timestamp received in the last 10 minutes which passed the
previous check. previous check.
o If any of the foregoing checks fails, the timestamp SHOULD be o If any of the foregoing checks fails, the timestamp SHOULD be
presented to the receiving entity (human or application) marked as presented to the receiving entity (human or application) marked as
"old timestamp", "future timestamp", or "decreasing timestamp", "old timestamp", "future timestamp", or "decreasing timestamp",
and the receiving entity MAY return a stanza error to the sender and the receiving entity MAY return a stanza error to the sender
as described under Recipient Error Handling (Section 7). as described under Recipient Error Handling (Section 7).
6.10 Mandatory-to-Implement Cryptographic Algorithms 6.10. Mandatory-to-Implement Cryptographic Algorithms
All implementations MUST support the following algorithms. All implementations MUST support the following algorithms.
Implementations MAY support other algorithms as well. Implementations MAY support other algorithms as well.
For CMS SignedData: For CMS SignedData:
o The SHA-1 message digest as specified in [CMS-ALG] section 2.1. o The SHA-1 message digest as specified in [CMS-ALG] section 2.1.
o The RSA (PKCS #1 v1.5) with SHA-1 signature algorithm, as o The RSA (PKCS #1 v1.5) with SHA-1 signature algorithm, as
specified in [CMS-ALG] section 3.2. specified in [CMS-ALG] section 3.2.
For CMS EnvelopedData: For CMS EnvelopedData:
o The RSA (PKCS #1 v1.5) key transport, as specified in [CMS-ALG] o The RSA (PKCS #1 v1.5) key transport, as specified in [CMS-ALG]
section 4.2.1. section 4.2.1.
o The AES-128 encryption algorithm in CBC mode, as specified in o The AES-128 encryption algorithm in CBC mode, as specified in
[CMS-AES]. [CMS-AES].
7. Recipient Error Handling 7. Recipient Error Handling
When an XMPP entity receives an XML stanza containing data that is When an XMPP entity receives an XML stanza containing data that is
signed and/or encrypted using the protocol described herein, several signed and/or encrypted using the protocol described herein, several
scenarios are possible: scenarios are possible:
Case #1: The receiving application does not understand the protocol. Case #1: The receiving application does not understand the protocol.
skipping to change at page 20, line 49 skipping to change at page 21, line 20
<e2e> and </e2e> tags), and then route the XMPP stanza to the XMPP <e2e> and </e2e> tags), and then route the XMPP stanza to the XMPP
service. service.
The wrapped S/MIME object MUST be immutable and MUST NOT be modified The wrapped S/MIME object MUST be immutable and MUST NOT be modified
by an XMPP-CPIM gateway. by an XMPP-CPIM gateway.
9. urn:ietf:params:xml:xmpp-e2e Namespace 9. urn:ietf:params:xml:xmpp-e2e Namespace
The <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'/> element is a The <e2e xmlns='urn:ietf:params:xml:ns:xmpp-e2e'/> element is a
wrapper for an XML CDATA section (see Section 2.7 of [XML]) that wrapper for an XML CDATA section (see Section 2.7 of [XML]) that
contains a "Message/CPIM", "application/pidf+xml", or "application/ contains a "Message/CPIM", "application/pidf+xml", or
xmpp+xml" object. Thus the 'urn:ietf:params:xml:xmpp-e2e' namespace "application/xmpp+xml" object. Thus the
has no inherent semantics, and the semantics of the encapsulated 'urn:ietf:params:xml:xmpp-e2e' namespace has no inherent semantics,
object are defined by one of the following specifications: and the semantics of the encapsulated object are defined by one of
the following specifications:
o [MSGFMT] for "Message/CPIM" o [MSGFMT] for "Message/CPIM"
o [PIDF] for "application/pidf+xml" o [PIDF] for "application/pidf+xml"
o [XMPP-CORE] for "application/xmpp+xml" o [XMPP-CORE] for "application/xmpp+xml"
Although the "application/xmpp+xml" media type is specified in this Although the "application/xmpp+xml" media type is specified in this
document, the <xmpp/> element is simply a wrapper for a <message/>, document, the <xmpp/> element is simply a wrapper for a <message/>,
<presence/>, or <iq/> stanza, where the semantics of those stanza <presence/>, or <iq/> stanza, where the semantics of those stanza
types are specified in [XMPP-CORE]. types are specified in [XMPP-CORE].
skipping to change at page 21, line 47 skipping to change at page 22, line 22
the "application/xmpp+xml" media type. the "application/xmpp+xml" media type.
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.
12. IANA Considerations 12. IANA Considerations
12.1 XML Namespace Name for e2e Data in XMPP 12.1. XML Namespace Name for e2e Data in XMPP
A URN sub-namespace for signed and encrypted content in the A URN sub-namespace of signed and encrypted content for the
Extensible Messaging and Presence Protocol (XMPP) is defined as Extensible Messaging and Presence Protocol (XMPP) is defined as
follows. (This namespace name adheres to the format defined in follows. (This namespace name adheres to the format defined in
[XML-REG].) [XML-REG].)
URI: urn:ietf:params:xml:ns:xmpp-e2e URI: urn:ietf:params:xml:ns:xmpp-e2e
Specification: XXXX Specification: RFC 3923
Description: This is the XML namespace name for signed and encrypted Description: This is an XML namespace name of signed and encrypted
content in the Extensible Messaging and Presence Protocol as content for the Extensible Messaging and Presence Protocol as
defined by XXXX. defined by RFC 3923.
Registrant Contact: IESG, <iesg@ietf.org> Registrant Contact: IESG, <iesg@ietf.org>
12.2 Content-type Registration for "application/xmpp+xml" 12.2. Content-type Registration for "application/xmpp+xml"
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/xmpp+xml Subject: Registration of MIME media type application/xmpp+xml
MIME media type name: application MIME media type name: application
MIME subtype name: xmpp+xml MIME subtype name: xmpp+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: (charset) Same as charset parameter of Optional parameters: (charset) Same as charset parameter of
application/xml as specified in RFC 3023; per Section 11.5 of application/xml as specified in RFC 3023; per Section 11.5 of
[draft-ietf-xmpp-core-24], the charset must be UTF-8. [XMPP-CORE], the charset must be UTF-8.
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023; per Section 11.5 of application/xml as specified in RFC 3023; per Section 11.5 of
[draft-ietf-xmpp-core-24], the encoding must be UTF-8. [XMPP-CORE], the encoding must be UTF-8.
Security considerations: All of the security considerations specified Security considerations: All of the security considerations specified
in RFC 3023 and [draft-ietf-xmpp-core-24] apply to this XML media in RFC 3023 and [XMPP-CORE] apply to this XML media type. Refer
type. Refer to Section 11 of XXXX. to Section 11 of RFC 3923.
Interoperability considerations: (none) Interoperability considerations: (none)
Specification: XXXX Specification: RFC 3923
Applications which use this media type: XMPP-compliant instant Applications which use this media type: XMPP-compliant instant
messaging and presence systems. messaging and presence systems.
Additional information: (none) Additional information: (none)
Person and email address to contact for further information: IESG, Person and email address to contact for further information: IESG,
<iesg@ietf.org> <iesg@ietf.org>
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: IETF, XMPP Working Group Author/Change controller: IETF, XMPP Working Group
13. References 13. References
13.1 Normative References 13.1. Normative References
[CERT] Ramsdell, B., "S/MIME Version 3.1 Certificate Handling", [CERT] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
draft-ietf-smime-rfc2632bis-07 (work in progress), June Extensions (S/MIME) Version 3.1 Certificate Handling",
2004. RFC 3850, July 2004.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
draft-ietf-smime-rfc3369bis-04 (work in progress), May 3852, July 2004.
2004.
[CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard (AES) [CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard
Encryption Algorithm in Cryptographic Message Syntax (AES) Encryption Algorithm in Cryptographic Message
(CMS)", RFC 3565, July 2003. Syntax (CMS)", RFC 3565, July 2003.
[CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) [CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002. Algorithms", RFC 3370, August 2002.
[CPIM] Peterson, J., "Common Profile for Instant Messaging [CPIM] Peterson, J., "Common Profile for Instant Messaging
(CPIM)", draft-ietf-impp-im-04 (work in progress), (CPIM)", RFC 3860, August 2004.
February 2004.
[CPP] Peterson, J., "Common Profile for Presence (CPP)", [CPP] Peterson, J., "Common Profile for Presence (CPP)", RFC
draft-ietf-impp-pres-04 (work in progress), February 2004. 3859, August 2004.
[DATETIME] [DATETIME] Klyne, G. and C. Newman, "Date and Time on the
Klyne, G. and C. Newman, "Date and Time on the Internet: Internet: Timestamps", RFC 3339, July 2002.
Timestamps", RFC 3339, July 2002.
[DISP] Troost, R., Dorner, S. and K. Moore, "Communicating [DISP] Troost, R., Dorner, S., and K. Moore, Ed.,
Presentation Information in Internet Messages: The "Communicating Presentation Information in Internet
Content-Disposition Header Field", RFC 2183, August 1997. 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
Presence and Instant Messaging", RFC 2778, February 2000, 2000.
<http://www.ietf.org/rfc/rfc2778.txt>.
[IMP-REQS] [IMP-REQS] Day, M., Aggarwal, S., Mohr, G., and J. Vincent,
Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / "Instant Messaging/Presence Protocol Requirements", RFC
Presence Protocol Requirements", RFC 2779, February 2000. 2779, February 2000.
[MSGFMT] Atkins, D. and G. Klyne, "Common Presence and Instant [MSGFMT] Klyne, G. and D. Atkins, "Common Presence and Instant
Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08 Messaging (CPIM): Message Format", RFC 3862, August
(work in progress), January 2003. 2004.
[MULTI] Galvin, J., Murphy, S., Crocker, S. and N. Freed, [MULTI] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and "Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995. Multipart/Encrypted", RFC 1847, October 1995.
[PIDF] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W. [PIDF] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
and J. Peterson, "Presence Information Data Format", W., and J. Peterson, "Presence Information Data Format
draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003. (PIDF)", RFC 3863, August 2004.
[SMIME] Ramsdell, B., "S/MIME Version 3.1 Message Specification", [SMIME] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
draft-ietf-smime-rfc2633bis-09 (work in progress), April Extensions (S/MIME) Version 3.1 Message Specification",
2004. RFC 3851, July 2004.
[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 [XML-MEDIA] Murata, M., St. Laurent, S. and D. Kohn, "XML Media
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[XML-MEDIA]
Murata, M., St. Laurent, S. and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[XMPP-CORE] [XMPP-CORE] Saint-Andre, P., Ed., "Extensible Messaging and
Saint-Andre, P., "XMPP Core", draft-ietf-xmpp-core-24 Presence Protocol (XMPP): Core", RFC 3920, October
(work in progress), May 2004. 2004.
[XMPP-IM] Saint-Andre, P., "XMPP Instant Messaging", [XMPP-IM] Saint-Andre, P., Ed., "Extensible Messaging and
draft-ietf-xmpp-im-22 (work in progress), May 2004. Presence Protocol (XMPP) Instant Messaging and
Presence", RFC 3921, October 2004.
13.2 Informative References 13.2. Informative References
[CAPS] Hildebrand, J. and P. Saint-Andre, "JEP-0115: Entity [CAPS] Hildebrand, J. and P. Saint-Andre, "Entity
Capabilities", April 2004, Capabilities", JSF JEP 0115, August 2004.
<http://www.jabber.org/jeps/jep-0115.html>.
[CMC] Myers, M., Liu, X., Schaad, J. and J. Weinstein, [CMC] Myers, M., Liu, X., Schaad, J. and J. Weinstein,
"Certificate Management Messages over CMS", RFC 2797, "Certificate Management Messages over CMS", RFC 2797,
April 2000. April 2000.
[CMP] Adams, C. and S. Farrell, "Internet X.509 Public Key [CMP] Adams, C. and S. Farrell, "Internet X.509 Public Key
Infrastructure Certificate Management Protocols", RFC Infrastructure Certificate Management Protocols", RFC
2510, March 1999. 2510, March 1999.
[DISCO] Hildebrand, J., Millard, P., Eatmon, R. and P. [DISCO] Hildebrand, J., Millard, P., Eatmon, R. and P. Saint-
Saint-Andre, "JEP-0030: Service Discovery", June 2004, Andre, "Service Discovery", JSF JEP 0030, July 2004.
<http://www.jabber.org/jeps/jep-0030.html>.
[MUC] Saint-Andre, P., "JEP-0045: Multi-User Chat", June 2004, [MUC] Saint-Andre, P., "Multi-User Chat", JSF JEP 0045, June
<http://www.jabber.org/jeps/jep-0045.html>. 2004.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (3rd ed)", W3C "Extensible Markup Language (XML) 1.0 (3rd ed)", W3C
REC-xml, February 2004, <http://www.w3.org/TR/REC-xml>. REC-xml, February 2004, <http://www.w3.org/TR/REC-xml>.
[XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC
January 2004. 3688, January 2004.
[XMPP-CPIM]
Saint-Andre, P., "Mapping the Extensible Messaging and
Presence Protocol (XMPP) to Common Presence and Instant
Messaging (CPIM)", draft-ietf-xmpp-cpim-05 (work in
progress), May 2004.
Author's Address
Peter Saint-Andre
Jabber Software Foundation
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.
<?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' targetNamespace='urn:ietf:params:xml:ns:xmpp-e2e'
skipping to change at page 25, line 39 skipping to change at page 26, line 31
<xs:element name='bad-timestamp' type='empty'/> <xs:element name='bad-timestamp' type='empty'/>
<xs:simpleType name='empty'> <xs:simpleType name='empty'>
<xs:restriction base='xs:string'> <xs:restriction base='xs:string'>
<xs:enumeration value=''/> <xs:enumeration value=''/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
Appendix B. Revision History Author's Address
Note to RFC Editor: please remove this entire appendix, and the
corresponding entries in the table of contents, prior to publication.
B.1 Changes from draft-ietf-xmpp-e2e-08
o Changed title to mention signing in addition to encryption.
o Specified several functionality areas that are out of scope for
this memo.
o Added clarifying text to the examples, split several examples in
order to correspond to the defined process steps, and added
examples for encrypting both messages and presence information.
o Changed SHOULD to MUST regarding checking of XMPP addresses.
o Changed "could" to SHOULD regarding sending of initial message
requesting certificate retrieval.
o Specified that 'from' attributes MUST (rather than SHOULD) match a
JID contained in the sender's certificate, and that resource
identifiers SHOULD be ignored for matching purposes.
o More fully defined S/MIME handling, including correct processing
of XML stanzas with invalid signatures, stanzas that cannot be
decrypted, and messages that appear to be replayed.
o Defined recipient generation of XMPP error stanzas.
o Incorporated text for "Mandatory-to-Implement Cryptographic
Algorithms" suggested by Russ Housley.
o Referred to Section 5.1.1 of XMPP-CORE regarding ASN.1 Object
Identifier to be used when an XMPP address is represented in a
certificate.
o Added reference to RFC 3565.
o Fixed CMC reference to point to RFC 2797.
o Updated references to point to rfc2632bis, rfc2633bis, and
rfc3369bis.
o Updated boilerplate to refer to RFC 3668.
o Removed Discussion Venue subsection.
B.2 Changes from draft-ietf-xmpp-e2e-07
o Clarified relationship of the 'urn:ietf:params:xml:ns:xmpp-e2e'
namespace to its encapsulated objects, including versioning, and
placed this content in its own section.
o Clarified nature of "application/xmpp+xml" media type and placed
this content in its own section.
o Added reference to RFC 3023 and modified XML media type
registration to adhere to the guidelines specified therein.
o Changed XML params registrant to IESG, per RFC 3688.
o Updated other references.
B.3 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.4 Changes from draft-ietf-xmpp-e2e-05
o Addressed I-D nits and RFC Editor formatting.
B.5 Changes from draft-ietf-xmpp-e2e-04
o Added text about instant inbox addresses.
B.6 Changes from draft-ietf-xmpp-e2e-03
o Specified that S/MIME multipart objects are enclosed in a CDATA
section.
o Changed "text/xml" to "text/plain" for message examples.
o Specified must-implement technologies, transfer encodings,
certificate enrollment, certificate retrieval, and certificate
names (including subjectAltName for JIDs).
o Specified requirements regarding attachment of signatures and
inclusion of certificates.
o Fixed some small terminological errors.
B.7 Changes from draft-ietf-xmpp-e2e-02 Peter Saint-Andre
Jabber Software Foundation
o Completely revised to use formats defined in the CPIM EMail: stpeter@jabber.org
specifications, S/MIME only, etc.
B.8 Changes from draft-ietf-xmpp-e2e-01 Full Copyright Statement
o Removed old Section 6 (Signalling Support via Presence) -- the Copyright (C) The Internet Society (2004).
ability to sign broadcasted presence made it redundant.
o Made small editorial changes to address RFC Editor requirements.
B.9 Changes from draft-ietf-xmpp-e2e-00 This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
o Added support for all stanza types. This document and the information contained herein are provided on an
o Specified that the full stanza is encrypted. "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
o Added support for S/MIME in addition to OpenPGP. REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
o Specified that encrypted presence must be directed to a specific INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
recipient. IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
o Specified order of encrypting and signing. THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
o Added support for signing broadcasted presence. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
o Added IANA considerations.
o Changed namespace to 'urn:ietf:params:xml:ns:xmpp-e2e'.
o Added XML schema.
Intellectual Property Statement Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the IETF's procedures with respect to rights in IETF Documents can
found in BCP 78 and BCP 79. be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at ietf-
ietf-ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgement
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. 85 change blocks. 
297 lines changed or deleted 169 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/