idnits 2.17.1 draft-ietf-smime-password-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 530 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 96: '... [0] KeyDerivationAlgorithmIdentifier OPTIONAL,...' RFC 2119 keyword, line 142: '...CMS implementations MUST include PBKDF2 [PKCS5v2]....' RFC 2119 keyword, line 151: '... implementations MUST include Triple-D...' RFC 2119 keyword, line 152: '...in CBC mode, and MAY include other alg...' RFC 2119 keyword, line 154: '...implementations SHOULD NOT include any...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (September 2000) is 8622 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 section? 'RFC2640' on line 46 looks like a reference -- Missing reference section? 'ASN1' on line 48 looks like a reference -- Missing reference section? 'RFC2119' on line 53 looks like a reference -- Missing reference section? '1' on line 69 looks like a reference -- Missing reference section? '2' on line 70 looks like a reference -- Missing reference section? '3' on line 402 looks like a reference -- Missing reference section? '0' on line 489 looks like a reference -- Missing reference section? 'PKCS5v2' on line 142 looks like a reference -- Missing reference section? 'PACKAGE' on line 176 looks like a reference -- Missing reference section? 'RFC2268' on line 286 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Editor: Peter Gutmann 2 draft-ietf-smime-password-02.txt University of Auckland 3 March 2, 2000 4 Expires September 2000 6 Password-based Encryption for S/MIME 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 The Cryptographic Message Syntax data format doesn't currently contain 31 any provisions for password-based data encryption. This document 32 provides a method of encrypting data using user-supplied passwords and, 33 by extension, any form of variable-length keying material which isn't 34 necessarily an algorithm-specific fixed-format key. 36 This draft is being discussed on the "ietf-smime" mailing list. To 37 join the list, send a message to with the 38 single word "subscribe" in the body of the message. Also, there is a 39 Web site for the mailing list at . 41 1. Introduction 43 This document describes a password-based content encryption mechanism 44 for S/MIME. This is implemented as a new RecipientInfo type and is an 45 extension to the RecipientInfo types currently defined in RFC 2640 46 [RFC2640]. 48 The format of the messages are described in ASN.1:1994 [ASN1]. 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 51 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 52 interpreted as described in [RFC2119]. 54 1.1 Password-based Content Encryption 56 CMS currently defined three recipient information types for public-key 57 key wrapping (KeyTransRecipientInfo), conventional key wrapping 58 (KEKRecipientInfo), and key agreement (KeyAgreeRecipientInfo). The 59 recipient information described here adds a fourth type, 60 PasswordRecipientInfo, which provides for password-based key wrapping. 62 1.2 RecipientInfo Types 64 The new recipient information type is an extension to the RecipientInfo 65 type defined in section 6.2 of CMS, extending the types to: 67 RecipientInfo ::= CHOICE { 68 ktri KeyTransRecipientInfo, 69 kari [1] KeyAgreeRecipientInfo, 70 kekri [2] KEKRecipientInfo, 71 pwri [3] PasswordRecipientinfo -- New RecipientInfo type 72 } 74 Although the recipient information generation process is described in 75 terms of a password-based operation (since this will be its most common 76 use), the transformation employed is a general-purpose key derivation 77 one which allows any type of keying material to be converted into a key 78 specific to a particular content-encryption algorithm. Since the most 79 common use for password-based encryption is to encrypt files which are 80 stored locally (rather than being transmitted across a network), the 81 term "recipient" is somewhat misleading, but is used here because the 82 other key transport mechanisms have always been described in similar 83 terms. 85 1.2.1 PasswordRecipientInfo Type 87 Recipient information using a user-supplied password or previously 88 agreed-upon key is represented in the type PasswordRecipientInfo. Each 89 instance of PasswordRecipientInfo will transfer the content-encryption 90 key (CEK) to one or more recipients who have the previously agreed-upon 91 password or key-encryption key (KEK). 93 PasswordRecipientInfo ::= SEQUENCE { 94 version CMSVersion, -- Always set to 0 95 keyDerivationAlgorithm 96 [0] KeyDerivationAlgorithmIdentifier OPTIONAL, 97 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 98 encryptedKey EncryptedKey } 100 The fields of type PasswordRecipientInfo have the following meanings: 102 version is the syntax version number. It shall always be 0. 104 keyDerivationAlgorithm identifies the key-derivation algorithm, and 105 any associated parameters, used to derive the KEK from the 106 user-supplied password. If this field is absent, the KEK is supplied 107 from an external source, for example a crypto token such as a smart 108 card. 110 keyEncryptionAlgorithm identifies the content-encryption algorithm, 111 and any associated parameters, used to encrypt the CEK with the KEK. 113 encryptedKey is the result of encrypting the content-encryption key 114 with the KEK. 116 1.2.2 Rationale 118 Password-based key wrapping is a two-stage process, a first stage in 119 which a user-supplied password is converted into a KEK if required, and 120 a second stage in which the KEK is used to encrypt a CEK. These two 121 stages are identified by the two algorithm identifiers. Although the 122 PKCS #5 standard goes one step further to wrap these up into a single 123 algorithm identifier, this design is particular to that standard and 124 may not be applicable for other key wrapping mechanisms. For this 125 reason the two steps are specified separately. 127 2 Supported Algorithms 129 This section lists the algorithms that must be implemented. Additional 130 algorithms that should be implemented are also included. 132 2.1 Key Derivation Algorithms 134 These algorithms are used to convert the password into a KEK. The key 135 derivation algorithms are: 137 KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= { 138 { SYNTAX PBKDF2-params IDENTIFIED BY id-PBKDF2 }, 139 ... 140 } 142 CMS implementations MUST include PBKDF2 [PKCS5v2]. 144 2.2 Key Encryption Algorithms 146 These algorithms are used to encrypt the content (the key) using the 147 derived KEK. The content encryption algorithms are: 149 KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs 151 CMS implementations MUST include Triple-DES in CBC mode, SHOULD include 152 RC2 in CBC mode, and MAY include other algorithms such as CAST-128, 153 RC5, IDEA, Skipjack, and encryption modes as required. CMS 154 implementations SHOULD NOT include any KSG ciphers such as RC4 or a 155 block cipher in OFB mode, and SHOULD NOT include a block cipher in ECB 156 mode. The use of RC2 has special requirements, see section 2.4 for 157 details. 159 2.3 Symmetric Key Encryption Algorithms 161 The key wrap algorithm is used to wrap the CEK with the KEK. There is 162 no requirement that the content-encryption algorithm match the KEK 163 algorithm, although care should be taken to ensure that, if different 164 algorithms are used, they offer an equivalent level of security (for 165 example wrapping a Triple-DES key with an RC2/40 key leads to a severe 166 impedance mismatch in encryption strength). 168 The key wrap algorithm specified below is independent of the 169 content-encryption or wrapping algorithms, relying only on the use of a 170 block cipher to perform the wrapping. 172 2.3.1 Key Wrap 174 The key wrap algorithm encrypts a CEK with a KEK in a manner which 175 ensures that every bit of plaintext effects every bit of ciphertext. 176 This makes it equivalent in function to the package transform [PACKAGE] 177 without requiring additional mechanisms or resources such as hash 178 functions or cryptographically strong random numbers. The key wrap 179 algorithm is performed in two phases, a first phase which formats the 180 CEK into a form suitable for encryption by the KEK, and a second phase 181 which wraps the formatted CEK using the KEK. 183 Key formatting: Create a formatted CEK block consisting of the 184 following: 186 1. A one-byte count of the number of bytes in the CEK. 188 2. A check value containing the bitwise complement of the first three 189 bytes of the CEK. 191 3. The CEK. 193 4. Enough random padding data to make the CEK data block at least two 194 KEK cipher blocks long (the fact that 32 bits of count+check value 195 are used means that even with a 40-bit CEK, the resulting data 196 size will always be at least two (64-bit) cipher blocks long). 197 The padding data does not have to be cryptographically strong, 198 although unpredictability helps. 200 The formatted CEK block then looks as follows: 202 CEK byte count || check value || CEK || padding (if required) 204 Key wrapping: 206 1. Encrypt the padded key using the KEK. 208 2. Without resetting the IV (that is, using the last ciphertext block 209 as the IV), encrypt the encrypted padded key a second time. 211 The resulting double-encrypted data is the EncryptedKey. 213 2.3.2 Key Unwrap 215 Key unwrapping: 217 1. Using the n-1'th ciphertext block as the IV, decrypt the n'th 218 ciphertext block. 220 2. Using the decrypted n'th ciphertext block as the IV, decrypt the 221 1st ... n-1'th ciphertext blocks. This strips the outer layer of 222 encryption. 224 3. Decrypt the inner layer of encryption using the KEK. 226 Key format verification: 228 1a.If the CEK byte count is less than the minimum allowed key size 229 (usually 5 bytes for 40-bit keys) or greater than the wrapped CEK 230 length or not valid for the CEK algorithm (eg not 16 or 24 bytes 231 for triple DES), the KEK was invalid. 232 1b.If the bitwise complement of the key check value doesn't match 233 the first three bytes of the key, the KEK was invalid. 235 2.3.3 Example 237 Given a content-encryption algorithm of Skipjack and a KEK algorithm of 238 Triple-DES, the wrap steps are as follows: 240 1. Set the first 4 bytes of the CEK block to the Skipjack key size 241 (10 bytes) and the bitwise complement of the first three bytes of 242 the CEK. 244 2. Append the 80-bit (10-byte) Skipjack CEK and pad the total to 16 245 bytes (two triple-DES blocks) using 2 bytes of random data. 247 2. Using the IV given in the KeyEncryptionAlgorithmIdentifer, 248 encrypted the padded Skipjack key. 250 3. Without resetting the IV, encrypt the encrypted padded key a 251 second time. 253 The unwrap steps are as follows: 255 1. Using the first 8 bytes of the double-encrypted key as the IV, 256 decrypt the second 8 bytes. 258 2. Without resetting the IV, decrypt the first 8 bytes. 260 3. Decrypt the inner layer of encryption using the the IV given in 261 the KeyEncryptionAlgorithmIdentifer to recover the padded Skipjack 262 key. 264 4. If the length byte isn't equal to the Skipjack key size (80 bits 265 or 10 bytes) or the bitwise complement of the check bytes doesn't 266 match the first three bytes of the CEK, the KEK was invalid. 268 2.3.4 Rationale for the Double Wrapping 270 If many CEK's are encrypted in a standard way with the same KEK and the 271 KEK has a 64-bit block size then after about 2^32 encryptions there is 272 a high probability of a collision between different blocks of encrypted 273 CEK's. If an opponent manages to obtain a CEK, they may be able to 274 solve for other CEK's. The double-encryption wrapping process, which 275 makes every bit of ciphertext dependent on every bit of the CEK, 276 eliminates this collision problem (as well as preventing other 277 potential problems such as bit-flipping attacks). Since the IV is 278 applied to the inner layer of encryption, even wrapping the same CEK 279 with the same KEK will result in a completely different wrapped key 280 each time. 282 2.4 Special Handling for RC2 Keys 284 For a variety of historical, political, and software-peculiarity 285 reasons which are beyond the scope of this document, the handling of 286 keys for the RC2 algorithm [RFC2268] by different implementations is 287 somewhat arbitrary. In particular, the choice of actual vs effective 288 key bits used in the algorithm is often unclear. The standard RC2 289 AlgorithmIdentifier only allows the effective key bits to be specified, 290 leaving the actual key bits to be communicated via out-of-band means, 291 which in some cases means hardcoding them into applications. Solving 292 this problem requires two things, a precise definition of how keys 293 represented with the standard RC2 AlgorithmIdentifier are handled, and 294 a new RC2 AlgorithmIdentifier which allows keys currently in use by 295 different applications to be handled. 297 2.4.1 Handling of RC2 with RFC 2268 AlgorithmIdentifier 299 RFC 2268 defines the following AlgorithmIdentifier for RC2: 301 rc2CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) US(840) 302 rsadsi(113549) encryptionAlgorithm(3) 2} 304 RC2-CBCParameter ::= CHOICE { 305 iv IV, 306 params SEQUENCE { 307 version INTEGER, 308 iv OCTET STRING 309 } 310 } 312 where the version field encodes the effective key size in a complex 313 manner specified in the RFC. Where this algorithm identifier is used, 314 the actual key size shall be the same size as the effective key size as 315 given by the version field. When RC2 is to be used, implementations 316 should use this AlgorithmIdentifier and parameters, and when this 317 AlgorithmIdentifier is used the actual key size MUST NOT be a value 318 other than the effective key size (to use a different size, see section 319 2.4.2). 321 2.4.2 Handling of RC2 with Other Key Sizes 323 If the use of an actual key size of other than the effective key size 324 is required, implementations MUST use the following 325 AlgorithmIdentifier: 327 rc2CBC OBJECT IDENTIFIER ::= {1 3 6 1 4 1 3029 666 13} 328 RC2-CBCParameter ::= SEQUENCE { 329 actualKeySize INTEGER, -- Actual key size in bits 330 effectiveKeySize INTEGER, -- Effective key size in bits 331 iv OCTET STRING 332 } 334 This allows arbitrary actual and effective key sizes to be specified 335 for compatibility with existing usage. Although implementations SHOULD 336 NOT use this alternative (using instead the one in section 2.4.1) 337 experience has shown that implementors will continue to use oddball RC2 338 parameters anyway, so new implementations should be prepared to 339 encounter and handle actual and effective key sizes ranging from 40 up 340 to around 200 bits. 342 2.4.3 Rationale 344 The reason for providing for the handling of oddball key sizes is 345 compatibility with existing applications, for example a mailing-list 346 exploder or mail gateway may take an RSA-wrapped CEK generated by a 347 current application and repackage it with a KEK, so we need a mechanism 348 for handling strange key lengths in a manner which is compatible with 349 existing usage. The alternative RC2 AlgorithmIdentifier, although not 350 recommended, provides a means of ensuring this compatibility. 352 3. Test Vectors 354 The following values are obtained when wrapping a 256-bit Blowfish-CFB 355 key using a triple DES-CBC key derived from the passphrase "All 356 n-entities must communicate with other n-entities via n-1 357 entiteeheehees" with salt { 12 34 56 78 78 56 34 12 } using 500 358 iterations of PBKDF2. 360 PKCS #5v2 values: 362 input 41 6C 6C 20 6E 2D 65 6E 74 69 74 69 65 73 20 6D 363 passphrase: 75 73 74 20 63 6F 6D 6D 75 6E 69 63 61 74 65 20 364 77 69 74 68 20 6F 74 68 65 72 20 6E 2d 65 6E 74 365 69 74 69 65 73 20 76 69 61 20 6E 2D 31 20 65 6E 366 74 69 74 65 65 68 65 65 68 65 65 73 367 "All n-entities must communicate with other " 368 "n-entities via n-1 entiteeheehees" 369 input 370 salt: 12 34 56 78 78 56 34 12 371 iterations: 500 373 output 6A 89 70 BF 68 C9 2C AE A8 4A 8D F2 85 10 85 86 374 3DES key: 07 12 63 80 CC 47 AB 2D 376 CEK formatting phase: 378 length byte: 20 379 key check: 73 9C 82 380 CEK: 8C 63 7D 88 72 23 A2 F9 65 B5 66 EB 01 4B 0F A5 381 D5 23 00 A3 F7 EA 40 FF FC 57 72 03 C7 1B AF 3B 382 padding: FA 06 0A 45 384 complete 20 93 9C 82 8C 63 7D 88 72 23 A2 F9 65 B5 66 EB 385 CEK block: 01 4B 0F A5 D5 23 00 A3 F7 EA 40 FF FC 57 72 03 386 C7 1B AF 3B FA 06 0A 45 388 Key wrap phase (wrap CEK block using 3DES key): 390 IV: BA F1 CA 79 31 21 3C 4E 392 first encr. F8 3F 9E 16 78 51 41 10 64 27 65 A9 F5 D8 71 CD 393 pass output: 27 DB AA 41 E7 BD 80 48 A9 08 20 FF 40 82 A2 80 394 96 9E 65 27 9E 12 6A EB 396 second encr. C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55 397 pass output: 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9 398 EC 74 E6 CA D7 DB 26 0C 400 ASN.1 encoded PasswordRecipientInfo: 402 0 A3 96: [3] { 403 2 02 1: INTEGER 0 404 5 A0 27: [0] { 405 7 06 9: OBJECT IDENTIFIER id-PBKDF2 (1 2 840 113549 1 5 12) 406 18 30 14: SEQUENCE { 407 20 04 8: OCTET STRING 408 : 12 34 56 78 78 56 34 12 409 30 02 2: INTEGER 500 410 : } 411 : } 412 34 30 20: SEQUENCE { 413 36 06 8: OBJECT IDENTIFIER des-EDE3-CBC (1 2 840 113549 3 7) 414 46 04 8: OCTET STRING 415 : BA F1 CA 79 31 21 3C 4E 416 : } 417 56 04 40: OCTET STRING 418 : C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55 419 : 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9 420 : EC 74 E6 CA D7 DB 26 0C 421 : } 423 4. Security Considerations 425 The security of this recipient information type rests on the security 426 of the underlying mechanisms employed, for which further information 427 can be found in RFC 2640 and PKCS5v2. More importantly, however, when 428 used with a password the security of this information type rests on the 429 entropy of the user-selected password, which is typically quite low. 430 Pass phrases (as opposed to simple passwords) are STRONGLY RECOMMENDED, 431 although it should be recognized that even with pass phrases it will be 432 difficult to use this recipient information type to derive a KEK with 433 sufficient entropy to properly protect a 128-bit (or higher) CEK. 435 5. Changes Since the Last Version 437 - Added length count due to concerns over odd-length RC2 keys 438 - Added check value to allow better error reporting and balance 439 out the single-byte length value 440 - Included test vectors 442 Author Address 444 Peter Gutmann 445 University of Auckland 446 Private Bag 92019 447 Auckland, New Zealand 448 pgut001@cs.auckland.ac.nz 450 References 452 ASN1 Recommendation X.680: Specification of Abstract Syntax Notation 453 One (ASN.1), 1994. 455 PKCS5v2 PKCS #5 v2.0: Password-Based Cryptography Standard, RSA 456 Laboratories, 25 March 1999. 458 RFC2119 Key Words for Use in RFC's to Indicate Requirement Levels, 459 S.Bradner, March 1997. 461 RFC2268 A Description of the RC2(r) Encryption Algorithm, R.Rivest, 462 March 1998. 464 RFC2640 Cryptographic Message Syntax, draft-ietf-smime-cms-11.txt, Russ 465 Housley, April 1999. 467 PACKAGE All-or-Nothing Encryption and the Package Transform, 468 R.Rivest, Proceedings of Fast Software Encryption '97, Haifa, 469 Israel, January 1997. 471 Appendix A: ASN.1 Module 473 PasswordRecipientInfo 474 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 475 smime(16) modules(0) pwri(n+1) } 477 DEFINITIONS IMPLICIT TAGS ::= 478 BEGIN 480 IMPORTS 482 FROM PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 483 pkcs-5(5) } 484 PBKDF2-params, PBES2-Encs; 486 PasswordRecipientInfo ::= SEQUENCE { 487 version CMSVersion, -- Always set to 0 488 keyDerivationAlgorithm 489 [0] KeyDerivationAlgorithmIdentifier OPTIONAL, 490 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 491 encryptedKey EncryptedKey } 493 KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= { 494 { SYNTAX PBKDF2-params IDENTIFIED BY id-PBKDF2 }, 495 ... 496 } 498 KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs 500 END 502 Full Copyright Statement 504 Copyright (C) The Internet Society 1999. All Rights Reserved. 506 This document and translations of it may be copied and furnished to 507 others, and derivative works that comment on or otherwise explain it or 508 assist in its implementation may be prepared, copied, published and 509 distributed, in whole or in part, without restriction of any kind, 510 provided that the above copyright notice and this paragraph are 511 included on all such copies and derivative works. However, this 512 document itself may not be modified in any way, such as by removing the 513 copyright notice or references to the Internet Society or other 514 Internet organizations, except as needed for the purpose of developing 515 Internet standards in which case the procedures for copyrights defined 516 in the Internet Standards process must be followed, or as required to 517 translate it into languages other than English. 519 The limited permissions granted above are perpetual and will not be 520 revoked by the Internet Society or its successors or assigns. 522 This document and the information contained herein is provided on an 523 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 524 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 525 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 526 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 527 FITNESS FOR A PARTICULAR PURPOSE.