idnits 2.17.1 draft-ietf-smime-ibearch-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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1505. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1479. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1487. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1493. 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 (October 2008) is 5664 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. 'ASCII' -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' ** Obsolete normative reference: RFC 2617 (ref. 'AUTH') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) -- Possible downref: Non-RFC (?) normative reference: ref. 'DER' ** Obsolete normative reference: RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (ref. 'HTTPTLS') (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 5091 (ref. 'IBCS') ** Obsolete normative reference: RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 G. Appenzeller 3 Stanford University 4 S/MIME Working Group L. Martin 5 Internet Draft Voltage Security 6 Intended status: Standards Track M. Schertler 7 Expires: April 2009 Tumbleweed Communications 8 October 2008 10 Identity-based Encryption Architecture and Supporting Data 11 Structures 13 15 Status of this Document 17 By submitting this Internet-Draft, each author represents 18 that any applicable patent or other IPR claims of which he 19 or she is aware have been or will be disclosed, and any of 20 which he or she becomes aware will be disclosed, in 21 accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet 24 Engineering Task Force (IETF), its areas, and its working 25 groups. Note that other groups may also distribute working 26 documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of 29 six months and may be updated, replaced, or obsoleted by 30 other documents at any time. It is inappropriate to use 31 Internet-Drafts as reference material or to cite them other 32 than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be 38 accessed at 39 http://www.ietf.org/shadow.html 41 Abstract 43 This document describes the security architecture required to 44 implement identity-based encryption, a public-key encryption 45 technology that uses a user's identity as a public key. It 46 also defines data structures that can be used to implement the 47 technology. 49 Table of Contents 51 1. Introduction.........................................4 52 1.1. Terminology.....................................4 53 2. Identity-based Encryption............................4 54 2.1. Overview........................................4 55 2.2. Sending a Message that is IBE-encrypted.........6 56 2.2.1. Sender Obtains Public Parameters...........6 57 2.2.2. Construct and Send IBE-encrypted Message...7 58 2.3. Receiving and Viewing an IBE-encrypted Message..8 59 2.3.1. Recipient Obtains Public Parameters........9 60 2.3.2. Recipient Obtains IBE Private Key..........9 61 2.3.3. Recipient Decrypts IBE-encrypted Message..10 62 3. Identity Format.....................................10 63 4. Public Parameter Lookup.............................11 64 4.1. Request Method.................................12 65 4.2. Parameter and Policy Format....................12 66 4.3. The application/ibe-pp-data MIME type..........16 67 5. Private Key Request Protocol........................17 68 5.1. Overview.......................................17 69 5.2. Private Key Request............................18 70 5.3. Request Structure..............................18 71 5.4. The application/ibe-key-request+xml MIME type..20 72 5.5. Authentication.................................21 73 5.6. Server Response Format.........................21 74 5.6.1. The IBE100 responseCode...................22 75 5.6.2. The IBE101 responseCode...................23 76 5.6.3. The IBE201 responseCode...................23 77 5.6.4. The IBE300 responseCode...................24 78 5.6.5. The IBE301 responseCode...................24 79 5.6.6. The IBE303 responseCode...................25 80 5.6.7. The IBE304 responseCode...................25 81 5.7. The application/ibe-pkg-reply+xml MIME type....25 82 6. ASN.1 Module........................................26 83 7. Security Considerations.............................28 84 7.1. Attacks outside the scope of this document.....28 85 7.2. Attacks within the scope of this document......29 86 7.2.1. Attacks on the protocols defined in this 87 document.........................................29 88 8. IANA Considerations.................................30 89 8.1. Media types....................................30 90 8.2. XML namespace..................................30 91 9. References..........................................32 92 9.1. Normative References...........................32 93 9.2. Informative References.........................33 94 Authors' Addresses.....................................34 95 Intellectual Property Statement........................34 96 Disclaimer of Validity.................................35 97 Copyright Statement....................................35 98 Acknowledgment.........................................35 100 1. Introduction 102 This document describes the security architecture required 103 to implement identity-based encryption, a public-key 104 encryption technology that uses a user's identity as a 105 public key. It also defines data structures that are 106 required to implement the technology. Objects used in this 107 implementation are defined using ASN.1 [ASN1] and XML 108 [XML]. 110 1.1. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 113 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 114 and "OPTIONAL" in this document are to be interpreted as 115 described in [KEY]. 117 2. Identity-based Encryption 119 2.1. Overview 121 Identity-based encryption (IBE) is a public-key encryption 122 technology that allows a public key to be calculated from 123 an identity and a set of public mathematical parameters and 124 for the corresponding private key to be calculated from an 125 identity, a set of public mathematical parameters and a 126 domain-wide secret value. An IBE public key can be 127 calculated by anyone who has the necessary public 128 parameters; a cryptographic secret is needed to calculate 129 an IBE private key, and the calculation can only be 130 performed by a trusted server which has this secret. 132 Calculation of both the public and private keys in an IBE 133 system can occur as needed, resulting in just-in-time 134 creation of both public and private keys. This contrasts 135 with other public-key systems [P1363], in which keys are 136 generated randomly and distributed prior to secure 137 communication commencing, and in which private encryption 138 keys need to be securely archived to allow for their 139 recovery if they are lost or destroyed. The ability to 140 calculate a recipient's public key, in particular, 141 eliminates the need for the sender and receiver to interact 142 with each other, either directly or through a proxy such as 143 a directory server, before sending secure messages. 145 A characteristic of IBE systems that differentiates them 146 from other server-based cryptographic systems is that once 147 a set of public parameters is fetched, encryption is 148 possible with no further communication with a server during 149 the validity period of the public parameters. Other server- 150 based systems may require a connection to a server for each 151 encryption operation. 153 This document describes an IBE-based messaging system, how 154 the components of such a system work together, and defines 155 data structures that support the operation of such a 156 system. The server components required for such a system 157 are the following: 159 o A Public Parameter Server (PPS). IBE Public 160 parameters include publicly-sharable cryptographic 161 material, known as IBE public parameters, and 162 policy information for an associated PKG. A PPS 163 provides a well-known location for secure 164 distribution of IBE public parameters and policy 165 information that describe the operation of a PKG. 166 Section 4 of this document describes the protocol 167 that a client uses to communicate with a PPS. 169 o A Private-key Generator (PKG). The PKG stores and 170 uses cryptographic material, known as a master 171 secret, which is used for generating a user's IBE 172 private key. A PKG accepts an IBE user's private 173 key request, and after successfully authenticating 174 them in some way, returns their IBE private key. 175 Section 5 of this document describes the protocol 176 that a client uses to communicate with a PKG. 178 A logical architecture of such an IBE system would be to 179 have a PKG and PPS per name space, such as a DNS zone. The 180 organization that controls the DNS zone would also control 181 the PKG and PPS and thus the determination of which PKG or 182 PSS to use when creating public and private keys for the 183 organization's members. In this case the PPS URI/IRI can be 184 uniquely created from a user-friendly name for the form of 185 identity that it supports. This architecture would make it 186 clear which set of public parameters to use and where to 187 retrieve them for a given identity (for example, an RFC 188 2821 address [SMTP]). 190 IBE-encrypted messages can use standard message formats, 191 such as the Cryptographic Message Syntax [CMS]. How to use 192 IBE with the CMS to encrypt e-mail messages is defined in 193 [IBECMS]. 195 Note that IBE algorithms are used only for encryption, so 196 if digital signatures are required they will need to be 197 provided by an additional mechanism. 199 Section 3 of this document describes the identity format 200 that all PPS and PKG servers MUST support. 202 2.2. Sending a Message that is IBE-encrypted 204 In order to send an encrypted message, an IBE user must 205 perform the following steps: 207 1. Obtain the recipient's public parameters 209 The public parameters of the recipient's system are 210 needed to perform IBE operations. Once a user obtains 211 these public parameters, he can perform IBE 212 encryption operations. These public parameters may be 213 available at a PPS that is operated by the user's 214 organization, one that is operated by the sender's 215 organization, or by a different organization 216 entirely. 218 2. Construct and Send IBE-encrypted Message 220 In addition to the IBE public parameters, all that is 221 needed to construct an IBE-encrypted message is the 222 recipient's identity, the form of which is defined by 223 the public parameters. When this identity is the same 224 as the identity that a message would be addressed to, 225 then no more information is needed from a user to 226 send them an encrypted message then is needed to send 227 them an unencrypted message. This is one of the major 228 benefits of an IBE-based secure messaging system. 229 Examples of identities can be an individual, group, 230 or role identifiers. 232 2.2.1. Sender Obtains Public Parameters 234 The sender of a message obtains the IBE public parameters 235 that he needs from a PPS that is hosted at a well-known URI 236 or IRI. The IBE public parameters contain all of the 237 information that the sender needs to create an IBE- 238 encrypted message except for the identity of the recipient. 239 Section 4 of this document describes the URI [URI] or IRI 240 [IRI] of a PPS, the format of IBE public parameters, and 241 how to obtain them from a PPS. The URI or IRI from which 242 users obtain IBE public parameters MUST be authenticated in 243 some way. PPS servers MUST support TLS 1.1 [TLS] to satisfy 244 this requirement and SHOULD support its successors. This 245 step is shown below in Figure 1. 247 IBE Public Parameter Request 248 -----------------------------> 249 Sender PPS 250 <----------------------------- 251 IBE Public Parameters 253 Figure 1 Requesting IBE Public Parameters 255 The sender of an IBE-encrypted message selects the PPS and 256 corresponding PKG based on his local security policy. 257 Different PPS servers may provide public parameters that 258 specify different IBE algorithms or different key 259 strengths, for example, or require the use of PKG servers 260 that require different levels of authentication before 261 granting IBE private keys. 263 2.2.2. Construct and Send IBE-encrypted Message 265 To IBE-encrypt a message, the sender chooses a content- 266 encryption key (CEK) and uses it to encrypt his message and 267 then encrypts the CEK with the recipient's IBE public key 268 as described in [CMS]. This operation is shown below in 269 Figure 2. The document [IBCS] describes the algorithms 270 needed to implement two forms of IBE and [IBECMS] describes 271 how to use the Cryptographic Message Syntax (CMS) to 272 encapsulate the encrypted message along with the IBE 273 information that the recipient needs to decrypt an e-mail 274 message. 276 CEK ----> Sender ----> IBE-encrypted CEK 278 ^ 279 | 280 | 282 Recipient's Identity 283 and IBE Public Parameters 285 Figure 2 Using an IBE Public-key Algorithm to Encrypt 287 2.3. Receiving and Viewing an IBE-encrypted Message 289 In order to read an IBE-encrypted message, a recipient of 290 such a message parses the message to find the URI or IRI he 291 needs to obtain the IBE public parameters that are required 292 to perform IBE calculations as well as a component of the 293 identity that was used to encrypt the message. Next the 294 recipient carries out the following steps: 296 1. Obtain the IBE public parameters 298 An IBE system's public parameters allow it to 299 uniquely create public and private keys. The 300 recipient of an IBE-encrypted message can decrypt an 301 IBE-encrypted message if he has both the IBE public 302 parameters and the necessary IBE private key. The 303 public parameters also provide the URI or IRI of the 304 PKG where the recipient of an IBE-encrypted message 305 can obtain the IBE private keys. 307 2. Obtain the IBE private key from the PKG 309 To decrypt an IBE-encrypted message, in addition to 310 the IBE public parameters, the recipient needs to 311 obtain the private key that corresponds to the public 312 key that the sender used. The IBE private key is 313 obtained after successfully authenticating to a 314 private key generator (PKG), a trusted third party 315 that calculates private keys for users. The recipient 316 then receives the IBE private key over a secure 317 connection. 319 3. Decrypt IBE-encrypted message 321 The IBE private key decrypts the CEK (see Section 322 2.2.2). The CEK is then used to decrypt encrypted 323 message. 325 It may be useful for a PKG to allow users other than the 326 intended recipient to receive some IBE private keys. Giving 327 a mail filtering appliance permission to obtain IBE private 328 keys on behalf of users, for example, can allow the 329 appliance to decrypt and scan encrypted messages for 330 viruses or other malicious features. 332 2.3.1. Recipient Obtains Public Parameters 334 Before he can perform any IBE calculations related to the 335 message that he has received, the recipient of an IBE- 336 encrypted message needs to obtain the IBE public parameters 337 that were used in the encryption operation. This operation 338 is shown below in Figure 3. Because the use of the correct 339 public parameters is vital to the overall security of an 340 IBE system, IBE public parameters MUST be transported to 341 recipients over a secure protocol. PPS servers MUST support 342 TLS 1.1 [TLS] or its successors, using the latest version 343 supported by both parties, for transport of IBE public 344 parameters. In addition, users MUST verify that the subject 345 name in the server certificate matches the URI/IRI of the 346 PPS. The comments in Section 2.2.1 also apply to this 347 operation. 349 IBE Public Parameter Request 350 -----------------------------> 351 Recipient PPS 352 <----------------------------- 353 IBE Public Parameters 355 Figure 3 Requesting IBE Public Parameters 357 2.3.2. Recipient Obtains IBE Private Key 359 To obtain an IBE private key, the recipient of an IBE- 360 encrypted message provides the IBE public key used to 361 encrypt the message and their authentication credentials to 362 a PKG and requests the private key that corresponds to the 363 IBE public key. Section 5 of this document defines the 364 protocol for communicating with a PKG as well as a minimum 365 interoperable way to authenticate to a PKG that all IBE 366 implementations MUST support. Because the security of IBE 367 private keys is vital to the overall security of an IBE 368 system, IBE private keys MUST be transported to recipients 369 over a secure protocol. PKG servers MUST support TLS 1.1 370 [TLS] or its successors, using the latest version supported 371 by both parties, for transport of IBE private keys. This 372 operation is shown below in Figure 4. 374 IBE Private Key Request 375 ----------------------------> 376 Recipient PKG 377 <---------------------------- 378 IBE Private Key 380 Figure 4 Obtaining an IBE Private Key 382 2.3.3. Recipient Decrypts IBE-encrypted Message 384 After obtaining the necessary IBE private key, the 385 recipient uses that IBE private key and the corresponding 386 IBE public parameters to decrypt the CEK. This operation is 387 shown below in Figure 5. He then uses the CEK to decrypt 388 the encrypted message content. An example of how to do this 389 with e-mail messages is given in [IBECMS]. 391 IBE-encrypted CEK ----> Recipient ----> CEK 393 ^ 394 | 395 | 397 IBE Private Key 398 and IBE Public Parameters 400 Figure 5 Using an IBE Public-key Algorithm to Decrypt 402 3. Identity Format 404 An IBEIdentityInfo type MUST be used to represent the 405 identity of a recipient. This is defined to be the 406 following: 408 IBEIdentityInfo ::= SEQUENCE { 409 district IA5String, 410 serial INTEGER, 411 identityType OBJECT IDENTIFIER, 412 identityData OCTET STRING 413 } 415 An IBEIdentityInfo type is used to calculate public and 416 private IBE keys. Because of this, such a structure is 417 typically DER-encoded [DER]. 419 The fields of an IBEIdentityInfo structure have the 420 following meanings. 422 The district is an IA5String that represents the URI [URI] 423 or IRI [IRI] where the recipient of an IBE-encrypted 424 message can retrieve the IBE public parameters needed to 425 encrypt or decrypt a message encrypted for this identity. 426 Applications MUST support the method described in Section 4 427 for doing this and MAY support other methods. IRIs MUST be 428 handled according to the procedures specified in Section 429 7.4 of [PKIX]. 431 The serial is an INTEGER that defines a unique set of IBE 432 public parameters in the event that more than one set of 433 parameters is used by a single district. 435 identityType is an OBJECT IDENTIFIER that defines the 436 format that the identityData field is encoded with. 438 An example of a useful IBEIdentityInfo type is given in 439 [IBECMS]. This example is tailored to the use of IBE in 440 encrypting e-mail. Because the information that comprises 441 an identity is very dependent on the application, this 442 document does not define an identityType that all 443 applications MUST support. 445 4. Public Parameter Lookup 447 This section specifies how a component of an IBE system can 448 retrieve these parameters. A sending or receiving client 449 MUST allow configuration of these parameters manually, for 450 example, through editing a configuration file. However for 451 simplified configuration a client SHOULD also implement the 452 public parameter URI/IRI request method described in this 453 document to fetch the public parameters based on a 454 configured URI/IRI. This is especially useful for 455 federating between IBE systems. By specifying a single 456 URI/IRI, a client can be configured to fetch all the 457 relevant parameters for a remote PKG. These public 458 parameters can then be used to encrypt messages to 459 recipients who authenticate to and retrieve private keys 460 from that PKG. 462 The following section outlines the URI/IRI request method 463 to retrieve a parameter block and describes the structure 464 of the parameter block itself. The technique for fetching 465 IBE public parameters using the process defined in this 466 section is indicated by the OBJECT IDENTIFIER uriPPSOID, 467 which is defined to be the following: 469 uriPPSOID OBJECT IDENTIFIER ::= { 470 joint-iso-itu-t(2) country(16) us(840) 471 organization(1) identicrypt(114334) 472 pps-schemas(3) ic-schemas(1) pps-uri(1) version(1) 473 } 475 4.1. Request Method 477 The configuration URI/IRI SHOULD be an HTTPS URI [HTTP] and 478 MAY additionally support IRIs [IRI] for this purpose. To 479 retrieve the IBE public parameters, the client SHOULD use 480 the HTTP GET method as defined in [HTTP]. The request MUST 481 happen over a secure protocol. The requesting client MUST 482 support TLS 1.1 [TLS] or its successors and SHOULD use the 483 latest version supported by both parties. When requesting 484 the URI/IRI the client MUST only accept the system 485 parameter block if the server identity was verified 486 successfully by TLS 1.1 [TLS] or its successors. 488 A successful GET request returns in its body the base64 489 [B64] encoding of the DER-encoded [DER] IBESysParams 490 structure that is described in the next section. This 491 structure MUST be encoded as an application/ibe-pp-data 492 MIME type. 494 4.2. Parameter and Policy Format 496 The IBE Public parameters are a structure of the form 498 IBESysParams ::= SEQUENCE { 499 version INTEGER { v2(2) }, 500 districtName IA5String, 501 districtSerial INTEGER, 502 validity ValidityPeriod, 503 ibePublicParameters IBEPublicParameters, 504 ibeIdentityType OBJECT IDENTIFIER, 505 ibeParamExtensions IBEParamExtensions OPTIONAL 506 } 508 The fields of an IBESysParams structure have the following 509 meanings. 511 The version field specifies the version of the IBESysParams 512 format. For the format described in this document, this 513 MUST be set to 2. 515 The districtName field is an IA5String that MUST be an 516 encoding of an URI [URI] or IRI [IRI]. IRIs MUST be handled 517 according to the procedures specified in Section 7.4 of 518 [PKIX]. 520 The districtSerial field is an integer that represents a 521 unique set of IBE public parameters that are available at 522 the URI or IRI defined by the districtName. If new 523 parameters are published for a districtName, the 524 districtSerial MUST be increased to a number greater than 525 the previously-used districtSerial. 527 The validity field defines lifetime of a specific instance 528 of the IBESysParams and is defined to be the following: 530 ValidityPeriod ::= SEQUENCE { 531 notBefore GeneralizedTime, 532 notAfter GeneralizedTime 533 } 535 The values of notBefore and netAfter MUST be expressed in 536 Greenwich Mean Time(Zulu), MUST include seconds (i.e. times 537 are always YYYYMMDDHHMMSSZ), even where the number of 538 seconds is equal to zero and MUST be expressed to the 539 nearest second. 541 A client MUST verify that the date on which it uses the IBE 542 public parameters falls between the notBefore time and the 543 notAfter time of the IBE public parameters and MUST NOT use 544 the parameters for IBE encryption operations if they do 545 not. 547 IBE public parameters MUST be regenerated and republished 548 whenever the values of ibePublicParameters, 549 ibeIdentityType, or ibeParamExtensions change for a 550 district. A client SHOULD refetch the IBE public parameters 551 at an application-configurable interval to ensure that it 552 has the most current version on the IBE public parameters. 554 It is possible to create identities for use in IBE that 555 have a time component, as described in [IBECMS], for 556 example. If such an identity is used, the time component of 557 the identity MUST fall between the notBefore time and the 558 notAfter times of the IBE public parameters. 560 IBEPublicParameters is a structure containing public 561 parameters that correspond to IBE algorithms that the PKG 562 supports. This structure is defined to be following: 564 IBEPublicParameters ::= SEQUENCE (1..MAX) OF 565 IBEPublicParameter 567 IBEPublicParameter ::= SEQUENCE { 568 ibeAlgorithm OBJECT IDENTIFIER, 569 publicParameterData OCTET STRING 570 } 572 The ibeAlgorithm OBJECT IDENTIFIER specifies an IBE 573 algorithm. The OIDs for two IBE algorithms, the Boneh- 574 Franklin and Boneh-Boyen algorithms and their 575 publicParameterData structures are defined in [IBCS]. 577 The publicParameterData is a DER-encoded [DER] structure 578 that contains the actual cryptographic parameters. Its 579 specific structure depends on the algorithm. 581 The IBESysParams of a district MUST contain an OID that 582 identifies at least one algorithm and MAY contain OIDs that 583 identify more than one algorithm. It MUST NOT contain two 584 or more IBEPublicParameter entries with the same algorithm. 585 A client that wants to use IBESysParams can chose any of 586 the algorithms specified in the publicParameterData 587 structure. A client MUST implement at least the Boneh- 588 Franklin algorithm [IBCS] and MAY implement the Boneh-Boyen 589 [IBCS] and other algorithms. If a client does not support 590 any of the supported algorithms it MUST generate an error 591 message and fail. 593 ibeIdentityType is an OID that defines the type of 594 identities that are used with this district. The OIDs and 595 the required and optional fields for each OID are 596 application dependent. An example of this is given in 597 [IBECMS], which defines an identity format suitable for use 598 in encrypting e-mail. 600 IBEParamExtensions is a set of extensions that can be used 601 to define additional parameters that particular 602 implementations may require. This structure is defined as 603 follows: 605 IBEParamExtensions ::= SEQUENCE OF IBEParamExtension 607 IBEParamExtension ::= SEQUENCE { 608 ibeParamExtensionOID OBJECT IDENTIFIER, 609 ibeParamExtensionValue OCTET STRING 610 } 612 The contents of the octet string ibeParamExtensionValue are 613 defined by the specific ibeParamExtensionOID. The 614 IBEParamExtensions of a district MAY have any number of 615 extensions, including zero. One example of extensions that 616 have been used in practice is to provide a URI where an 617 encrypted message can be decrypted and viewed by users of 618 webmail systems. Another example is to provide commercial 619 branding information, so that a bank can provide a 620 different user interface for customers of different lines 621 of business. 623 If a client receives Public parameters that contain an 624 extension that it is unable to process, it MUST NOT use the 625 values in the IBESysParams structure for any cryptographic 626 operations. Clients MUST be able to process an IBESysParams 627 structure that contains no IBEParamExtensions. 629 The pkgURI OBJECT IDENTIFIER that is defined below defines 630 an IBEParamExtensions structure that contains the URI or 631 IRI of a Private Key Generator. The presence of this OBJECT 632 IDENTIFIER in an IBEParamExtension indicates that clients 633 MUST use the protocol defined in Section 5 of this document 634 to obtain IBE private keys from the PKG and do so using the 635 URI/IRI that is defined by the value defined by the 636 ibeParamExtensionValue in the IBEParamExtension. 638 If the PKG is publicly-accessible, this extension SHOULD be 639 present to allow the automatic retrieval of private keys 640 for recipients of encrypted messages. For this extension 641 the ibeParamExtensionValue OCTET STRING is an IA5String 642 containing the URI [URI] or IRI [IRI] of the PKG where IBE 643 private keys can be obtained. IRIs MUST be handled 644 according to the procedures specified in Section 7.4 of 645 [PKIX]. 647 ibeParamExt OBJECT IDENTIFIER ::= { 648 ibcs ibcs3(3) parameter-extensions(2) 649 } 651 pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) } 653 4.3. The application/ibe-pp-data MIME type 655 The following summarizes the properties of the 656 application/ibe-pp-data MIME type. 658 MIME media type name: application 660 MIME subtype name: ibe-pp-data 662 Mandatory parameters: none 664 Optional parameters: none 666 Encoding considerations: This media type MUST be encoded as 667 7bit (us-ascii text [ASCII]). 669 Security considerations: The data conveyed as this media 670 type are the public parameters needed for the operation of 671 a cryptographic system. To ensure that the parameters can 672 be trusted, the request for these parameters must take 673 place over a secure protocol, TLS 1.1 or its successors. To 674 ensure the validity of the server, the client MUST verify 675 the server certificate and MUST abort the parameter request 676 if the verification of the server certificate of the TLS 677 connection fails. This media type contains no active 678 content and does not use compression. 680 Interoperability considerations: There are no known 681 interoperability considerations for this media type. 683 Applications that use this media type: Applications that 684 implement IBE in compliance with this specification will 685 use this media type. The most commonly-used of these 686 applications are encrypted email and file encryption. 688 Additional information: none 690 Person and email address for further information: Luther 691 Martin, martin@voltage.com. 693 Intended usage: COMMON 694 Author/Change controller: Luther Martin, 695 martin@voltage.com. 697 5. Private Key Request Protocol 699 5.1. Overview 701 When requesting a private key, a client has to transmit 702 three parameters: 704 1. The IBE algorithm for which the key is being 705 requested 707 2. The identity for which it is requesting a key 709 3. Authentication credentials for the individual 710 requesting the key 712 These two are often not the same as a single user may have 713 access to multiple aliases. For example an email user may 714 have access to the keys that correspond to two different 715 email addresses, e.g. bob@example.com and 716 bob.smith@example.com. 718 This section defines the protocol to request private keys, 719 a minimum user authentication method for interoperability, 720 and how to pass authentication credentials to the server. 721 It assumes that a client has already determined the URI/IRI 722 of the PKG. This can be done from information included in 723 the IBE message format and the public parameters of the IBE 724 system. 726 The technique for fetching an IBE private key using the 727 process defined in this section is indicated by the OBJECT 728 IDENTIFIER pkgURI, which is defined to be the following: 730 ibcs OBJECT IDENTIFIER ::= { 731 joint-iso-itu-t(2) country(16) us(840) 732 organization(1) identicrypt(114334) ibcs(1) 733 } 735 ibeParamExt OBJECT IDENTIFIER ::= { 736 ibcs ibcs3(3) parameter-extensions(2) 737 } 739 pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) } 741 5.2. Private Key Request 743 To request a private key, a client MUST perform a HTTP POST 744 method as defined in [HTTP]. The request MUST take place 745 over a secure protocol. The requesting client MUST support 746 TLS 1.1 [TLS] or its successors, using the latest version 747 supported by both the client and the PKG. When requesting 748 the URI/IRI the client MUST verify the server certificate 749 [HTTPTLS], and MUST abort the key request if the server 750 certificate verification of the TLS connection fails. Doing 751 so is critical to protect the authentication credentials 752 and the private key against man-in-the-middle attacks when 753 it is transmitted from the key server to the client. 755 5.3. Request Structure 757 The POST method contains in its body the following XML 758 structure that MUST be encoded as an application/ibe-key- 759 request+xml MIME type: 761 762 763 764 765 766 767 768 algorithmOID 769 770 771 ibeIdentityInfo 772 773 774 775 ibeAuthData 776 777 778 780 A SHOULD include an element in 781 the part of a key request that contains an 782 ASCII string that identifies the client type and client 783 version. 785 A key request MUST contain an element that 786 contains the base64 [B64] encoding of a DER-encoded [DER] 787 object identifier that identifies the algorithm for which a 788 key is requested. OIDs for the BB1 and BF algorithms are 789 listed in [IBCS]. 791 A key request MUST contain an element that 792 contains the identity that the private key is being 793 requested for. This identity is the base64 [B64] encoding 794 of a DER-encoded [DER] ASN.1 structure. This structure 795 defines a user's identity in a way appropriate for the 796 application. An example of such a structure that is 797 appropriate for use in encrypting e-mail is defined in 798 [IBECMS]. 800 A key request MAY contain an element. This 801 element contains authentication information that the PKG 802 can use to determine whether or not a request for a 803 particular IBE private key should be granted. 805 A client MAY include optional additional XML elements in 806 the part of the key request. A PKG MUST be able 807 to process key requests that contain no such optional 808 elements. 810 5.4. The application/ibe-key-request+xml MIME type 812 The following summarizes the properties of the application/ 813 ibe-key-request+xml MIME type. 815 MIME media type name: application 817 MIME subtype name: ibe-key-request+xml 819 Mandatory parameters: none 821 Optional parameters: none 823 Encoding considerations: This media type MUST be encoded as 824 us-ascii [ASCII]. 826 Security considerations: The data conveyed in this media 827 type may contain authentication credentials. Because of 828 this, its confidentiality and integrity is extremely 829 important. To ensure this, the request for an IBE private 830 key must take place over a secure protocol, TLS 1.1 or its 831 successors. To ensure the validity of the server, the 832 client MUST verify the server certificate and MUST abort 833 the key request if the verification of the server 834 certificate of the TLS connection fails. This media type 835 contains no active content and does not use compression. 837 Interoperability considerations: There are no known 838 interoperability considerations for this media type. 840 Applications that use this media type: Applications that 841 implement IBE in compliance with this specification will 842 use this media type. The most commonly-used of these 843 applications are encrypted email and file encryption. 845 Additional information: none 847 Person and email address for further information: Luther 848 Martin, martin@voltage.com. 850 Intended usage: COMMON 852 Author/Change controller: Luther Martin, 853 martin@voltage.com. 855 5.5. Authentication 857 When a client requests a key from a PKG, the PKG MUST 858 authenticate the client before issuing the key. 859 Authentication may either be done through the key request 860 structure or as part of the secure transport protocol. 862 A client or server implementing the request protocol MUST 863 support HTTP Basic Auth [AUTH] and SHOULD also support HTTP 864 Digest Auth [AUTH]. Applications MAY also use other means 865 of authentication that are appropriate for the application. 866 An e-mail application, for example, might rely on deployed 867 e-mail infrastructure for this, for example. 869 For authentication methods that are not done by the 870 transport protocol, a client MAY include additional 871 authentication information in XML elements in the 872 element of a key request. If a client does 873 not know how to authenticate to a server, the client MAY 874 send a key request without authentication information. If 875 the key server requires the client to authenticate 876 externally, it MAY reply with an IBE201 responseCode as 877 defined below to redirect the client to the correct 878 authentication mechanism. After receiving an authentication 879 credential from this external mechanism, a client can then 880 use the credential to form a key request that contains the 881 additional authentication data. 883 5.6. Server Response Format 885 The key server replies to the HTTP request with an HTTP 886 response. If the response contains a client error or server 887 error status code, the client MUST abort the key request 888 and fail. 890 If the PKG replies with an HTTP response that has a status 891 code indicating success, the body of the reply MUST contain 892 the following XML structure that MUST be encoded as an 893 application/ibe-pkg-reply+xml MIME type: 895 896 897 898 bodyTags 899 900 901 The responseCode attribute contains an ASCII string that 902 describes the type of response from the key server. The 903 list of currently-defined responseCodes and their 904 associated meanings is: 906 IBE100 KEY_FOLLOWS 907 IBE101 RESERVED 908 IBE201 FOLLOW_ENROLL_URI 909 IBE300 SYSTEM_ERROR 910 IBE301 INVALID_REQUEST 911 IBE303 CLIENT_OBSOLETE 912 IBE304 AUTHORIZATION DENIED 914 5.6.1. The IBE100 responseCode 916 If the key request was successful, the key server responds 917 with a responseCode of IBE100, and the MUST 918 contain a element that contains a valid 919 private key. An example of this is shown below. 921 922 923 924 925 privateKey 926 927 928 930 The privateKey is the base64 [B64] encoding of the DER 931 encoding [DER] of the following structure: 933 IBEPrivateKeyReply ::= SEQUENCE { 934 pkgIdentity IBEIdentityInfo, 935 pgkAlgorithm OBJECT IDENTIFIER, 936 pkgKeyData OCTET STRING, 937 pkgOptions SEQUENCE SIZE (1..MAX) OF PKGOption 938 } 940 PKGOption ::= SEQUENCE { 941 optionID OBJECT IDENTIFIER, 942 optionValue OCTET STRING 943 } 945 The pkgIdentity is an IBEIdentityInfo structure that MUST 946 be identical to the IBEIdentityInfo structure that was sent 947 in the key request. 949 The pkgAlgorithm is an OID that identifies the algorithm of 950 the returned private key. The OIDs for the BB and BF 951 algorithms are defined in [IBCS]. 953 The pkgKeyData is a structure that contains the actual 954 private key. Private-key formats for the BB and BF 955 algorithms are defined in [IBCS]. 957 A server MAY pass back additional information to a client 958 in the pkgOptions structure. A client that receives a 959 IBEPrivateKeyReply from a PKG that contains information in 960 a pkgOptions structure that it is unable process MUST NOT 961 use the IBE private key in the IBEPrivateKeyReply structure 962 for any cryptographic operations. A client MUST be able to 963 process an IBEPrivateKeyReply that contains no PKGOptions 964 structure. 966 5.6.2. The IBE101 responseCode 968 The responseCode IBE101 is reserved to ensure 969 interoperability with earlier versions of the protocol that 970 is described in this document. An example of such a 971 response is shown below. A response with the IBE101 972 responseCode SHOULD contain no body. If information is 973 contained in the body of such a response, the client 974 receiving the response MUST discard any data that is 975 contained in the body. 977 978 979 980 This message must be discarded by the recipient 981 984 5.6.3. The IBE201 responseCode 986 A PKG MAY support authenticating users to external 987 authentication mechanisms. If this is the case, the server 988 replies to the client with responseCode IBE201 and the body 989 of the response MUST contain a element that 990 specifies the URI of the authentication mechanism. An 991 example of such a response is shown below. 993 994 995 996 998 999 1001 The client can now contact the URI returned in such a 1002 response using the same mechanisms as defined in Section 1003 4.2 to obtain an authentication credential. Once the client 1004 has obtained the credential from the authentication 1005 mechanism at this URI, it sends a new key request to the 1006 PKG with the correct authentication credentials contained 1007 in the request, placing the authentication credential in 1008 the element of a key request as described in 1009 Section 4.4. 1011 5.6.4. The IBE300 responseCode 1013 The IBE300 responseCode indicates that an internal server 1014 error has occurred. Information that may help diagnose the 1015 error MAY be included in the body of such a response. An 1016 example of such a response is shown below. Upon receiving a 1017 IBE300 responseCode, the client MUST abort the key request 1018 and discard any data that was included in the body of the 1019 response. 1021 1022 1023 1024 Widget phlebotomy failure 1025 1026 1028 5.6.5. The IBE301 responseCode 1030 The IBE303 responseCode indicates that an invalid key 1031 request has been received by the server. Information that 1032 may help diagnose the error MAY be included in the body of 1033 such a response. An example of such a response is shown 1034 below. Upon receiving an IBE301 responseCode, the client 1035 MUST abort the key request and discard any data that was 1036 included in the body of the response. 1038 1039 1040 1041 Some additional stuff 1042 1043 1045 5.6.6. The IBE303 responseCode 1047 The IBE303 responseCode indicates that the server is unable 1048 to correctly process the request because the version of the 1049 request is no longer supported by the server. Information 1050 that may help diagnose the error MAY be included in the 1051 body of such a response. An example of such a response is 1052 shown below. Upon receiving an IBE303 responseCode, the 1053 client MUST abort the key request and discard any data that 1054 was included in the body of the response. 1056 1057 1058 1059 Version 3.3 or later needed 1060 1061 1063 5.6.7. The IBE304 responseCode 1065 The IBE304 responseCode indicates that a valid key request 1066 has been received by the server but the authentication 1067 credentials provided were invalid. Information that may 1068 help diagnose the error MAY be included in the body of such 1069 a response. An example of such a response is shown below. 1070 Upon receiving an IBE304 responseCode, the client MUST 1071 abort the key request and discard any data that was 1072 included in the body of the response. 1074 1075 1076 1077 Helpful error message 1078 1079 1081 5.7. The application/ibe-pkg-reply+xml MIME type 1083 The following summarizes the properties of the 1084 application/ibe-pkg-reply+xml MIME type. 1086 MIME media type name: application 1088 MIME subtype name: ibe-pkg-reply+xml 1090 Mandatory parameters: none 1092 Optional parameters: none 1094 Encoding considerations: This media type MUST be encoded as 1095 us-ascii [ASCII]. 1097 Security considerations: The data conveyed as this media 1098 type is an IBE private key, so its confidentiality and 1099 integrity is extremely important. To ensure this, the 1100 response from the server that contains an IBE private key 1101 must take place over a secure protocol, TLS 1.1 or its 1102 successors. To ensure the validity of the server, the 1103 client MUST verify the server certificate and MUST abort 1104 the key request if the verification of the server 1105 certificate of the TLS connection fails. This media type 1106 contains no active content and does not use compression. 1108 Interoperability considerations: There are no known 1109 interoperability considerations for this media type. 1111 Applications that use this media type: Applications that 1112 implement IBE in compliance with this specification will 1113 use this media type. The most commonly-used of these 1114 applications are encrypted email and file encryption. 1116 Additional information: none 1118 Person and email address for further information: Luther 1119 Martin, martin@voltage.com. 1121 Intended usage: COMMON 1123 Author/Change controller: Luther Martin, 1124 martin@voltage.com. 1126 6. ASN.1 Module 1128 The following ASN.1 module summarizes the ASN.1 definitions 1129 discussed in this document. 1131 IBEARCH-module { joint-iso-itu-t(2) country(16) us(840) 1132 organization(1) identicrypt(114334) ibcs(1) ibearch(5) 1133 module(5) version(1) 1134 } 1136 DEFINITIONS IMPLICIT TAGS ::= BEGIN 1138 IBESysParams ::= SEQUENCE { 1139 version INTEGER { v2(2) }, 1140 districtName IA5String, 1141 districtSerial INTEGER, 1142 validity ValidityPeriod, 1143 ibePublicParameters IBEPublicParameters, 1144 ibeIdentityType OBJECT IDENTIFIER, 1145 ibeParamExtensions IBEParamExtensions OPTIONAL 1146 } 1148 ValidityPeriod ::= SEQUENCE { 1149 notBefore GeneralizedTime, 1150 notAfter GeneralizedTime 1151 } 1153 IBEPublicParameters ::= SEQUENCE (1..MAX) OF 1154 IBEPublicParameter 1156 IBEPublicParameter ::= SEQUENCE { 1157 ibeAlgorithm OBJECT IDENTIFIER, 1158 publicParameterData OCTET STRING 1159 } 1161 IBEParamExtensions ::= SEQUENCE OF IBEParamExtension 1163 IBEParamExtension ::= SEQUENCE { 1164 ibeParamExtensionOID OBJECT IDENTIFIER, 1165 ibeParamExtensionValue OCTET STRING 1166 } 1168 ibcs OBJECT IDENTIFIER ::= { 1169 joint-iso-itu-t(2) country(16) us(840) 1170 organization(1) identicrypt(114334) ibcs(1) 1171 } 1173 ibeParamExt OBJECT IDENTIFIER ::= { 1174 ibcs ibcs3(3) parameter-extensions(2) 1175 } 1177 pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) } 1178 IBEPrivateKeyReply ::= SEQUENCE { 1179 pkgIdentity IBEIdentityInfo, 1180 pgkAlgorithm OBJECT IDENTIFIER, 1181 pkgKeyData OCTET STRING, 1182 pkgOptions SEQUENCE SIZE (1..MAX) OF PKGOption 1183 } 1185 PKGOption ::= SEQUENCE { 1186 optionID OBJECT IDENTIFIER, 1187 optionValue OCTET STRING 1188 } 1190 uriPPSOID OBJECT IDENTIFIER ::= { 1191 joint-iso-itu-t(2) country(16) us(840) 1192 organization(1) identicrypt(114334) 1193 pps-schemas(3) ic-schemas(1) pps-uri(1) version(1) 1194 } 1196 IBEIdentityInfo ::= SEQUENCE { 1197 district IA5String, 1198 serial INTEGER, 1199 identityType OBJECT IDENTIFIER, 1200 identityData OCTET STRING 1201 } 1203 END 1205 7. Security Considerations 1207 7.1. Attacks outside the scope of this document 1209 Attacks on the cryptographic algorithms that are used to 1210 implement IBE are outside the scope of this document. Such 1211 attacks are detailed in [IBCS], which defines parameters 1212 that give 80-bit, 112-bit and 128-bit encryption strength. 1213 We assume that capable administrators of an IBE system will 1214 select parameters that provide a sufficient resistance to 1215 cryptanalytic attacks by adversaries. 1217 Attacks that give an adversary the ability to access or 1218 change the information on a PPS or PKG, especially the 1219 cryptographic material (referred to in this document as the 1220 master secret), will defeat the security of an IBE system. 1221 In particular, if the cryptographic material is compromised 1222 the adversary will have the ability to recreate any user's 1223 private key and therefore decrypt all messages protected 1224 with the corresponding public key. To address this concern, 1225 it is highly RECOMMENDED that best practices for physical 1226 and operational security for PPS and PKG servers be 1227 followed and that these servers be configured (sometimes 1228 known as hardened) in accordance with best current 1229 practices [NIST]. An IBE system SHOULD be operated in an 1230 environment where illicit access is infeasible for 1231 attackers to obtain. 1233 Attacks that require administrative or IBE user equivalent 1234 access to machines used by either the client or the server 1235 components defined in this document are also outside the 1236 scope of this document. 1238 We also assume that all administrators of a system 1239 implementing the protocols that are defined in this 1240 document are trustworthy and will not abuse their authority 1241 to bypass the security provided by an IBE system. 1242 Similarly, we assume that users of an IBE system will 1243 behave responsibly, not sharing their authentication 1244 credentials with others. Thus attacks that require such 1245 assumptions are outside the scope of this document. 1247 7.2. Attacks within the scope of this document 1249 Attacks within the scope of this document are those that 1250 allow an adversary to: 1252 o passively monitor information transmitted between 1253 users of an IBE system and the PPS and PKG 1255 o masquerade as a PPS or PKG 1257 o perform a DOS attack on a PPS or PKG 1259 o easily guess an IBE users authentication 1260 credential 1262 7.2.1. Attacks on the protocols defined in this document 1264 All communications between users of an IBE system and the 1265 PPS or PKG are protected using TLS 1.1 [TLS]. The IBE 1266 system defined in this document provides no additional 1267 security protections for the communications between IBE 1268 users and the PPS or PKG. Therefore the described IBE 1269 system is completely dependent on the TLS security 1270 mechanisms for authentication of the PKG or PPS server and 1271 for confidentiality and integrity of the communications. 1272 Should there be a compromise of the TLS security 1273 mechanisms, the integrity of all communications between an 1274 IBE user and the PPS or PKG will be suspect. 1276 The protocols defined in this document do not explicitly 1277 defend against an attacker masquerading as a legitimate IBE 1278 PPS or PKG. The protocols rely on the server authentication 1279 mechanism of TLS [TLS]. In addition to the TLS server 1280 authentication mechanism IBE client software can provide 1281 protection against this possibility by providing user 1282 interface capabilities that allows users to visually 1283 determine that a connection to PPS and PKG servers is 1284 legitimate. This additional capability can help ensure that 1285 users cannot easily be tricked into providing valid 1286 authorization credentials to an attacker. 1288 The protocols defined in this document are also vulnerable 1289 to attacks against an IBE PPS or PKG. Denial of service 1290 attacks against either component can result in users unable 1291 to encrypt or decrypt using IBE, and users of an IBE system 1292 SHOULD take the appropriate countermeasures [DOS, BGPDOS] 1293 that their use of IBE requires. 1295 The IBE user authentication method selected by an IBE PKG 1296 SHOULD be of sufficient strength to prevent attackers from 1297 easily guessing the IBE user's authentication credentials 1298 through trial and error. 1300 8. IANA Considerations 1302 8.1. Media types 1304 This specification proposes the registration of three media 1305 types in the standard registration tree. These are 1306 application/ibe-pp-data, application/ibe-key-request+xml, 1307 and application/ibe-pkg-reply+xml. The media type 1308 application/ibe-pp-data is defined in Section 4.3 of this 1309 document. The media type application/ibe-key-request+xml is 1310 defined in Section 5.4 of this document. The media type 1311 application/ibe-pkg-reply+xml is defined in Section 5.7 of 1312 this document. 1314 8.2. XML namespace 1316 The IANA is requested to register the following namespace 1317 identifier: 1319 urn:ietf:params:xml:ns:ibe 1321 Registrant Contact: 1323 Luther Martin 1324 Voltage Security 1325 1070 Arastradero Rd Suite 100 1326 Palo Alto CA 94304 1328 Phone: +1 650 543 1280 1329 Email: martin@voltage.com 1331 XML: 1333 BEGIN 1334 1335 1336 1337 1338 1339 1340 1341 algorithmOID 1342 1343 1344 ibeIdentityInfo 1345 1346 1347 1348 ibeAuthData 1349 1350 1351 1353 1354 1355 1356 bodyTags 1357 1358 1359 END 1361 9. References 1363 9.1. Normative References 1365 [ASCII] ISO/IEC 646:1991 - Information Technology - ISO 7- 1366 bit Coded Character Set for Information Exchange 1368 [ASN1] ITU-T Recommendation X.680: Information Technology - 1369 Abstract Syntax Notation One, 1997. 1371 [AUTH] J. Franks, et al., "HTTP Authentication: Basic and 1372 Digest Access Authentication", RFC 2617, June 1999. 1374 [B64] N. Freed and N. Borenstein, "Multipurpose Internet 1375 Mail Extensions(MIME) Part One: Format of Internet 1376 Message Bodies," RFC 2045, November 1996. 1378 [CMS] R. Housley, "Cryptographic Message Syntax (CMS)," RFC 1379 3852, July 2004. 1381 [DER] ITU-T Recommendation X.690: OSI Networking and System 1382 Aspects: Abstract Syntax Notation One (ASN.1), July 1383 2002. 1385 [DOS] P. Ferguson and D. Senie, "Network Ingress Filtering: 1386 Defeating Denial of Service Attacks which employ IP 1387 Source Address Spoofing," RFC 2827, BCP 38, May 2000. 1389 [HTTP] R. Fielding, et al., "Hypertext Transfer Protocol -- 1390 HTTP/1.1", RFC 2616, June 1999. 1392 [HTTPTLS] E. Rescorla, "HTTP over TLS," RFC 2818, May 2000. 1394 [IBCS] X. Boyen and L. Martin, "Identity-Based Cryptography 1395 Standard (IBCS) #1: Supersingular Curve 1396 Implementations of the BF and BB1 Cryptosystems," RFC 1397 5091, December 2007. 1399 [IRI] M. Deurst and M. Suignard, "Internationalized 1400 Resource Identifiers (IRIs)," RFC 3987, January 2005. 1402 [KEY] S. Brander, "Key Words for Use in RFCs to Indicate 1403 Requirement Levels," BCP 14, RFC 2119, March 1997. 1405 [PKIX] D. Cooper, et al., "Internet X.509 Public Key 1406 Infrastructure Certificate and Certificate Revocation 1407 List (CRL) Profile," RFC 5280, May 2008 1409 [SMTP] J. Klensin, "Simple Mail Transfer Protocol," RFC 1410 5321, October 2008. 1412 [TLS] T. Dierks and E. Rescorla, "The Transport Layer 1413 Security (TLS) Protocol Version 1.1," RFC 4346, April 1414 2006. 1416 [URI] T. Berners-Lee, R. Fielding, and L. Masinter, 1417 "Uniform Resource Identifier (URI): Generic Syntax", 1418 STD 66, RFC 3986, January 2005. 1420 [XML] W3C, Extensible Markup Language (XML) 1.0 (Fourth 1421 Edition), September 2006. 1423 9.2. Informative References 1425 [BGPDOS] D. Turk, "Configuring BGP to Block Denial-of- 1426 Service Attacks," RFC 3882, September 2004. 1428 [IBECMS] L. Martin and M. Schertler, "Using the Boneh- 1429 Franklin identity-based encryption algorithm with the 1430 Cryptographic Message Syntax (CMS)," draft-ietf- 1431 smime-bfibecms-10.txt, July 2008. 1433 [NIST] M. Souppaya, J. Wack and K. Kent, "Security 1434 Configuration Checklist Program for IT Products - 1435 Guidance for Checklist Users and Developers," NIST 1436 Special Publication SP 800-70, May 2005. 1438 [P1363] IEEE P1363, "Standard Specifications for Public-Key 1439 Cryptography," 2001. 1441 Authors' Addresses 1443 Guido Appenzeller 1444 Stanford University 1445 Gates Building 3A 1446 Stanford, CA 94305 1448 Phone: +1 650 732 2273 1449 Email: appenz@cs.stanford.edu 1451 Luther Martin 1452 Voltage Security 1453 1070 Arastradero Rd Suite 100 1454 Palo Alto CA 94304 1455 USA 1457 Phone: +1 650 543 1280 1458 Email: martin@voltage.com 1460 Mark Schertler 1461 Tumbleweed Communications 1462 700 Saginaw Dr 1463 Redwood City CA 94063 1464 USA 1466 Phone: +1 650 216 2039 1467 Email: mark.schertler@tumbleweed.com 1469 Intellectual Property Statement 1471 The IETF takes no position regarding the validity or scope 1472 of any Intellectual Property Rights or other rights that 1473 might be claimed to pertain to the implementation or use of 1474 the technology described in this document or the extent to 1475 which any license under such rights might or might not be 1476 available; nor does it represent that it has made any 1477 independent effort to identify any such rights. 1478 Information on the procedures with respect to rights in RFC 1479 documents can be found in BCP 78 and BCP 79. 1481 Copies of IPR disclosures made to the IETF Secretariat and 1482 any assurances of licenses to be made available, or the 1483 result of an attempt made to obtain a general license or 1484 permission for the use of such proprietary rights by 1485 implementers or users of this specification can be obtained 1486 from the IETF on-line IPR repository at 1487 http://www.ietf.org/ipr. 1489 The IETF invites any interested party to bring to its 1490 attention any copyrights, patents or patent applications, 1491 or other proprietary rights that may cover technology that 1492 may be required to implement this standard. Please address 1493 the information to the IETF at ietf-ipr@ietf.org. 1495 Disclaimer of Validity 1497 This document and the information contained herein are 1498 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 1499 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 1500 THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET 1501 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1502 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 1503 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 1504 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR 1505 A PARTICULAR PURPOSE. 1507 Copyright Statement 1509 Copyright (C) The IETF Trust (2008). 1511 This document is subject to the rights, licenses and 1512 restrictions contained in BCP 78, and except as set forth 1513 therein, the authors retain all their rights. 1515 Acknowledgment 1517 Funding for the RFC Editor function is currently provided 1518 by the Internet Society.