idnits 2.17.1 draft-ietf-smime-bfibecms-05.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 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 581. 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 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 193 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (August 2007) is 6100 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) == Missing Reference: 'BF' is mentioned on line 71, but not defined == Missing Reference: 'BB1' is mentioned on line 72, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' ** Obsolete normative reference: RFC 3369 (ref. 'CMS') (Obsoleted by RFC 3852) -- Possible downref: Non-RFC (?) normative reference: ref. 'DER' -- No information found for draft-ieft-martin-ibcs - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IBCS' -- No information found for draft-ietf-ibearch - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IBE' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Informational RFC: RFC 3882 ** Obsolete normative reference: RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L. Martin 3 S/MIME Working Group Voltage Security 4 Internet Draft Mark Schertler 5 Expires: February 2008 Tumbleweed Communications 6 August 2007 8 Using the Boneh-Franklin and Boneh-Boyen identity-based encryption 9 algorithms with the Cryptographic Message Syntax (CMS) 11 13 Status of this Document 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Abstract 38 This document describes the conventions for using the Boneh-Franklin 39 (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in 40 the Cryptographic Message Syntax (CMS) to encrypt content-encryption 41 keys. Object identifiers and the convention for encoding a 42 recipient's identity are also defined. 44 Table of Contents 46 1. Introduction...................................................2 47 1.1. Terminology...............................................3 48 1.2. IBE overview..............................................3 49 2. Using identity-based encryption................................3 50 3. Key encryption algorithm identifiers...........................6 51 4. Processing by the sender.......................................7 52 5. Processing by the receiver.....................................7 53 6. ASN.1 module...................................................9 54 7. Security considerations.......................................10 55 7.1. Attacks that are outside the scope of this document......10 56 7.2. Attacks that are within the scope of this document.......11 57 7.3. Attacks to which the protocols defined in this document are 58 susceptible...................................................11 59 8. IANA considerations...........................................12 60 9. References....................................................13 61 9.1. Normative references.....................................13 62 9.2. Informative references...................................13 63 Authors' Addresses...............................................14 64 Intellectual property statement..................................14 65 Disclaimer of validity...........................................15 66 Copyright statement..............................................15 67 Acknowledgment...................................................15 69 1. Introduction 71 This document defines the way to use the Boneh-Franklin [BF] and 72 Boneh-Boyen [BB1] identity-based encryption (IBE) public-key 73 algorithms in the Cryptographic Message Syntax (CMS) [CMS]. IBE is a 74 public key technology for encrypting content-encryption keys (CEKs) 75 that can be implemented within the framework of the CMS: the 76 recipient's identity is incorporated into the EnvelopedData CMS 77 content type using the OtherRecipientInfo CHOICE in the RecipientInfo 78 field as defined in section 6.2.5 of [CMS]. This document does not 79 describe the implementation of the BF and BB1 algorithms, which are 80 described in detail in [IBCS]. 82 IBE algorithms are a type of public-key cryptographic algorithm in 83 which the public key is calculated directly from a user's identity 84 instead of being generated randomly. This requires a different set of 85 steps for encryption and decryption than would be used with other 86 public-key algorithms, and these steps are defined in Sections 4 and 87 5 of this document respectively. 89 This document also defines the object identifiers and syntax of the 90 object that is used to define the identity of a message recipient. 92 CMS values and identity objects are defined using ASN.1 [ASN1]. 94 1.1. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 100 1.2. IBE overview 102 In addition to the client components that are described in this 103 document, the following additional components are required for a 104 complete IBE messaging system: 106 o A Private-key Generator (PKG). The PKG contains the 107 cryptographic material, known as a master secret, for 108 generating an individual's IBE private key. A PKG accepts an 109 IBE user's private key request and, after successfully 110 authenticating them in some way, returns their IBE private 111 key. 113 o A Public Parameter Server (PPS). IBE System Parameters 114 include publicly sharable cryptographic material, known as 115 IBE public parameters, and policy information for the PKG. A 116 PPS provides a well-known location for secure distribution 117 of IBE public parameters and policy information for the IBE 118 PKG. 120 The interaction of senders and receivers of IBE-encrypted messages 121 are described in [IBE]. 123 2. Using identity-based encryption 125 To use IBE, the ori field in RecipientInfo MUST be used. The fields 126 are set as follows: oriType is set to ibeORIType; oriValue is set to 127 ibeORIValue. 129 These fields have the following meanings: 131 ibeORIType defines the object identifier (OID) that indicates that 132 the subsequent ibeORIValue is the information necessary to decrypt 133 the message using IBE. This field MUST be set to 134 ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 135 us(840) organization(1) identicrypt(114334) ibcs(1) 136 cms(4) ori-oid(1) } 138 ibeORIValue defines the identity that was used in the IBE algorithm 139 to encrypt the CEK. This is an IBERecipientInfo type. 141 IBERecipientInfo ::= SEQUENCE { 142 cmsVersion INTEGER { v3(3) }, 143 keyFetchMethod OBJECT IDENTIFIER, 144 recipientIdentity IBEIdentityInfo, 145 serverInfo SEQUENCE SIZE (1..MAX) OF 146 OIDValuePairs OPTIONAL, 147 encryptedKey EncryptedKey 148 } 150 The fields of IBERecipientInfo have the following meanings: 152 The cmsVersion MUST be set to 3. 154 The keyFetchMethod is the OID that defines the method of retrieving 155 the private key that the recipient MUST use. How to retrieve an IBE 156 private key using the steps defined in [IBE] is defined by the 157 keyFetchMethod OID. The method for retrieving private keys that is 158 specified in [IBE] is defined by cmsPPSOID. 160 cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 161 us(840) organization(1) identicrypt(114334) pps-schemas(3) 162 ic-schemas(1) pps-uri(1) 163 } 165 The recipientIdentity is the data that was used to calculate the IBE 166 public key that was used to encrypt the content-encryption key. This 167 MUST be an IBEIdentityInfo type. This recipientIdentity is used to 168 calculate IBE public and private keys as described in [IBCS]. 170 IBEIdentityInfo ::= SEQUENCE { 171 district IA5String, 172 serial INTEGER, 173 identitySchema OBJECT IDENTIFIER, 174 identityData OCTET STRING 175 } 177 The fields of IBEIdentityInfo have the following meanings. 179 The district and serial are unique identifiers that are used to 180 construct the URI for the location of the necessary IBE public 181 parameters. The construction and use of this URI is defined in [IBE]. 183 The identitySchema defines the format that is used to encode the 184 information that defines the identity of the recipient. This MUST be 185 set to cmsIdentityOID to indicate that identityData contains an 186 EmailIdentitySchema type. 188 cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 189 us(840) organization(1) identicrypt(114334) keyschemas(2) 190 icschemas(1) rfc822email(1) 191 } 193 The identityData field contains the identify information for the 194 recipient. If the contents of the field is an ASN.1 structure, the 195 structure MUST be DER encoded [DER] before placing it in the OCTET 196 STRING. 198 EmailIdentitySchema ::= SEQUENCE { 199 rfc822Email IA5String, 200 time GeneralizedTime 201 } 203 The rfc822Email is the e-mail address of the recipient in the format 204 defined by [RFC822]. E-mail addresses that contain non-ASCII 205 characters MUST be encoded using punycode [RFC3492]. 207 The value of "time" is the UTC time after which the sender wants to 208 let the recipient decrypt the message, so it may be called the "not- 209 before" time. This is usually set to the time when the message is 210 encrypted, but MAY be set to a future time. UTC time values are 211 expressed to the nearest second. 213 The sender of an IBE-encrypted message may want to express this time 214 rounded to a time interval to create a key lifetime. A key lifetime 215 reduces the number of IBE private keys that a recipient needs to 216 retrieve, but still forces the IBE user to periodically re- 217 authenticate. Based on the time interval chosen a recipient would 218 only have to retrieve a new IBE key once during the interval. To do 219 this, follow the following steps. Let "time-interval" be the number 220 of seconds in this larger time interval. 222 1. Find the GeneralizedTime for the not-before value. 223 2. Convert this GeneralizedTime into the number of seconds 224 since January 1, 1970. Call this "total-time." 225 3. Calculate reduced-time = (floor (total-time / 226 time-interval)) * time-interval. 227 4. Convert reduced-time to a GeneralizedTime to get the 228 not-before "time" value. 230 An example of this algorithm for computing a one week time interval 231 is as follows. 233 1. Say the GeneralizedTime is 20020401000000Z. 234 2. Then the total-time is 1017612000. 235 3. A time-interval of 1 week is 604800 seconds. 236 So the reduced-time = (floor(1017612000/604800))* 237 604800 = 1017273600. 238 4. This gives the reduced-time GeneralizedTime form of the 239 reduced-time of 20020328000000Z. 241 When issuing IBE private keys, a PKG SHOULD NOT issue them too far 242 into the future. This restriction is to prevent an adversary who 243 obtains an IBE user's authentication credentials from requesting 244 private keys far into the future and therefore negating the periodic 245 IBE user re-authentication that key lifetime provides. For example if 246 a one week period is chosen for the key lifetime, then IBE private 247 keys should not be issued more than 1 week in advance. Otherwise once 248 an adversary gains access to the PKG via the stolen IBE user 249 credentials they can request all future keys and negate the IBE user 250 authentication restraints in place. 252 The serverInfo is an optional series of OID-value pairs that can be 253 used to convey any other information that might be used by a PKG. 254 Examples of such information could include the user interface that 255 the recipient will experience. Differences in the user interface 256 could include localization information or commercial branding 257 information. 259 The encryptedKey is the result of encrypting the CEK with an IBE 260 algorithm using recipientIdentity as the IBE public key. 262 3. Key encryption algorithm identifiers 264 The BF and BB1 algorithms as defined in [IBCS] have the following 265 object identifiers. These object identifiers are also defined in the 266 ASN.1 module in [IBCS]. 268 bf OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) 269 organization(1) identicrypt(114334) ibcs(1) ibcs1(1) 270 ibe-algorithms(2) bf(1) } 272 This is the object identifier that MUST be inserted in the 273 keyEncryptionAlgorithm field in the CMS when the BF algorithm is used 274 to encrypt the CEK. 276 bb1 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) 277 organization(1) identicrypt(114334) ibcs(1) ibcs1(1) 278 ibe-algorithms(2) bb1(2) } 280 This is the object identifier that MUST be inserted in the 281 keyEncryptionAlgorithm field in the CMS when the BB1 algorithm is 282 used to encrypt the CEK. 284 4. Processing by the sender 286 The sender of a message that uses IBE to encrypt content-encryption 287 keys performs the following steps: 289 1. Selects a set of IBE public parameters to use in the subsequent 290 steps in accordance with his local security policy. He then 291 determines the URI where the public parameters can be obtained using 292 the process described in [IBE]. This information MUST be encoded in 293 the IBEIdentityInfo as described in Section 2. 295 2. Sets the fields of an OtherRecipientInfo object to their 296 appropriate values as described in Section 2. 298 3. Calculates an IBE public key as defined in [IBCS] using this 299 IBEIdentityInfo as the identity information. 301 4. This IBE public key is then used to encrypt the content- 302 encryption key (CEK), using the algorithms that are defined in 303 [IBCS]. 305 5. Sets encryptedKey to the IBE-encrypted CEK. 307 6. Within the CMS, keyEncryptionAlgorithm MUST then be set to the 308 appropriate OID for the IBE algorithm that was used (see Section 3). 310 5. Processing by the receiver 312 Upon receiving a message that has a CEK encrypted with IBE, the 313 recipient performs the following steps to decrypt the CEK: 315 1. Determines that the CEK is IBE-encrypted by noting that the 316 oriType of the OtherRecipientInfo type is set to ibeORIType. 318 2. Determines that the recipientIdentity was used as the identity 319 in IBE encryption of the CEK. 321 3. Determines the location of the IBE public parameters and the 322 IBE Private Key Generator as described in [IBE]. 324 4. Obtains the IBE public parameters from the location determined 325 in Step 3 using the process defined in [IBE]. 327 5. Obtains the IBE private key needed to decrypt the encrypted CEK 328 using the process defined in [IBE]. 330 6. Decrypts the CEK using the IBE private key obtained in Step 4 331 using the algorithms described in [IBCS]. 333 6. ASN.1 module 335 IBECMS-module { joint-iso-itu-t(2) country(16) us(840) 336 organization(1) identicrypt(114334) ibcs(1) cms(4) 337 module(5) version(1) 338 } 340 DEFINITIONS IMPLICIT TAGS ::= BEGIN 342 IBEOtherRecipientInfo ::= SEQUENCE { 343 oriType OBJECT IDENTIFIER, 344 oriValue IBERecipientInfo 345 } 347 ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 348 us(840) organization(1) identicrypt(114334) ibcs(1) 349 cms(4) ori-oid(1) 350 } 352 IBERecipientInfo ::= SEQUENCE { 353 cmsVersion INTEGER { v3(3) }, 354 keyFetchMethod OBJECT IDENTIFIER, 355 recipientIdentity IBEIdentityInfo, 356 serverInfo SEQUENCE SIZE (1..MAX) OF 357 OIDValuePairs OPTIONAL, 358 encryptedKey EncryptedKey 359 } 361 IBEIdentityInfo ::= SEQUENCE { 362 district IA5String, 363 serial INTEGER, 364 identitySchema OBJECT IDENTIFIER, 365 identityData OCTET STRING 366 } 368 OIDValuePairs ::= SEQUENCE { 369 fieldID OBJECT IDENTIFIER, 370 fieldData OCTET STRING 371 } 373 EncryptedKey ::= OCTET STRING 375 EmailIdentitySchema ::= SEQUENCE { 376 rfc822Email IA5String, 377 time GeneralizedTime 378 } 379 cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 380 us(840) organization(1) identicrypt(114334) keyschemas(2) 381 icschemas(1) rfc822email(1) 382 } 384 cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) 385 us(840) organization(1) identicrypt(114334) pps-schemas(3) 386 ic-schemas(1) pps-uri(1) 387 } 389 END 391 7. Security considerations 393 This document is based on [CMS] and [IBCS], and the relevant security 394 considerations of those documents apply. 396 7.1. Attacks that are outside the scope of this document 398 Attacks on the cryptographic algorithms that are used to implement 399 IBE are outside the scope of this document. Such attacks are detailed 400 in [IBCS], which defines parameters that give 80-bit, 112-bit, 128- 401 bit and 256-bit encryption strength. We assume that capable 402 administrators of an IBE system will select parameters that provide a 403 sufficient resistance to cryptanalytic attacks by adversaries. 405 Attacks that give an adversary the ability to access or change the 406 information on a PPS or PKG, especially the cryptographic material 407 (referred to in this document as the master secret), will defeat the 408 security of an IBE system. In particular, if the cryptographic 409 material is compromised the adversary will have the ability to 410 recreate any user's private key and therefore decrypt all messages 411 protected with the corresponding public key. To address this concern, 412 it is highly RECOMMENDED that best practices for physical and 413 operational security for PPS and PKG servers be followed and that 414 these servers be configured (sometimes known as hardened) in 415 accordance with best current practices [NIST]. An IBE system SHOULD 416 be operated in an environment where illicit access to the PPS and PKG 417 is infeasible for attackers to obtain. 419 Attacks that require administrative or IBE user equivalent access to 420 machines used by either the client or the server components defined 421 in this document are also outside the scope of this document. 423 We also assume that all administrators of a system implementing the 424 protocols that are defined in this document are trustworthy and will 425 not abuse their authority to bypass the security provided by an IBE 426 system. This is of particular importance with an IBE system, for an 427 administrator of a PKG could potentially abuse his authority and 428 configure the PKG to grant him any IBE private key that the PKG is 429 capable of calculating. To minimize the possibility of administrators 430 doing this, a system implementing IBE SHOULD implement n-out-of-m 431 control for critical administrative functions and SHOULD maintain 432 auditable logs of all security-critical events that occur in an 433 operating IBE system. 435 Similarly, we assume that users of an IBE system will behave 436 responsibly, not sharing their authentication credentials with 437 others. Thus attacks that require such assumptions are outside the 438 scope of this document. 440 7.2. Attacks that are within the scope of this document 442 Attacks within the scope of this document are those that allow an 443 adversary to: 445 o passively monitor information transmitted between users of 446 an IBE system and the PPS and PKG 448 o masquerade as a PPS or PKG 450 o perform a DOS attack on a PPS or PKG 452 o easily guess an IBE user's authentication credential 454 7.3. Attacks to which the protocols defined in this document are 455 susceptible 457 All communications between users of an IBE system and the PPS or PKG 458 are protected using TLS [TLS]. The IBE system defined in this 459 document provides no additional security for the communications 460 between IBE users and the PPS or PKG. Therefore the described IBE 461 system is completely dependent on the TLS security mechanisms for 462 authentication of the PKG or PPS server and for confidentiality and 463 integrity of the communications. Should there be a compromise of the 464 TLS security mechanisms, the integrity of all communications between 465 an IBE user and the PPS or PKG will be suspect. 467 The protocols defined in this document do not explicitly defend 468 against an attacker masquerading as a legitimate IBE PPS or PKG. The 469 protocols rely on the server authentication mechanism of TLS [TLS]. 470 In addition to the TLS server authentication mechanism IBE client 471 software can provide protection against this possibility by providing 472 user interface capabilities that allows users to visually determine 473 that a connection to PPS and PKG servers is legitimate. This 474 additional capability can help ensure that users cannot easily be 475 tricked into providing valid authorization credentials to an 476 attacker. 478 The protocols defined in this document are also vulnerable to attacks 479 against an IBE PPS or PKG. Denial of service attacks against either 480 component can result in users unable to encrypt or decrypt using IBE, 481 and users of an IBE system SHOULD take the appropriate 482 countermeasures [RFC2827, RFC3882] that their use of IBE requires. 484 The IBE user authentication method used by an IBE PKG SHOULD be of 485 sufficient strength to prevent attackers from easily guessing the IBE 486 user's authentication credentials through trial and error. 488 8. IANA considerations 490 All of the object identifiers used in this document were assigned by 491 the National Institute of Standards and Technology (NIST), so no 492 further action by the IANA is necessary for this document. 494 9. References 496 9.1. Normative references 498 [ASN1] CCITT, "Recommendation X.209: Specification of Basic Encoding 499 Rules for Abstract Syntax Notation One (ASN.1)," 1998. 501 [CMS] R. Housley, "Cryptographic Message Syntax," RFC 3369, August 502 2002. 504 [DER] ITU-T Recommendation X.680: Information Technology - Abstract 505 Syntax Notation One, 1997. 507 [IBCS] X. Boyen, L. Martin, "Identity-based Cryptography Standard 508 (IBCS) #1: Supersingular Curve Implementations of the BF 509 and BB1 Cryptosystems," draft-ieft-martin-ibcs-03.txt. 511 [IBE] G. Appenzeller, L. Martin and M. Schertler, "Identity-based 512 Encryption Architecture," draft-ietf-ibearch-01.txt. 514 [KEYWORDS] S. Brander, "Key Words for Use in RFCs to Indicate 515 Requirement Levels," BCP 14, RFC 2119, March 1997. 517 [RFC822] D. Crocker, "Standard for the format of ARPA internet text 518 messages," RFC 822, August 1982. 520 [RFC2827] P. Ferguson and D. Senie, "Network Ingress Filtering: 521 Defeating Denial of Service Attacks which employ IP Source 522 Address Spoofing," RFC 2827, BCP 38, May 2000. 524 [RFC3492] A. Costello, "Punycode: A Bootstring encoding of Unicode 525 for Internationalized Domain Names in Applications (IDNA)," 526 RFC 3492, March 2003. 528 [RFC3882] D. Turk, "Configuring BGP to Block Denial-of-Service 529 Attacks," RFC 3882, September 2004. 531 [TLS] T. Dierks and E. Rescorla, "The Transport Layer Security (TLS) 532 Protocol Version 1.1," RFC 4346, April 2006. 534 9.2. Informative references 536 [NIST] M. Souppaya, J. Wack and K. Kent, "Security Configuration 537 Checklist Program for IT Products - Guidance for Checklist 538 Users and Developers," NIST Special Publication SP 800-70, 539 May 2005. 541 Authors' Addresses 543 Luther Martin 544 Voltage Security 545 1070 Arastradero Rd Suite 100 546 Palo Alto CA 94304 548 Phone: +1 650 543 1280 549 Email: martin@voltage.com 551 Mark Schertler 552 Tumbleweed Communications 553 700 Saginaw Dr 554 Redwood City CA 94063 556 Phone: +1 650 216 2039 557 Email: mark.schertler@tumbleweed.com 559 Intellectual property statement 561 The IETF takes no position regarding the validity or scope of any 562 Intellectual Property Rights or other rights that might be claimed to 563 pertain to the implementation or use of the technology described in 564 this document or the extent to which any license under such rights 565 might or might not be available; nor does it represent that it has 566 made any independent effort to identify any such rights. Information 567 on the procedures with respect to rights in RFC documents can be 568 found in BCP 78 and BCP 79. 570 Copies of IPR disclosures made to the IETF Secretariat and any 571 assurances of licenses to be made available, or the result of an 572 attempt made to obtain a general license or permission for the use of 573 such proprietary rights by implementers or users of this 574 specification can be obtained from the IETF on-line IPR repository at 575 http://www.ietf.org/ipr. 577 The IETF invites any interested party to bring to its attention any 578 copyrights, patents or patent applications, or other proprietary 579 rights that may cover technology that may be required to implement 580 this standard. Please address the information to the IETF at 581 ietf-ipr@ietf.org. 583 Disclaimer of validity 585 This document and the information contained herein are provided on an 586 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 587 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 588 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 589 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 590 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 591 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 593 Copyright statement 595 Copyright (C) The IETF Trust (2007). 597 This document is subject to the rights, licenses and restrictions 598 contained in BCP 78, and except as set forth therein, the authors 599 retain all their rights. 601 Acknowledgment 603 Funding for the RFC Editor function is currently provided by the 604 Internet Society.