idnits 2.17.1
draft-ietf-xmpp-e2e-09.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3667, Section 5.1 on line 14.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 1238.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1215.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1222.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1228.
** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line
1244), which is fine, but *also* found old RFC 2026, Section 10.4C,
paragraph 1 text on line 36.
** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
Acknowledgement -- however, there's a paragraph with a matching
beginning. Boilerplate error?
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission
of drafts without verbatim RFC 3978 boilerplate is not accepted.
The following non-3978 patterns matched text found in the document.
That text should be removed or replaced:
By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, or
will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 27
longer pages, the longest (page 25) being 72 lines
== It seems as if not all pages are separated by form feeds - found 0 form
feeds but 28 pages
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (July 12, 2004) is 7228 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Unused Reference: 'X509' is defined on line 1020, but no explicit
reference was found in the text
== Unused Reference: 'XMPP-CPIM' is defined on line 1064, but no explicit
reference was found in the text
** Downref: Normative reference to an Informational RFC: RFC 2778 (ref.
'IMP-MODEL')
** Downref: Normative reference to an Informational RFC: RFC 2779 (ref.
'IMP-REQS')
** Obsolete normative reference: RFC 3280 (ref. 'X509') (Obsoleted by RFC
5280)
** Obsolete normative reference: RFC 3023 (ref. 'XML-MEDIA') (Obsoleted by
RFC 7303)
-- Obsolete informational reference (is this intentional?): RFC 2797 (ref.
'CMC') (Obsoleted by RFC 5272)
-- Obsolete informational reference (is this intentional?): RFC 2510 (ref.
'CMP') (Obsoleted by RFC 4210)
Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 XMPP Working Group P. Saint-Andre
2 Internet-Draft Jabber Software Foundation
3 Expires: January 10, 2005 July 12, 2004
5 End-to-End Signing and Object Encryption in the Extensible Messaging
6 and Presence Protocol (XMPP)
7 draft-ietf-xmpp-e2e-09
9 Status of this Memo
11 By submitting this Internet-Draft, I certify that any applicable
12 patent or other IPR claims of which I am aware have been disclosed,
13 and any of which I become aware will be disclosed, in accordance with
14 RFC 3668.
16 Internet-Drafts are working documents of the Internet Engineering
17 Task Force (IETF), its areas, and its working groups. Note that
18 other groups may also distribute working documents as
19 Internet-Drafts.
21 Internet-Drafts are draft documents valid for a maximum of six months
22 and may be updated, replaced, or obsoleted by other documents at any
23 time. It is inappropriate to use Internet-Drafts as reference
24 material or to cite them other than as "work in progress."
26 The list of current Internet-Drafts can be accessed at
27 http://www.ietf.org/ietf/1id-abstracts.txt.
29 The list of Internet-Draft Shadow Directories can be accessed at
30 http://www.ietf.org/shadow.html.
32 This Internet-Draft will expire on January 10, 2005.
34 Copyright Notice
36 Copyright (C) The Internet Society (2004). All Rights Reserved.
38 Abstract
40 This memo defines a method for end-to-end signing and object
41 encryption in the Extensible Messaging and Presence Protocol (XMPP).
43 Table of Contents
45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
46 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
47 3. Securing Messages . . . . . . . . . . . . . . . . . . . . . 5
48 4. Securing Presence . . . . . . . . . . . . . . . . . . . . . 9
49 5. Securing Arbitrary XMPP Data . . . . . . . . . . . . . . . . 13
50 6. Rules for S/MIME Generation and Handling . . . . . . . . . . 15
51 7. Recipient Error Handling . . . . . . . . . . . . . . . . . . 18
52 8. Secure Communications Through a Gateway . . . . . . . . . . 20
53 9. urn:ietf:params:xml:xmpp-e2e Namespace . . . . . . . . . . . 20
54 10. application/xmpp+xml Media Type . . . . . . . . . . . . . . 21
55 11. Security Considerations . . . . . . . . . . . . . . . . . . 21
56 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21
57 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
58 13.1 Normative References . . . . . . . . . . . . . . . . . . . 22
59 13.2 Informative References . . . . . . . . . . . . . . . . . . 24
60 Author's Address . . . . . . . . . . . . . . . . . . . . . . 25
61 A. Schema for urn:ietf:params:xml:ns:xmpp-e2e . . . . . . . . . 25
62 B. Revision History . . . . . . . . . . . . . . . . . . . . . . 25
63 Intellectual Property and Copyright Statements . . . . . . . 28
65 1. Introduction
67 This memo define a method for end-to-end signing and object
68 encryption in the Extensible Messaging and Presence Protocol (XMPP).
69 (For information about XMPP, see [XMPP-CORE] and [XMPP-IM].) The
70 method specified herein enables a sender to sign and/or encrypt an
71 instant message sent to a specific recipient, sign and/or encrypt
72 presence information that is directed to a specific user, and sign
73 and/or encrypt any arbitrary XMPP stanza directed to a specific user.
74 This memo thereby helps the XMPP specifications meet the requirements
75 specified in [IMP-REQS].
77 1.1 Terminology
79 This document inherits terminology defined in [CMS], [IMP-MODEL],
80 [SMIME], and [XMPP-CORE].
82 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
83 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
84 "OPTIONAL" in this document are to be interpreted as described in
85 [TERMS].
87 2. Requirements
89 For the purposes of this memo, we stipulate the following
90 requirements:
92 1. The method defined MUST address signing and encryption
93 requirements for minimal instant messaging and presence, as those
94 are defined in [IMP-REQS]. In particular, the method MUST
95 address the following requirements, which are copied here
96 verbatim from [IMP-REQS]:
97 * The protocol MUST provide means to ensure confidence that a
98 received message (NOTIFICATION or INSTANT MESSAGE) has not
99 been corrupted or tampered with. (Section 2.5.1)
100 * The protocol MUST provide means to ensure confidence that a
101 received message (NOTIFICATION or INSTANT MESSAGE) has not
102 been recorded and played back by an adversary. (Section
103 2.5.2)
104 * The protocol MUST provide means to ensure that a sent message
105 (NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES
106 that the sender allows. (Section 2.5.3)
107 * The protocol MUST allow any client to use the means to ensure
108 non-corruption, non-playback, and privacy, but the protocol
109 MUST NOT require that all clients use these means at all
110 times. (Section 2.5.4)
111 * When A establishes a SUBSCRIPTION to B's PRESENCE INFORMATION,
112 the protocol MUST provide A means of verifying the accurate
113 receipt of the content B chooses to disclose to A. (Section
114 5.1.4)
115 * The protocol MUST provide A means of verifying that the
116 presence information is accurate, as sent by B. (Section
117 5.3.1)
118 * The protocol MUST provide A means of ensuring that no other
119 PRINCIPAL C can see the content of M. (Section 5.4.6)
120 * The protocol MUST provide A means of ensuring that no other
121 PRINCIPAL C can tamper with M, and B means to verify that no
122 tampering has occurred. (Section 5.4.7)
123 2. The method defined MUST enable interoperability with non-XMPP
124 messaging systems that support the Common Presence and Instant
125 Messaging (CPIM) specifications published by the Instant
126 Messaging and Presence (IMPP) Working Group. Two corollaries of
127 this requirement are:
128 * Prior to signing and/or encrypting, the format of an instant
129 message MUST conform to the CPIM Message Format defined in
130 [MSGFMT].
131 * Prior to signing and/or encrypting, the format of presence
132 information MUST conform to the CPP Presence Information Data
133 Format defined in [PIDF].
134 3. The method MUST follow the required procedures (including the
135 specific algorithms) defined in [CPIM] and [CPP]. In particular,
136 these documents specify:
137 * Signing MUST use [SMIME] signatures with [CMS] SignedData.
138 * Encryption MUST use [SMIME] encryption with [CMS]
139 EnvelopeData.
140 4. In order to enable interoperable implementations, sending and
141 receiving applications MUST implement the algorithms specified
142 under Mandatory-to-Implement Cryptographic Algorithms (Section
143 6.10).
145 We further stipulate that the following functionality is out of scope
146 for this memo:
148 o Discovery of support for this protocol. An entity could discover
149 whether another entity supports this protocol by (1) attempting to
150 send signed or encrypted stanzas and receiving an error stanza
151 ("technical" discovery) or a textual message in reply ("social"
152 discovery) if the protocol is not supported, or (2) using a
153 dedicated service discovery protocol, such as [DISCO] or [CAPS].
154 However, the definition of a service discovery protocol is out of
155 scope for this memo.
156 o Signing or encryption of XMPP groupchat messages, which are
157 mentioned in [XMPP-IM] but not defined therein since they are not
158 required by [IMP-REQS]; such messages are best specified in [MUC].
159 o Signing or encryption of broadcasted presence as described in
160 [XMPP-IM] (the methods defined herein apply to directed presence
161 only).
162 o Signing or encryption of communications that occur within the
163 context of applications other than instant messaging and presence
164 as those are described in [IMP-MODEL] and [IMP-REQS].
166 3. Securing Messages
168 3.1 Process for Securing Messages
170 In order to sign and/or encrypt a message, a sending agent MUST use
171 the following procedure:
173 1. Generate a "Message/CPIM" object as defined in [MSGFMT].
174 2. Sign and/or encrypt both the headers and content of the "Message/
175 CPIM" object as specified in Requirement 3 of Section 2 above.
176 3. Provide the resulting signed and/or encrypted object within an
177 XML CDATA section (see Section 2.7 of [XML]) contained in an
178 child of a stanza, where the element is
179 qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace as
180 specified more fully in Section 9 below.
182 3.2 Example of a Signed Message
184 The following example illustrates the defined steps for signing a
185 message.
187 First, the sending agent generates a "Message/CPIM" object in
188 accordance with the rules and formats specified in [MSGFMT].
190 Example 1: Sender generates "Message/CPIM" object:
192 | Content-type: Message/CPIM
193 |
194 | From: Juliet Capulet
195 | To: Romeo Montague
196 | DateTime: 2003-12-09T11:45:36.66Z
197 | Subject: Imploring
198 |
199 | Content-type: text/plain; charset=utf-8
200 | Content-ID: <1234567890@example.com>
201 |
202 | Wherefore art thou, Romeo?
204 Once the sending agent has generated the "Message/CPIM" object, the
205 sending agent may sign it. The result is a multipart [SMIME] object
206 (see [MULTI]) that has a Content-Type of "multipart/signed" and
207 includes two parts: one whose Content-Type is "Message/CPIM" and
208 another whose Content-Type is "application/pkcs7-signature".
210 Example 2: Sender generates multipart/signed object:
212 | Content-Type: multipart/signed; boundary=next;
213 | micalg=sha1;
214 | protocol=application/pkcs7-signature
215 |
216 | --next
217 | Content-type: Message/CPIM
218 |
219 | From: Juliet Capulet
220 | To: Romeo Montague
221 | DateTime: 2003-12-09T23:45:36.66Z
222 | Subject: Imploring
223 |
224 | Content-type: text/plain; charset=utf-8
225 | Content-ID: <1234567890@example.com>
226 |
227 | Wherefore art thou, Romeo?
228 | --next
229 | Content-Type: application/pkcs7-signature
230 | Content-Disposition: attachment;handling=required;\
231 | filename=smime.p7s
232 |
233 | [signed body part]
234 |
235 | --next--
237 The sending agent now wraps the "mulipart/signed" object in an XML
238 CDATA section, which is contained in an element that is
239 included as a child element of the XMPP message stanza and that is
240 qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
242 Example 3: Sender generates XMPP message stanza:
244 |
245 |
246 |
255 | To: Romeo Montague
256 | DateTime: 2003-12-09T23:45:36.66Z
257 | Subject: Imploring
258 |
259 | Content-type: text/plain; charset=utf-8
260 | Content-ID: <1234567890@example.com>
261 |
262 | Wherefore art thou, Romeo?
263 | --next
264 | Content-Type: application/pkcs7-signature
265 | Content-Disposition: attachment;handling=required;\
266 | filename=smime.p7s
267 |
268 | [signed body part]
269 |
270 | --next--
271 | ]]>
272 |
273 |
275 3.3 Example of an Encrypted Message
277 The following example illustrates the defined steps for encrypting a
278 message.
280 First, the sending agent generates a "Message/CPIM" object in
281 accordance with the rules and formats specified in [MSGFMT].
283 Example 4: Sender generates "Message/CPIM" object:
285 | Content-type: Message/CPIM
286 |
287 | From: Juliet Capulet
288 | To: Romeo Montague
289 | DateTime: 2003-12-09T11:45:36.66Z
290 | Subject: Imploring
291 |
292 | Content-type: text/plain; charset=utf-8
293 | Content-ID: <1234567890@example.com>
294 |
295 | Wherefore art thou, Romeo?
297 Once the sending agent has generated the "Message/CPIM" object, the
298 sending agent may encrypt it.
300 Example 5: Sender generates encrypted object:
302 | U2FsdGVkX19okeKTlLxa/1n1FE/upwn1D20GhPWqhDWlexKMUKYJInTWzERP+vcQ
303 | /OxFs40uc9Fx81a5/62p/yPb/UWnuG6SR6o3Ed2zwcusDImyyz125HFERdDUMBC9
304 | Pt6Z4cTGKBmJzZBGyuc3Y+TMBTxqFFUAxeWaoxnZrrl+LP72vwbriYc3KCMxDbQL
305 | Igc1Vzs5/5JecegMieNY24SlNyX9HMFRNFpbI64vLxYEk55A+3IYbZsluCFT31+a
306 | +GeAvJkvH64LRV4mPbUhENTQ2wbAwnOTvbLIaQEQrii78xNEh+MK8Bx7TBTvi4yH
307 | Ddzf9Sim6mtWsXaCAvWSyp0X91d7xRJ4JIgKfPzkxNsWJFCLthQS1p734eDxXVd3
308 | i08lEHzyll6htuEr59ZDAw==
310 The sending agent now wraps the encrypted object in an XML CDATA
311 section, which is contained in an element that is included as
312 a child element of the XMPP message stanza and that is qualified by
313 the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
315 Example 6: Sender generates XMPP message stanza:
317 |
318 |
319 |
328 |
329 |
331 4. Securing Presence
333 4.1 Process for Securing Presence Information
335 In order to sign and/or encrypt presence information, a sending agent
336 MUST use the following procedure:
338 1. Generate an "application/pidf+xml" object as defined in [PIDF].
339 2. Sign and/or encrypt the "application/pidf+xml" object as
340 specified in Requirement 3 of Section 2 above.
341 3. Provide the resulting signed and/or encrypted object within an
342 XML CDATA section (see Section 2.7 of [XML]) contained in an
343 child of a stanza, where the element is
344 qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
345 The stanza MUST include a 'to' attribute, i.e., it
346 must be an instance of directed presence as defined in [XMPP-IM].
348 4.2 Example of Signed Presence Information
350 The following example illustrates the defined steps for signing
351 presence information.
353 First, the sending agent generates an "application/pidf+xml" object
354 in accordance with the rules and formats specified in [PIDF].
356 Example 7: Sender generates "application/pidf+xml" object:
358 |
359 |
362 |
364 | open
365 | away
366 |
367 | retired to the chamber
368 | 2003-12-09T23:53:11.31
369 |
370 |
372 Once the sending agent has generated the "application/pidf+xml"
373 object, the sending agent may sign it. The result is a multipart
374 [SMIME] object (see [MULTI]) that has a Content-Type of "multipart/
375 signed" and includes two parts: one whose Content-Type is
376 "application/pidf+xml" and another whose Content-Type is
377 "application/pkcs7-signature".
379 Example 8: Sender generates multipart/signed object:
381 | Content-Type: multipart/signed; boundary=next;
382 | micalg=sha1;
383 | protocol=application/pkcs7-signature
384 |
385 | --next
386 | Content-type: application/pidf+xml
387 | Content-ID: <2345678901@example.com>
388 |
389 |
390 |
393 |
394 | open
396 | away
397 |
398 | retired to the chamber
399 | 2003-12-09T23:53:11.31Z
400 |
401 |
402 | --next
403 | Content-Type: application/pkcs7-signature
404 | Content-Disposition: attachment;handling=required;\
405 | filename=smime.p7s
406 |
407 | [signed body part]
408 |
409 | --next--
411 The sending agent now wraps the "mulipart/signed" object in an XML
412 CDATA section, which is contained in an element that is
413 included as a child element of the XMPP message stanza and that is
414 qualified by the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
416 Example 9: Sender generates XMPP presence stanza:
418 |
419 |
420 |
428 |
429 |
430 |
433 |
434 |
435 | open
436 | away
437 |
438 | retired to the chamber
439 | 2003-12-09T23:53:11.31Z
440 |
441 |
442 | --next
443 | Content-Type: application/pkcs7-signature
444 | Content-Disposition: attachment;handling=required;\
445 | filename=smime.p7s
446 |
447 | [signed body part]
448 |
449 | --next--
450 | ]]>
451 |
452 |
454 4.3 Example of Encrypted Presence Information
456 The following example illustrates the defined steps for encrypting
457 presence information.
459 First, the sending agent generates an "application/pidf+xml" object
460 in accordance with the rules and formats specified in [PIDF].
462 Example 10: Sender generates "application/pidf+xml" object:
464 |
465 |
468 |
470 | open
471 | away
472 |
473 | retired to the chamber
474 | 2003-12-09T23:53:11.31
475 |
476 |
478 Once the sending agent has generated the "application/pidf+xml"
479 object, the sending agent may encrypt it.
481 Example 11: Sender generates encrypted object:
483 | U2FsdGVkX18VJPbx5GMdFPTPZrHLC9QGiVP+ziczu6zWZLFQxae6O5PP6iqpr2No
484 | zOvBVMWvYeRAT0zd18hr6qsqKiGl/GZpAAbTvPtaBxeIykxsd1+CX+U+iw0nEGCr
485 | bjiQrk0qUKJ79bNxwRnqdidjhyTpKSbOJC0XZ8CTe7AE9KDM3Q+uk+O3jrqX4byL
486 | GBlKThbzKidxz32ObojPEEwfFiM/yUeqYUP1OcJpUmeQ8lcXhD6tcx+m2MAyYYLP
487 | boKQxpLknxRnbM8T/voedlnFLbbDu69mOlxDPbr1mHZd3hDsyFudb1fb4rI3Kw0K
488 | Nq+3udr2IkysviJDgQo+xGIQUG/5sED/mAaPRlj4f/JtTzvT4EaQTawv69ntXfKV
489 | MCr9KdIMMdjdJzOJkYLoAhNVrcZn5tw8WsJGwuKuhYb/SShy7InzOapPaPAl7/Mm
490 | PHj7zj3NZ6EEIweDOuAwWlIG/dT506tci27+EW7JnXwMPnFMkF+6a7tr/0Y+iiej
491 | woJxUIBqCOgX+U7srHpK2NYtNTZ7UQp2V0yEx1JV8+Y=
493 The sending agent now wraps the encrypted object in an XML CDATA
494 section, which is contained in an element that is included as
495 a child element of the XMPP message stanza and that is qualified by
496 the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
498 Example 12: Sender generates XMPP presence stanza:
500 |
501 |
502 |
513 |
514 |
516 5. Securing Arbitrary XMPP Data
518 The foregoing sections of this memo describe how to secure "least
519 common denominator" messaging and presence data of the kind that can
520 be directly translated into the MSGFMT or PIDF formats. However,
521 XMPP possesses a third base-level stanza type () in addition to
522 and , as well as the ability to include
523 extended XML data within arbitrary child elements of the three core
524 stanza types. Therefore it would be desirable to secure such data if
525 possible.
527 Because [MSGFMT] specifies the ability to encapsulate any MIME type,
528 the approach taken in this memo is to include arbitrary XMPP data in
529 an XML media type named "application/xmpp+xml" as specified more
530 fully in Section 10 below.
532 The following examples illustrate the structure of the "application/
533 xmpp+xml" MIME type. (Note: The 'http://jabber.org/protocol/evil'
534 namespace used in these examples is associated with an April Fool's
535 protocol written to be the instant messaging equivalent of RFC 3514;
536 it is included only as an instance of extended information included
537 in an XML stanza and should not be taken seriously as a functional
538 XMPP extension.)
539 Example 13: Message stanza with extended data contained in
540 "application/xmpp+xml" MIME type:
542 |
543 |
544 |
547 |
548 | I told him what I thought, and told no more
549 | Than what he found himself was apt and true.
550 |
551 |
552 |
553 |
555 Example 14: Presence stanza with extended data contained in
556 "application/xmpp+xml" MIME type:
558 |
559 |
560 |
561 | dnd
562 | Fomenting dissension
563 |
564 |
565 |
567 Example 15: IQ stanza with extended data contained in "application/
568 xmpp+xml" MIME type:
570 |
571 |
572 |
576 |
577 | Stabber
578 | 666
579 | FiendOS
580 |
581 |
582 |
583 |
585 Just as with the "Message/CPIM" and "application/pidf+xml" objects,
586 the "application/xmpp+xml" object would be signed and/or encrypted,
587 then encapsulated within an XML CDATA section (see Section 2.7 of
588 [XML]) contained in an child of a stanza, where
589 the element is qualified by the
590 'urn:ietf:params:xml:ns:xmpp-e2e' namespace.
592 6. Rules for S/MIME Generation and Handling
594 6.1 Certificate Enrollment
596 [SMIME] does not specify how to obtain a certificate from a
597 certificate authority, but instead mandates that every sending agent
598 must already have a certificate. The PKIX Working Group has, at the
599 time of this writing, produced two separate standards for certificate
600 enrollment: [CMP] and [CMC]. Which method to use for certificate
601 enrollment is outside the scope of this memo.
603 6.2 Certificate Retrieval
605 A receiving agent MUST provide some certificate retrieval mechanism
606 in order to gain access to certificates for recipients of digital
607 envelopes. This memo does not address how S/MIME agents handle
608 certificates, only what they do after a certificate has been
609 validated or rejected. S/MIME certification issues are covered in
610 [CERT].
612 However, at a minimum, for initial S/MIME deployment, a user agent
613 SHOULD automatically generate a message to an intended recipient
614 requesting that recipient's certificate in a signed return message.
615 Receiving and sending agents SHOULD also provide a mechanism to allow
616 a user to "store and protect" certificates for correspondents in such
617 a way so as to guarantee their later retrieval.
619 6.3 Certificate Names
621 End-entity certificates used by XMPP entities in the context of this
622 memo SHOULD contain a valid instant messaging and presence address.
623 The address SHOULD be specified as both an 'im:' URI (for instant
624 messaging, as defined in [CPIM]) and a 'pres:' URI (for presence, as
625 defined in [CPP]); each of these URIs SHOULD be specified in a
626 separate GeneralName entry of type uniformResourceIdentifier inside
627 the subjectAltName (i.e., two separate entries). Information in the
628 subject distinguished name SHOULD be ignored.
630 Each URI MUST be of the form or , where
631 the "address" portion is an XMPP address (also referred to as a
632 Jabber Identifier or JID) as defined in [XMPP-CORE], prepended with
633 the 'im:' or 'pres:' URI scheme. The address SHOULD be of the form
634 (i.e., a "bare JID"), although any valid JID form MAY
635 be used.
637 The value of the JID contained in the XMPP 'from' attribute MUST
638 match a JID provided in the signer's certificate, with the exception
639 that the resource identifier portion of the JID contained in the
640 'from' attribute SHOULD be ignored for matching purposes.
642 Receiving agents MUST check that the sending JID matches a JID
643 provided in the signer's certificate, with the exception that the
644 resource identifier portion of the JID contained in the 'from'
645 attribute SHOULD be ignored for matching purposes. A receiving agent
646 SHOULD provide some explicit alternate processing of the stanza if
647 this comparison fails, which may be to display a message informing
648 the recipient of the addresses in the certificate or other
649 certificate details.
651 The subject alternative name extension is used in S/MIME as the
652 preferred means to convey the instant messaging and presence address
653 that corresponds to the entity for this certificate. Any XMPP
654 address present in the certificate MUST be encoded using the ASN.1
655 Object Identifier "id-on-xmppAddr" as specified in Section 5.1.1 of
656 [XMPP-CORE].
658 6.4 Transfer Encoding
660 Because it is expected that XMPP applications will not interface with
661 older 7-bit systems, the transfer encoding (as defined in Section
662 3.1.2 of [SMIME]) MUST be "binary".
664 6.5 Order of Signing and Encrypting
666 If a stanza is both signed and encrypted, it SHOULD be signed first,
667 then encrypted.
669 6.6 Inclusion of Certificates
671 If the sender and recipient are involved in an active messaging
672 session over a period of time, the sending agent SHOULD include the
673 sender's certificate along with at least one encrypted message stanza
674 every five minutes. Outside the context of an active messaging
675 session, the sending agent SHOULD include the sender's certificate
676 along with each encrypted message stanza. A sending agent MAY
677 include the sender's certificate along with each encrypted presence
678 stanza. However, a sending agent SHOULD NOT include a certificate
679 more than once every five minutes.
681 6.7 Attachment and Checking of Signatures
683 Sending agents SHOULD attach a signature to each encrypted XML
684 stanza. If a signature is attached, a Content-Disposition header
685 field (as defined in [DISP]) SHOULD be included to specify how the
686 signature is to be handled by the receiving application.
688 If the receiving agent determines that the signature attached to an
689 encrypted XML stanza is invalid, it SHOULD NOT present the stanza to
690 the intended recipient (human or application), SHOULD provide some
691 explicit alternate processing of the stanza (which may be to display
692 a message informing the recipient that the attached signature is
693 invalid), and MAY return a stanza error to the sender as described
694 under Recipient Error Handling (Section 7).
696 6.8 Decryption
698 If the receiving agent is unable to decrypt the encrypted XML stanza,
699 it SHOULD NOT present the stanza to the intended recipient (human or
700 application), SHOULD provide some explicit alternate processing of
701 the stanza (which may be to display a message informing the recipient
702 that it has received a stanza that cannot be decrypted), and MAY
703 return a stanza error to the sender as described under Recipient
704 Error Handling (Section 7).
706 6.9 Inclusion and Checking of Timestamps
708 Timestamps are included in "Message/CPIM" and "application/pidf+xml"
709 objects to help prevent replay attacks. All timestamps MUST conform
710 to [DATETIME] and be presented as UTC with no offset, including
711 fractions of a second as appropriate. Absent a local adjustment to
712 the sending agent's perceived time or the underlying clock time, the
713 sending agent MUST ensure that the timestamps it sends to the
714 receiver increase monotonically (if necessary by incrementing the
715 seconds fraction in the timestamp if the clock returns the same time
716 for multiple requests). The following rules apply to the receiving
717 application:
719 o It MUST verify that the timestamp received is within five minutes
720 of the current time.
721 o It SHOULD verify that the timestamp received is greater than any
722 timestamp received in the last 10 minutes which passed the
723 previous check.
724 o If any of the foregoing checks fails, the timestamp SHOULD be
725 presented to the receiving entity (human or application) marked as
726 "old timestamp", "future timestamp", or "decreasing timestamp",
727 and the receiving entity MAY return a stanza error to the sender
728 as described under Recipient Error Handling (Section 7).
730 6.10 Mandatory-to-Implement Cryptographic Algorithms
732 All implementations MUST support the following algorithms.
733 Implementations MAY support other algorithms as well.
735 For CMS SignedData:
737 o The SHA-1 message digest as specified in [CMS-ALG] section 2.1.
738 o The RSA (PKCS #1 v1.5) with SHA-1 signature algorithm, as
739 specified in [CMS-ALG] section 3.2.
741 For CMS EnvelopedData:
743 o The RSA (PKCS #1 v1.5) key transport, as specified in [CMS-ALG]
744 section 4.2.1.
745 o The AES-128 encryption algorithm in CBC mode, as specified in
746 [CMS-AES].
748 7. Recipient Error Handling
750 When an XMPP entity receives an XML stanza containing data that is
751 signed and/or encrypted using the protocol described herein, several
752 scenarios are possible:
754 Case #1: The receiving application does not understand the protocol.
755 Case #2: The receiving application understands the protocol and is
756 able to decrypt the payload and verify the sender's signature.
757 Case #3: The receiving application understands the protocol and is
758 able to decrypt the payload and verify the sender's signature, but
759 the timestamps fail the checks specified above under Checking of
760 Timestamps (Section 6.9).
761 Case #4: The receiving application understands the protocol and is
762 able to decrypt the payload but is unable to verify the sender's
763 signature.
764 Case #5: The receiving application understands the protocol but is
765 unable to decrypt the payload.
767 In Case #1, the receiving application MUST do one and only one of the
768 following: (1) ignore the extension, (2) ignore the entire
769 stanza, or (3) return a error to the sender,
770 as described in [XMPP-CORE].
772 In Case #2, the receiving application MUST NOT return a stanza error
773 to the sender, since this is the success case.
775 In Case #3, the receiving application MAY return a
776 error to the sender (as described in [XMPP-CORE]), optionally
777 supplemented by an application-specific error condition element
778 as shown below:
780 Example 16: Recipient returns error:
782
783
784 [CDATA section here]
785
786
787
788
789
790
792 In Case #4, the receiving application SHOULD return a
793 error to the sender (as described in [XMPP-CORE]),
794 optionally supplemented by an application-specific error condition
795 element as shown below:
797 Example 17: Recipient returns error:
799
800
801 [CDATA section here]
802
803
804
805
806
807
809 In Case #5, the receiving application SHOULD return a
810 error to the sender (as described in [XMPP-CORE]), optionally
811 supplemented by an application-specific error condition element
812 as shown below:
814 Example 18: Recipient returns error:
816
817
818 [CDATA section here]
819
820
821
822
823
824
826 8. Secure Communications Through a Gateway
828 A common method for achieving interoperability between two disparate
829 services is through the use of a "gateway" that interprets the
830 protocols of each service and translates them into the protocols of
831 the other. The CPIM specifications (specifically [MSGFMT] and [PIDF]
832 define the common profiles to be used for interoperability between
833 instant messaging and presence services that comply with [IMP-REQS].
834 In the case of communications between an XMPP service and a non-XMPP
835 service, we can visualize this relationship as follows:
837 +-------------+ +-------------+ +------------+
838 | | | | | |
839 | XMPP | | XMPP-CPIM | | Non-XMPP |
840 | Service | <----> | Gateway | <----> | Service |
841 | | | | | |
842 +-------------+ +-------------+ +------------+
844 The end-to-end encryption method defined herein enables the exchange
845 of encrypted and/or signed instant messages and presence through an
846 XMPP-CPIM gateway. In particular:
848 o When a gateway receives a secured XMPP message or presence stanza
849 from the XMPP service that is addressed to a user on the non-XMPP
850 service, it MUST remove the XMPP "wrapper" (everything down to and
851 including the and tags) in order to reveal the
852 multipart S/MIME object, then route the object to the non-XMPP
853 service (first wrapping it in the protocol used by the non-XMPP
854 service if necessary).
855 o When a gateway receives a secured non-XMPP instant message or
856 presence document from the non-XMPP service that is addressed to a
857 user on the XMPP service, it MUST remove the non-XMPP "wrapper"
858 (if any) in order to reveal the multipart S/MIME object, wrap the
859 object in an XMPP message or presence "wrapper" (including the
860 and tags), and then route the XMPP stanza to the XMPP
861 service.
863 The wrapped S/MIME object MUST be immutable and MUST NOT be modified
864 by an XMPP-CPIM gateway.
866 9. urn:ietf:params:xml:xmpp-e2e Namespace
868 The element is a
869 wrapper for an XML CDATA section (see Section 2.7 of [XML]) that
870 contains a "Message/CPIM", "application/pidf+xml", or "application/
871 xmpp+xml" object. Thus the 'urn:ietf:params:xml:xmpp-e2e' namespace
872 has no inherent semantics, and the semantics of the encapsulated
873 object are defined by one of the following specifications:
875 o [MSGFMT] for "Message/CPIM"
876 o [PIDF] for "application/pidf+xml"
877 o [XMPP-CORE] for "application/xmpp+xml"
879 Although the "application/xmpp+xml" media type is specified in this
880 document, the element is simply a wrapper for a ,
881 , or stanza, where the semantics of those stanza
882 types are specified in [XMPP-CORE].
884 Given that the 'urn:ietf:params:xml:ns:xmpp-e2e' namespace has no
885 inherent semantics and specifies a using protocol only, versioning is
886 the responsibility of the protocols that define the encapsulated
887 objects ([MSGFMT], [PIDF], and [XMPP-CORE]).
889 10. application/xmpp+xml Media Type
891 The "application/xmpp+xml" media type adheres to the guidelines
892 specified in [XML-MEDIA]. The root element for this MIME type is
893 , and the root element MUST contain one and only one child
894 element, corresponding to one of the XMPP stanza types (i.e.,
895 message, presence, or iq) if the default namespace is 'jabber:client'
896 or 'jabber:server' as defined in [XMPP-CORE]. The character encoding
897 for this XML media type MUST be UTF-8, in accordance with Section
898 11.5 of [XMPP-CORE].
900 11. Security Considerations
902 This entire memo discusses security. Detailed security
903 considerations for instant messaging and presence protocols are given
904 in [IMP-REQS] (Sections 5.1 through 5.4), and for XMPP in particular
905 are given in [XMPP-CORE] (Sections 12.1 through 12.6). In addition,
906 all of the security considerations specified in [XML-MEDIA] apply to
907 the "application/xmpp+xml" media type.
909 The end-to-end security method defined here MAY result in exchanging
910 secured instant messages and presence information through a gateway
911 that implements the CPIM specifications. Such a gateway MUST be
912 compliant with the minimum security requirements of the instant
913 messaging and presence protocols with which it interfaces.
915 12. IANA Considerations
917 12.1 XML Namespace Name for e2e Data in XMPP
919 A URN sub-namespace for signed and encrypted content in the
920 Extensible Messaging and Presence Protocol (XMPP) is defined as
921 follows. (This namespace name adheres to the format defined in
922 [XML-REG].)
923 URI: urn:ietf:params:xml:ns:xmpp-e2e
924 Specification: XXXX
925 Description: This is the XML namespace name for signed and encrypted
926 content in the Extensible Messaging and Presence Protocol as
927 defined by XXXX.
928 Registrant Contact: IESG,
930 12.2 Content-type Registration for "application/xmpp+xml"
932 To: ietf-types@iana.org
934 Subject: Registration of MIME media type application/xmpp+xml
936 MIME media type name: application
937 MIME subtype name: xmpp+xml
938 Required parameters: (none)
939 Optional parameters: (charset) Same as charset parameter of
940 application/xml as specified in RFC 3023; per Section 11.5 of
941 [draft-ietf-xmpp-core-24], the charset must be UTF-8.
942 Encoding considerations: Same as encoding considerations of
943 application/xml as specified in RFC 3023; per Section 11.5 of
944 [draft-ietf-xmpp-core-24], the encoding must be UTF-8.
945 Security considerations: All of the security considerations specified
946 in RFC 3023 and [draft-ietf-xmpp-core-24] apply to this XML media
947 type. Refer to Section 11 of XXXX.
948 Interoperability considerations: (none)
949 Specification: XXXX
950 Applications which use this media type: XMPP-compliant instant
951 messaging and presence systems.
952 Additional information: (none)
953 Person and email address to contact for further information: IESG,
954
955 Intended usage: COMMON
956 Author/Change controller: IETF, XMPP Working Group
958 13. References
960 13.1 Normative References
962 [CERT] Ramsdell, B., "S/MIME Version 3.1 Certificate Handling",
963 draft-ietf-smime-rfc2632bis-07 (work in progress), June
964 2004.
966 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)",
967 draft-ietf-smime-rfc3369bis-04 (work in progress), May
968 2004.
970 [CMS-AES] Schaad, J., "Use of the Advanced Encryption Standard (AES)
971 Encryption Algorithm in Cryptographic Message Syntax
972 (CMS)", RFC 3565, July 2003.
974 [CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS)
975 Algorithms", RFC 3370, August 2002.
977 [CPIM] Peterson, J., "Common Profile for Instant Messaging
978 (CPIM)", draft-ietf-impp-im-04 (work in progress),
979 February 2004.
981 [CPP] Peterson, J., "Common Profile for Presence (CPP)",
982 draft-ietf-impp-pres-04 (work in progress), February 2004.
984 [DATETIME]
985 Klyne, G. and C. Newman, "Date and Time on the Internet:
986 Timestamps", RFC 3339, July 2002.
988 [DISP] Troost, R., Dorner, S. and K. Moore, "Communicating
989 Presentation Information in Internet Messages: The
990 Content-Disposition Header Field", RFC 2183, August 1997.
992 [IMP-MODEL]
993 Day, M., Rosenberg, J. and H. Sugano, "A Model for
994 Presence and Instant Messaging", RFC 2778, February 2000,
995 .
997 [IMP-REQS]
998 Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging /
999 Presence Protocol Requirements", RFC 2779, February 2000.
1001 [MSGFMT] Atkins, D. and G. Klyne, "Common Presence and Instant
1002 Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-08
1003 (work in progress), January 2003.
1005 [MULTI] Galvin, J., Murphy, S., Crocker, S. and N. Freed,
1006 "Security Multiparts for MIME: Multipart/Signed and
1007 Multipart/Encrypted", RFC 1847, October 1995.
1009 [PIDF] Fujimoto, S., Sugano, H., Klyne, G., Bateman, A., Carr, W.
1010 and J. Peterson, "Presence Information Data Format",
1011 draft-ietf-impp-cpim-pidf-08 (work in progress), May 2003.
1013 [SMIME] Ramsdell, B., "S/MIME Version 3.1 Message Specification",
1014 draft-ietf-smime-rfc2633bis-09 (work in progress), April
1015 2004.
1017 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate
1018 Requirement Levels", BCP 14, RFC 2119, March 1997.
1020 [X509] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
1021 X.509 Public Key Infrastructure Certificate and
1022 Certificate Revocation List (CRL) Profile", RFC 3280,
1023 April 2002.
1025 [XML-MEDIA]
1026 Murata, M., St. Laurent, S. and D. Kohn, "XML Media
1027 Types", RFC 3023, January 2001.
1029 [XMPP-CORE]
1030 Saint-Andre, P., "XMPP Core", draft-ietf-xmpp-core-24
1031 (work in progress), May 2004.
1033 [XMPP-IM] Saint-Andre, P., "XMPP Instant Messaging",
1034 draft-ietf-xmpp-im-22 (work in progress), May 2004.
1036 13.2 Informative References
1038 [CAPS] Hildebrand, J. and P. Saint-Andre, "JEP-0115: Entity
1039 Capabilities", April 2004,
1040 .
1042 [CMC] Myers, M., Liu, X., Schaad, J. and J. Weinstein,
1043 "Certificate Management Messages over CMS", RFC 2797,
1044 April 2000.
1046 [CMP] Adams, C. and S. Farrell, "Internet X.509 Public Key
1047 Infrastructure Certificate Management Protocols", RFC
1048 2510, March 1999.
1050 [DISCO] Hildebrand, J., Millard, P., Eatmon, R. and P.
1051 Saint-Andre, "JEP-0030: Service Discovery", June 2004,
1052 .
1054 [MUC] Saint-Andre, P., "JEP-0045: Multi-User Chat", June 2004,
1055 .
1057 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
1058 "Extensible Markup Language (XML) 1.0 (3rd ed)", W3C
1059 REC-xml, February 2004, .
1061 [XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1062 January 2004.
1064 [XMPP-CPIM]
1065 Saint-Andre, P., "Mapping the Extensible Messaging and
1066 Presence Protocol (XMPP) to Common Presence and Instant
1067 Messaging (CPIM)", draft-ietf-xmpp-cpim-05 (work in
1068 progress), May 2004.
1070 Author's Address
1072 Peter Saint-Andre
1073 Jabber Software Foundation
1075 EMail: stpeter@jabber.org
1077 Appendix A. Schema for urn:ietf:params:xml:ns:xmpp-e2e
1079 The following XML schema is descriptive, not normative.
1081
1083
1089
1091
1092
1093
1095
1096
1097
1098
1099
1101
1103 Appendix B. Revision History
1105 Note to RFC Editor: please remove this entire appendix, and the
1106 corresponding entries in the table of contents, prior to publication.
1108 B.1 Changes from draft-ietf-xmpp-e2e-08
1110 o Changed title to mention signing in addition to encryption.
1111 o Specified several functionality areas that are out of scope for
1112 this memo.
1114 o Added clarifying text to the examples, split several examples in
1115 order to correspond to the defined process steps, and added
1116 examples for encrypting both messages and presence information.
1117 o Changed SHOULD to MUST regarding checking of XMPP addresses.
1118 o Changed "could" to SHOULD regarding sending of initial message
1119 requesting certificate retrieval.
1120 o Specified that 'from' attributes MUST (rather than SHOULD) match a
1121 JID contained in the sender's certificate, and that resource
1122 identifiers SHOULD be ignored for matching purposes.
1123 o More fully defined S/MIME handling, including correct processing
1124 of XML stanzas with invalid signatures, stanzas that cannot be
1125 decrypted, and messages that appear to be replayed.
1126 o Defined recipient generation of XMPP error stanzas.
1127 o Incorporated text for "Mandatory-to-Implement Cryptographic
1128 Algorithms" suggested by Russ Housley.
1129 o Referred to Section 5.1.1 of XMPP-CORE regarding ASN.1 Object
1130 Identifier to be used when an XMPP address is represented in a
1131 certificate.
1132 o Added reference to RFC 3565.
1133 o Fixed CMC reference to point to RFC 2797.
1134 o Updated references to point to rfc2632bis, rfc2633bis, and
1135 rfc3369bis.
1136 o Updated boilerplate to refer to RFC 3668.
1137 o Removed Discussion Venue subsection.
1139 B.2 Changes from draft-ietf-xmpp-e2e-07
1141 o Clarified relationship of the 'urn:ietf:params:xml:ns:xmpp-e2e'
1142 namespace to its encapsulated objects, including versioning, and
1143 placed this content in its own section.
1144 o Clarified nature of "application/xmpp+xml" media type and placed
1145 this content in its own section.
1146 o Added reference to RFC 3023 and modified XML media type
1147 registration to adhere to the guidelines specified therein.
1148 o Changed XML params registrant to IESG, per RFC 3688.
1149 o Updated other references.
1151 B.3 Changes from draft-ietf-xmpp-e2e-06
1153 o Specified use of SHA-1 for digest and AES for content encryption.
1154 o Specified order of signing then encrypting.
1155 o Specified format and checking of timestamps.
1156 o Clarified use of subjectAltName field, where the GeneralName
1157 content is a URI of the form im:user@host and pres:user@host.
1158 o Clarified circumstances under which certificates should be
1159 attached.
1160 o Added Content-Disposition header field to examples.
1162 B.4 Changes from draft-ietf-xmpp-e2e-05
1164 o Addressed I-D nits and RFC Editor formatting.
1166 B.5 Changes from draft-ietf-xmpp-e2e-04
1168 o Added text about instant inbox addresses.
1170 B.6 Changes from draft-ietf-xmpp-e2e-03
1172 o Specified that S/MIME multipart objects are enclosed in a CDATA
1173 section.
1174 o Changed "text/xml" to "text/plain" for message examples.
1175 o Specified must-implement technologies, transfer encodings,
1176 certificate enrollment, certificate retrieval, and certificate
1177 names (including subjectAltName for JIDs).
1178 o Specified requirements regarding attachment of signatures and
1179 inclusion of certificates.
1180 o Fixed some small terminological errors.
1182 B.7 Changes from draft-ietf-xmpp-e2e-02
1184 o Completely revised to use formats defined in the CPIM
1185 specifications, S/MIME only, etc.
1187 B.8 Changes from draft-ietf-xmpp-e2e-01
1189 o Removed old Section 6 (Signalling Support via Presence) -- the
1190 ability to sign broadcasted presence made it redundant.
1191 o Made small editorial changes to address RFC Editor requirements.
1193 B.9 Changes from draft-ietf-xmpp-e2e-00
1195 o Added support for all stanza types.
1196 o Specified that the full stanza is encrypted.
1197 o Added support for S/MIME in addition to OpenPGP.
1198 o Specified that encrypted presence must be directed to a specific
1199 recipient.
1200 o Specified order of encrypting and signing.
1201 o Added support for signing broadcasted presence.
1202 o Added IANA considerations.
1203 o Changed namespace to 'urn:ietf:params:xml:ns:xmpp-e2e'.
1204 o Added XML schema.
1206 Intellectual Property Statement
1208 The IETF takes no position regarding the validity or scope of any
1209 Intellectual Property Rights or other rights that might be claimed to
1210 pertain to the implementation or use of the technology described in
1211 this document or the extent to which any license under such rights
1212 might or might not be available; nor does it represent that it has
1213 made any independent effort to identify any such rights. Information
1214 on the procedures with respect to rights in RFC documents can be
1215 found in BCP 78 and BCP 79.
1217 Copies of IPR disclosures made to the IETF Secretariat and any
1218 assurances of licenses to be made available, or the result of an
1219 attempt made to obtain a general license or permission for the use of
1220 such proprietary rights by implementers or users of this
1221 specification can be obtained from the IETF on-line IPR repository at
1222 http://www.ietf.org/ipr.
1224 The IETF invites any interested party to bring to its attention any
1225 copyrights, patents or patent applications, or other proprietary
1226 rights that may cover technology that may be required to implement
1227 this standard. Please address the information to the IETF at
1228 ietf-ipr@ietf.org.
1230 Disclaimer of Validity
1232 This document and the information contained herein are provided on an
1233 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1234 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1235 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1236 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1237 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1238 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1240 Copyright Statement
1242 Copyright (C) The Internet Society (2004). This document is subject
1243 to the rights, licenses and restrictions contained in BCP 78, and
1244 except as set forth therein, the authors retain all their rights.
1246 Acknowledgment
1248 Funding for the RFC Editor function is currently provided by the
1249 Internet Society.