idnits 2.17.1 draft-ietf-smime-bfibecms-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 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 687. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 661. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 675. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (June 2008) is 5787 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) -- Possible downref: Non-RFC (?) normative reference: ref. 'DER' ** Downref: Normative reference to an Informational RFC: RFC 5091 (ref. 'IBCS') == Outdated reference: A later version (-09) exists of draft-ietf-smime-ibearch-06 ** Downref: Normative reference to an Informational draft: draft-ietf-smime-ibearch (ref. 'IBE') ** Obsolete normative reference: RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 9 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 Intended status: Standards Track Tumbleweed Communications 6 Expires: December 2008 June 2008 8 Using the Boneh-Franklin and Boneh-Boyen Identity-based 9 Encryption Algorithms with the Cryptographic Message Syntax 10 (CMS) 12 14 Status of this Document 16 By submitting this Internet-Draft, each author represents 17 that any applicable patent or other IPR claims of which he 18 or she is aware have been or will be disclosed, and any of 19 which he or she becomes aware will be disclosed, in 20 accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet 23 Engineering Task Force (IETF), its areas, and its working 24 groups. Note that other groups may also distribute working 25 documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of 28 six months and may be updated, replaced, or obsoleted by 29 other documents at any time. It is inappropriate to use 30 Internet-Drafts as reference material or to cite them other 31 than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be 37 accessed at 38 http://www.ietf.org/shadow.html 40 Abstract 42 This document describes the conventions for using the Boneh- 43 Franklin (BF) and Boneh-Boyen (BB1) identity-based 44 encryption algorithms in the Cryptographic Message Syntax 45 (CMS) to encrypt content-encryption keys. Object identifiers 46 and the convention for encoding a recipient's identity are 47 also defined. 49 Table of Contents 51 1. Introduction............................................2 52 1.1. Terminology........................................3 53 1.2. IBE overview.......................................3 54 2. Using identity-based encryption.........................4 55 3. Key encryption algorithm identifiers....................8 56 4. Processing by the sender................................8 57 5. Processing by the receiver..............................9 58 6. ASN.1 module............................................9 59 7. Security considerations................................11 60 7.1. Attacks that are outside the scope of this 61 document...............................................11 62 7.2. Attacks that are within the scope of this 63 document...............................................12 64 7.3. Attacks to which the protocols defined in this 65 document are susceptible...............................12 66 8. IANA considerations....................................13 67 9. References.............................................14 68 9.1. Normative references..............................14 69 9.2. Informative references............................14 70 Authors' Addresses........................................15 71 Intellectual property statement...........................15 72 Disclaimer of validity....................................16 73 Copyright statement.......................................16 74 Acknowledgment............................................16 76 1. Introduction 78 This document defines the way to use the Boneh-Franklin 79 [IBCS] and Boneh-Boyen [IBCS] identity-based encryption 80 (IBE) public-key algorithms in the Cryptographic Message 81 Syntax (CMS) [CMS]. IBE is a public key technology for 82 encrypting content-encryption keys (CEKs) that can be 83 implemented within the framework of the CMS: the recipient's 84 identity is incorporated into the EnvelopedData CMS content 85 type using the OtherRecipientInfo CHOICE in the 86 RecipientInfo field as defined in section 6.2.5 of [CMS]. 87 This document does not describe the implementation of the BF 88 and BB1 algorithms, which are described in detail in [IBCS]. 90 IBE algorithms are a type of public-key cryptographic 91 algorithm in which the public key is calculated directly 92 from a user's identity instead of being generated randomly. 93 This requires a different set of steps for encryption and 94 decryption than would be used with other public-key 95 algorithms, and these steps are defined in Sections 4 and 5 96 of this document respectively. 98 This document also defines the object identifiers and syntax 99 of the object that is used to define the identity of a 100 message recipient. 102 CMS values and identity objects are defined using ASN.1 103 [ASN1]. 105 1.1. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 108 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 109 and "OPTIONAL" in this document are to be interpreted as 110 described in RFC 2119 [KEYWORDS]. 112 1.2. IBE overview 114 In addition to the client components that are described in 115 this document, the following additional components are 116 required for a complete IBE messaging system. 118 o A Private-key Generator (PKG). The PKG contains the 119 cryptographic material, known as a master secret, 120 for generating an individual's IBE private key. A 121 PKG accepts an IBE user's private key request and, 122 after successfully authenticating them in some way, 123 returns their IBE private key. 125 o A Public Parameter Server (PPS). IBE System 126 Parameters include publicly sharable cryptographic 127 material, known as IBE public parameters, and 128 policy information for the PKG. A PPS provides a 129 well-known location for distribution of IBE public 130 parameters and policy information for the IBE PKG. 132 The interaction of senders and receivers of IBE-encrypted 133 messages are described in [IBE]. All communications 134 between users of an IBE system and the PPS or PKG MUST be 135 protected using TLS [TLS] as described in [IBE]. This 136 provides confidentiality and integrity of all information 137 that is delivered to users as well as authentication of 138 the PPS and PKG. 140 2. Using identity-based encryption 142 To use IBE, the ori field in RecipientInfo MUST be used. The 143 fields are set as follows: oriType is set to ibeORIType; 144 oriValue is set to ibeORIValue. 146 These fields have the following meanings: 148 ibeORIType defines the object identifier (OID) that 149 indicates that the subsequent ibeORIValue is the information 150 necessary to decrypt the message using IBE. This field MUST 151 be set to the following: 153 ibeORIType OBJECT IDENTIFIER ::= { 154 joint-iso-itu(2) country(16) us(840) 155 organization(1) identicrypt(114334) 156 ibcs(1) cms(4) ori-oid(1) 157 } 159 ibeORIValue defines the identity that was used in the IBE 160 algorithm to encrypt the CEK. This is an IBERecipientInfo 161 type, which is defined as follows: 163 IBERecipientInfo ::= SEQUENCE { 164 cmsVersion INTEGER { v3(3) }, 165 keyFetchMethod OBJECT IDENTIFIER, 166 recipientIdentity IBEIdentityInfo, 167 serverInfo SEQUENCE SIZE (1..MAX) OF 168 OIDValuePairs OPTIONAL, 169 encryptedKey EncryptedKey 170 } 172 The fields of IBERecipientInfo MUST be set as follows. 174 The cmsVersion MUST be set to 3. 176 The keyFetchMethod is the OID that defines the method of 177 retrieving the private key that the recipient MUST use. How 178 to retrieve an IBE private key using the steps defined in 179 [IBE] is defined by the keyFetchMethod OID. The method for 180 retrieving private keys that is specified in [IBE] is 181 defined by cmsPPSOID, which is defined to be the following: 183 cmsPPSOID OBJECT IDENTIFIER ::= { 184 joint-iso-itu-t(2) country(16) us(840) 185 organization(1) identicrypt(114334) 186 pps-schemas(3) ic-schemas(1) pps-uri(1) 187 } 189 The recipientIdentity is the data that was used to calculate 190 the IBE public key that was used to encrypt the content- 191 encryption key. This recipientIdentity is used to calculate 192 IBE public and private keys as described in [IBCS]. This 193 MUST be an IBEIdentityInfo type, which is defined as 194 follows: 196 IBEIdentityInfo ::= SEQUENCE { 197 district IA5String, 198 serial INTEGER, 199 identitySchema OBJECT IDENTIFIER, 200 identityData OCTET STRING 201 } 203 The fields of IBEIdentityInfo have the following meanings. 205 The district and serial are unique identifiers that are used 206 to construct the URI for the location of the necessary IBE 207 public parameters. The construction and use of this URI is 208 defined in [IBE]. Internationalized Resource Identifiers 209 (IRIs) MUST be handled according to the procedures specified 210 in Section 7.4 of [PKIX]. 212 The identitySchema defines the format that is used to encode 213 the information that defines the identity of the recipient. 214 This MUST be set to cmsIdentityOID to indicate that 215 identityData contains an EmailIdentitySchema type. The value 216 of cmsIdentityOID is the following: 218 cmsIdentityOID OBJECT IDENTIFIER ::= { 219 joint-iso-itu-t(2) country(16) us(840) 220 organization(1) identicrypt(114334) 221 keyschemas(2) icschemas(1) rfc822Name(1) 222 } 224 The identityData field contains the identify information for 225 the recipient, the contents of which is an ASN.1 structure 226 which MUST be DER encoded [DER] before placing it in the 227 OCTET STRING. 229 If identitySchema is set to the cmsIdentityOID OBJECT 230 IDENTIFIER, the identityData MUST be an EmailIdentitySchema 231 type, which is defined as follows: 233 EmailIdentitySchema ::= SEQUENCE { 234 rfc822Name IA5String, 235 time GeneralizedTime 236 } 238 The rfc822Name field is the e-mail address of the recipient 239 in the format defined in Section 4.2.1.6 of [PKIX] for the 240 rfc822Name subjectAltName variant. Rules for encoding 241 Internet mail addresses that include internationalized 242 domain names are specified in Section 7.5 of [PKIX]. 244 The value of the time field is the UTC time after which the 245 sender wants to let the recipient decrypt the message, so it 246 may be called the "not-before" time. This is usually set to 247 the time when the message is encrypted, but MAY be set to a 248 future time. The value of "time" MUST be expressed in 249 Greenwich Mean Time(Zulu), MUST include seconds (i.e. times 250 are always YYYYMMDDHHMMSSZ), even where the number of 251 seconds is equal to zero and MUST be expressed to the 252 nearest second. 254 The sender of an IBE-encrypted message may want to express 255 this time rounded to a time interval to create a key 256 lifetime. A key lifetime reduces the number of IBE private 257 keys that a recipient needs to retrieve, but still forces 258 the IBE user to periodically re-authenticate. Based on the 259 time interval chosen a recipient would only have to retrieve 260 a new IBE key once during the interval. To do this, follow 261 the following steps. Let "time-interval" be the number of 262 seconds in this larger time interval. 264 1. Find the GeneralizedTime for the not-before value. 265 2. Convert this GeneralizedTime into the number of 266 seconds since January 1, 1970. Call this 267 "total-time." 268 3. Calculate reduced-time = (floor (total-time / 269 time-interval)) * time-interval. 270 4. Convert reduced-time to a GeneralizedTime to get the 271 not-before "time" value. 273 An example of this algorithm for computing a one week time 274 interval is as follows. 276 1. Suppose that the GeneralizedTime is 20020401000000Z. 277 2. Then the total-time is 1017612000. 278 3. A time-interval of 1 week is 604800 seconds. 279 So the reduced-time = (floor(1017612000/604800)) * 280 604800 = 1017273600. 281 4. This gives the GeneralizedTime form of the 282 reduced-time of 20020328000000Z. 284 When issuing IBE private keys, a PKG SHOULD NOT issue them 285 too far into the future. This restriction is to prevent an 286 adversary who obtains an IBE user's authentication 287 credentials from requesting private keys far into the future 288 and therefore negating the periodic IBE user re- 289 authentication that key lifetime provides. For example if a 290 one week period is chosen for the key lifetime, then IBE 291 private keys should not be issued more than 1 week in 292 advance. Otherwise once an adversary gains access to the PKG 293 via the stolen IBE user credentials they can request all 294 future keys and negate the IBE user authentication 295 restraints in place. 297 The serverInfo is an optional sequence of OID-value pairs 298 that are defined to be the following: 300 OIDValuePairs ::= SEQUENCE { 301 fieldID OBJECT IDENTIFIER, 302 fieldData OCTET STRING 303 } 305 These can be used to convey any other information that might 306 be used by a PKG. Examples of such information could include 307 the user interface that the recipient will experience. 308 Differences in the user interface could include localization 309 information or commercial branding information. 311 OIDValuePairs ::= SEQUENCE { 312 fieldID OBJECT IDENTIFIER, 313 fieldData OCTET STRING 314 } 316 The encryptedKey is the result of encrypting the CEK with an 317 IBE algorithm using recipientIdentity as the IBE public key. 319 3. Key encryption algorithm identifiers 321 The BF and BB1 algorithms as defined in [IBCS] have the 322 following object identifiers. These object identifiers are 323 also defined in the ASN.1 module in [IBCS]. 325 bf OBJECT IDENTIFIER ::= { 326 joint-iso-itu-t(2) country(16) us(840) 327 organization(1) identicrypt(114334) 328 ibcs(1) ibcs1(1) ibe-algorithms(2) bf(1) 329 } 331 This is the object identifier that MUST be inserted in the 332 keyEncryptionAlgorithm field in the CMS when the BF 333 algorithm is used to encrypt the CEK. 335 bb1 OBJECT IDENTIFIER ::= { 336 joint-iso-itu-t(2) country(16) us(840) 337 organization(1) identicrypt(114334) 338 ibcs(1) ibcs1(1) ibe-algorithms(2) bb1(2) 339 } 341 This is the object identifier that MUST be inserted in the 342 keyEncryptionAlgorithm field in the CMS when the BB1 343 algorithm is used to encrypt the CEK. 345 4. Processing by the sender 347 The sender of a message that uses IBE to encrypt content- 348 encryption keys performs the following steps: 350 1. Selects a set of IBE public parameters to use in the 351 subsequent steps in accordance with his local security 352 policy. He then determines the URI where the public 353 parameters can be obtained using the process described in 354 [IBE]. This information MUST be encoded in the 355 IBEIdentityInfo as described in Section 2. 357 2. Sets the fields of an OtherRecipientInfo object to 358 their appropriate values as described in Section 2. 360 3. Calculates an IBE public key as defined in [IBCS] 361 using this IBEIdentityInfo as the identity information. 363 4. This IBE public key is then used to encrypt the 364 content-encryption key (CEK), using the algorithms that are 365 defined in [IBCS]. 367 5. Sets encryptedKey to the IBE-encrypted CEK. 369 6. Within the CMS, keyEncryptionAlgorithm MUST then be 370 set to the appropriate OID for the IBE algorithm that was 371 used (see Section 3). 373 5. Processing by the receiver 375 Upon receiving a message that has a CEK encrypted with IBE, 376 the recipient performs the following steps to decrypt the 377 CEK: 379 1. Determines that the CEK is IBE-encrypted by noting that 380 the oriType of the OtherRecipientInfo type is set to 381 ibeORIType. 383 2. Determines that the recipientIdentity was used as the 384 identity in IBE encryption of the CEK. 386 3. Determines the location of the IBE public parameters 387 and the IBE Private Key Generator as described in 388 [IBE]. 390 4. Obtains the IBE public parameters from the location 391 determined in Step 3 using the process defined in 392 [IBE]. 394 5. Obtains the IBE private key needed to decrypt the 395 encrypted CEK using the process defined in [IBE]. 397 6. Decrypts the CEK using the IBE private key obtained in 398 Step 4 using the algorithms described in [IBCS]. 400 6. ASN.1 module 402 The following ASN.1 module summarizes the ASN.1 definitions 403 discussed in this document. 405 IBECMS-module { 406 joint-iso-itu-t(2) country(16) us(840) 407 organization(1) identicrypt(114334) 408 ibcs(1) cms(4) module(5) version(1) 409 } 411 DEFINITIONS IMPLICIT TAGS ::= BEGIN 413 IBEOtherRecipientInfo ::= SEQUENCE { 414 oriType OBJECT IDENTIFIER, 415 oriValue IBERecipientInfo 416 } 418 ibeORIType OBJECT IDENTIFIER ::= { 419 joint-iso-itu-t(2) country(16) us(840) 420 organization(1) identicrypt(114334) 421 ibcs(1) cms(4) ori-oid(1) 422 } 424 IBERecipientInfo ::= SEQUENCE { 425 cmsVersion INTEGER { v3(3) }, 426 keyFetchMethod OBJECT IDENTIFIER, 427 recipientIdentity IBEIdentityInfo, 428 serverInfo SEQUENCE SIZE (1..MAX) OF 429 OIDValuePairs OPTIONAL, 430 encryptedKey EncryptedKey 431 } 433 IBEIdentityInfo ::= SEQUENCE { 434 district IA5String, 435 serial INTEGER, 436 identitySchema OBJECT IDENTIFIER, 437 identityData OCTET STRING 438 } 440 OIDValuePairs ::= SEQUENCE { 441 fieldID OBJECT IDENTIFIER, 442 fieldData OCTET STRING 443 } 445 EncryptedKey ::= OCTET STRING 447 EmailIdentitySchema ::= SEQUENCE { 448 rfc822Name IA5String, 449 time GeneralizedTime 450 } 451 cmsIdentityOID OBJECT IDENTIFIER ::= { 452 joint-iso-itu-t(2) country(16) us(840) 453 organization(1) identicrypt(114334) 454 keyschemas(2) icschemas(1) RFC2821email(1) 455 } 457 cmsPPSOID OBJECT IDENTIFIER ::= { 458 joint-iso-itu-t(2) country(16) us(840) 459 organization(1) identicrypt(114334) 460 pps-schemas(3) ic-schemas(1) pps-uri(1) 461 } 463 END 465 7. Security considerations 467 This document is based on [CMS] and [IBCS], and the relevant 468 security considerations of those documents apply. 470 7.1. Attacks that are outside the scope of this document 472 Attacks on the cryptographic algorithms that are used to 473 implement IBE are outside the scope of this document. Such 474 attacks are detailed in [IBCS], which defines parameters 475 that give 80-bit, 112-bit, 128-bit and 256-bit encryption 476 strength. We assume that capable administrators of an IBE 477 system will select parameters that provide a sufficient 478 resistance to cryptanalytic attacks by adversaries. 480 Attacks that give an adversary the ability to access or 481 change the information on a PPS or PKG, especially the 482 cryptographic material (referred to in this document as the 483 master secret), will defeat the security of an IBE system. 484 In particular, if the cryptographic material is compromised 485 the adversary will have the ability to recreate any user's 486 private key and therefore decrypt all messages protected 487 with the corresponding public key. To address this concern, 488 it is highly RECOMMENDED that best practices for physical 489 and operational security for PPS and PKG servers be followed 490 and that these servers be configured (sometimes known as 491 hardened) in accordance with best current practices [NIST]. 492 An IBE system SHOULD be operated in an environment where 493 illicit access to the PKG or the ability to modify the 494 information distributed by the PPS is infeasible for 495 attackers to obtain. 497 Attacks that require administrative or IBE user equivalent 498 access to machines used by either the client or the server 499 components defined in this document are also outside the 500 scope of this document. 502 We also assume that all administrators of a system 503 implementing the protocols that are defined in this document 504 are trustworthy and will not abuse their authority to bypass 505 the security provided by an IBE system. This is of 506 particular importance with an IBE system, for an 507 administrator of a PKG could potentially abuse his authority 508 and configure the PKG to grant him any IBE private key that 509 the PKG is capable of calculating. To minimize the 510 possibility of administrators doing this, a system 511 implementing IBE SHOULD implement n-out-of-m control for 512 critical administrative functions and SHOULD maintain 513 auditable logs of all security-critical events that occur in 514 an operating IBE system. 516 Similarly, we assume that users of an IBE system will behave 517 responsibly, not sharing their authentication credentials 518 with others. Thus attacks that require such assumptions are 519 outside the scope of this document. 521 7.2. Attacks that are within the scope of this document 523 Attacks within the scope of this document are those that 524 allow an adversary to: 526 o passively monitor information transmitted between 527 users of an IBE system and the PPS and PKG 529 o masquerade as a PPS or PKG 531 o perform a DOS attack on a PPS or PKG 533 o easily guess an IBE user's authentication 534 credential 536 7.3. Attacks to which the protocols defined in this document 537 are susceptible 539 All communications between users of an IBE system and the 540 PPS or PKG are protected using TLS [TLS]. The IBE system 541 defined in this document provides no additional security for 542 the communications between IBE users and the PPS or PKG. 543 Therefore the described IBE system is completely dependent 544 on the TLS security mechanisms for authentication of the PKG 545 or PPS server and for confidentiality and integrity of the 546 communications. Should there be a compromise of the TLS 547 security mechanisms, the integrity of all communications 548 between an IBE user and the PPS or PKG will be suspect. 550 The protocols defined in this document do not explicitly 551 defend against an attacker masquerading as a legitimate IBE 552 PPS or PKG. The protocols rely on the server authentication 553 mechanism of TLS [TLS]. In addition to the TLS server 554 authentication mechanism IBE client software can provide 555 protection against this possibility by providing user 556 interface capabilities that allows users to visually 557 determine that a connection to PPS and PKG servers is 558 legitimate. This additional capability can help ensure that 559 users cannot easily be tricked into providing valid 560 authorization credentials to an attacker. 562 The protocols defined in this document are also vulnerable 563 to attacks against an IBE PPS or PKG. Denial of service 564 attacks against either component can result in users unable 565 to encrypt or decrypt using IBE, and users of an IBE system 566 SHOULD take the appropriate countermeasures [DOS, BGPDOS] 567 that their use of IBE requires. 569 The IBE user authentication method used by an IBE PKG SHOULD 570 be of sufficient strength to prevent attackers from easily 571 guessing the IBE user's authentication credentials through 572 trial and error. 574 8. IANA considerations 576 No further action by the IANA is necessary for this 577 document. 579 9. References 581 9.1. Normative references 583 [ASN1] ITU-T Recommendation X.680: Information Technology - 584 Abstract Syntax Notation One (ASN.1): 585 Specification of Basic Notation," July 2002. 587 [CMS] R. Housley, "Cryptographic Message Syntax," RFC 3852, 588 July 2004. 590 [DER] ITU-T Recommendation X.690: OSI Networking and System 591 Aspects: Abstract Syntax Notation One (ASN.1), 592 July 2002. 594 [DOS] P. Ferguson and D. Senie, "Network Ingress Filtering: 595 Defeating Denial of Service Attacks which employ 596 IP Source Address Spoofing," RFC 2827, BCP 38, May 597 2000. 599 [IBCS] X. Boyen and L. Martin, "Identity-based Cryptography 600 Standard (IBCS) #1: Supersingular Curve 601 Implementations of the BF and BB1 Cryptosystems," 602 RFC 5091, December 2007. 604 [IBE] G. Appenzeller, L. Martin and M. Schertler, "Identity- 605 based Encryption Architecture," draft-ietf-smime- 606 ibearch-06.txt. 608 [KEYWORDS] S. Brander, "Key Words for Use in RFCs to 609 Indicate Requirement Levels," BCP 14, RFC 2119, 610 March 1997. 612 [PKIX] D. Cooper, et al., "Internet X.509 Public Key 613 Infrastructure Certificate and Certificate 614 Revocation List (CRL) Profile," RFC 5280, May 615 2008. 617 [TLS] T. Dierks and E. Rescorla, "The Transport Layer 618 Security (TLS) Protocol Version 1.1," RFC 4346, 619 April 2006. 621 9.2. Informative references 623 [BGPDOS] D. Turk, "Configuring BGP to Block Denial-of- 624 Service Attacks," RFC 3882, September 2004. 626 [NIST] M. Souppaya, J. Wack and K. Kent, "Security 627 Configuration Checklist Program for IT Products - 628 Guidance for Checklist Users and Developers," NIST 629 Special Publication SP 800-70, May 2005. 631 Authors' Addresses 633 Luther Martin 634 Voltage Security 635 1070 Arastradero Rd Suite 100 636 Palo Alto CA 94304 637 USA 639 Phone: +1 650 543 1280 640 Email: martin@voltage.com 642 Mark Schertler 643 Tumbleweed Communications 644 700 Saginaw Dr 645 Redwood City CA 94063 646 USA 648 Phone: +1 650 216 2039 649 Email: mark.schertler@tumbleweed.com 651 Intellectual property statement 653 The IETF takes no position regarding the validity or scope 654 of any Intellectual Property Rights or other rights that 655 might be claimed to pertain to the implementation or use of 656 the technology described in this document or the extent to 657 which any license under such rights might or might not be 658 available; nor does it represent that it has made any 659 independent effort to identify any such rights. Information 660 on the procedures with respect to rights in RFC documents 661 can be found in BCP 78 and BCP 79. 663 Copies of IPR disclosures made to the IETF Secretariat and 664 any assurances of licenses to be made available, or the 665 result of an attempt made to obtain a general license or 666 permission for the use of such proprietary rights by 667 implementers or users of this specification can be obtained 668 from the IETF on-line IPR repository at 669 http://www.ietf.org/ipr. 671 The IETF invites any interested party to bring to its 672 attention any copyrights, patents or patent applications, or 673 other proprietary rights that may cover technology that may 674 be required to implement this standard. Please address the 675 information to the IETF at ietf-ipr@ietf.org. 677 Disclaimer of validity 679 This document and the information contained herein are 680 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 681 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 682 THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET 683 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 684 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 685 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 686 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR 687 A PARTICULAR PURPOSE. 689 Copyright statement 691 Copyright (C) The IETF Trust (2008). 693 This document is subject to the rights, licenses and 694 restrictions contained in BCP 78, and except as set forth 695 therein, the authors retain all their rights. 697 Acknowledgment 699 Funding for the RFC Editor function is currently provided by 700 the Internet Society.