idnits 2.17.1 draft-ietf-smime-ibearch-08.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 1540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1528. 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 (September 2008) is 5695 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 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 8 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: March 2009 Tumbleweed Communications 8 September 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.........................22 74 5.6.1. The IBE100 responseCode...................22 75 5.6.2. The IBE101 responseCode...................24 76 5.6.3. The IBE201 responseCode...................24 77 5.6.4. The IBE300 responseCode...................25 78 5.6.5. The IBE301 responseCode...................25 79 5.6.6. The IBE303 responseCode...................25 80 5.6.7. The IBE304 responseCode...................26 81 5.7. The application/ibe-pkg-reply+xml MIME type....26 82 6. ASN.1 Module........................................27 83 7. Security Considerations.............................29 84 7.1. Attacks outside the scope of this document.....29 85 7.2. Attacks within the scope of this document......30 86 7.2.1. Attacks on the protocols defined in this 87 document.........................................30 88 8. IANA Considerations.................................31 89 8.1. Media types....................................31 90 8.2. XML namespace..................................31 91 9. References..........................................33 92 9.1. Normative References...........................33 93 9.2. Informative References.........................34 94 Authors' Addresses.....................................35 95 Intellectual Property Statement........................35 96 Disclaimer of Validity.................................36 97 Copyright Statement....................................36 98 Acknowledgment.........................................36 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: The single required parameter is a 663 base64-encoded DER-encoded IBESysParams structure. 665 Optional parameters: There are no optional parameters. 667 Encoding considerations: This media type MUST be encoded as 668 7bit (us-ascii text [ASCII]). 670 Security considerations: The data conveyed as this media 671 type are the public parameters needed for the operation of 672 a cryptographic system. To ensure that the parameters can 673 be trusted, the request for these parameters must take 674 place over a secure protocol, TLS 1.1 or its successors. To 675 ensure the validity of the server, the client MUST verify 676 the server certificate and MUST abort the parameter request 677 if the verification of the server certificate of the TLS 678 connection fails. This media type contains no active 679 content and does not use compression. 681 Interoperability considerations: There are no known 682 interoperability considerations for this media type. 684 Applications that use this media type: Applications that 685 implement IBE in compliance with this specification will 686 use this media type. The most commonly-used of these 687 applications are encrypted email and file encryption. 689 Additional information: This media type is used for the 690 response from a public parameter server after receiving a 691 request for IBE public parameters. This media type contains 692 no active content and does not use compression. 694 Person and email address for further information: Luther 695 Martin, martin@voltage.com. 697 Intended usage: COMMON. 699 Author/Change controller: Luther Martin, 700 martin@voltage.com. 702 5. Private Key Request Protocol 704 5.1. Overview 706 When requesting a private key, a client has to transmit 707 three parameters: 709 1. The IBE algorithm for which the key is being 710 requested 712 2. The identity for which it is requesting a key 714 3. Authentication credentials for the individual 715 requesting the key 717 These two are often not the same as a single user may have 718 access to multiple aliases. For example an email user may 719 have access to the keys that correspond to two different 720 email addresses, e.g. bob@example.com and 721 bob.smith@example.com. 723 This section defines the protocol to request private keys, 724 a minimum user authentication method for interoperability, 725 and how to pass authentication credentials to the server. 726 It assumes that a client has already determined the URI/IRI 727 of the PKG. This can be done from information included in 728 the IBE message format and the public parameters of the IBE 729 system. 731 The technique for fetching an IBE private key using the 732 process defined in this section is indicated by the OBJECT 733 IDENTIFIER pkgURI, which is defined to be the following: 735 ibcs OBJECT IDENTIFIER ::= { 736 joint-iso-itu-t(2) country(16) us(840) 737 organization(1) identicrypt(114334) ibcs(1) 738 } 740 ibeParamExt OBJECT IDENTIFIER ::= { 741 ibcs ibcs3(3) parameter-extensions(2) 742 } 744 pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) } 746 5.2. Private Key Request 748 To request a private key, a client MUST perform a HTTP POST 749 method as defined in [HTTP]. The request MUST take place 750 over a secure protocol. The requesting client MUST support 751 TLS 1.1 [TLS] or its successors, using the latest version 752 supported by both the client and the PKG. When requesting 753 the URI/IRI the client MUST verify the server certificate 754 [HTTPTLS], and MUST abort the key request if the server 755 certificate verification of the TLS connection fails. Doing 756 so is critical to protect the authentication credentials 757 and the private key against man-in-the-middle attacks when 758 it is transmitted from the key server to the client. 760 5.3. Request Structure 762 The POST method contains in its body the following XML 763 structure that MUST be encoded as an application/ibe-key- 764 request+xml MIME type: 766 767 768 769 770 771 772 773 algorithmOID 774 775 776 ibeIdentityInfo 777 778 779 780 ibeAuthData 781 782 783 785 A SHOULD include an element in 786 the part of a key request that contains an 787 ASCII string that identifies the client type and client 788 version. 790 A key request MUST contain an element that 791 contains the base64 [B64] encoding of a DER-encoded [DER] 792 object identifier that identifies the algorithm for which a 793 key is requested. OIDs for the BB1 and BF algorithms are 794 listed in [IBCS]. 796 A key request MUST contain an element that 797 contains the identity that the private key is being 798 requested for. This identity is the base64 [B64] encoding 799 of a DER-encoded [DER] ASN.1 structure. This structure 800 defines a user's identity in a way appropriate for the 801 application. An example of such a structure that is 802 appropriate for use in encrypting e-mail is defined in 803 [IBECMS]. 805 A key request MAY contain an element. This 806 element contains authentication information that the PKG 807 can use to determine whether or not a request for a 808 particular IBE private key should be granted. 810 A client MAY include optional additional XML elements in 811 the part of the key request. A PKG MUST be able 812 to process key requests that contain no such optional 813 elements. 815 5.4. The application/ibe-key-request+xml MIME type 817 The following summarizes the properties of the application/ 818 ibe-key-request+xml MIME type. 820 MIME media type name: application 822 MIME subtype name: ibe-key-request+xml 824 Mandatory parameters: The required parameters are the 825 identity for which an IBE private key is being requested 826 and an object identifier that identifies which 827 cryptographic algorithm the key is being requested for. The 828 identity is the base64-encoding of a DER-encoded 829 ibeIdentityInfo structure. The object identifier is the 830 base64-encoding of a DER-encoded object identifier, like 831 those defined in [IBCS]. 833 Optional parameters: Any optional parameters may be defined 834 by an administrator of a particular PKG. The most common 835 optional parameter is an authentication credential. A PKG 836 may redirect a request for an IBE private key to an 837 external authentication mechanism, the reply from which is 838 then included as this optional parameter in a subsequent 839 key request. Other optional parameters may include other 840 information as required by particular implementations. An 841 example of this from an existing implementation is a bank 842 that has clients pass branding information along with a key 843 request so that mortgage customers see a different user 844 interface than non-mortgage customers do, for example. 846 Encoding considerations: This media type MUST be encoded as 847 us-ascii [ASCII]. 849 Security considerations: The data conveyed in this media 850 type may contain authentication credentials. Because of 851 this, its confidentiality and integrity is extremely 852 important. To ensure this, the request for an IBE private 853 key must take place over a secure protocol, TLS 1.1 or its 854 successors. To ensure the validity of the server, the 855 client MUST verify the server certificate and MUST abort 856 the key request if the verification of the server 857 certificate of the TLS connection fails. This media type 858 contains no active content and does not use compression. 860 Interoperability considerations: There are no known 861 interoperability considerations for this media type. 863 Applications that use this media type: Applications that 864 implement IBE in compliance with this specification will 865 use this media type. The most commonly-used of these 866 applications are encrypted email and file encryption. 868 Additional information: This media type is used for the 869 data that is passed to an IBE PKG by a client requesting an 870 IBE private key. This media type contains no active content 871 and does not use compression. 873 Person and email address for further information: Luther 874 Martin, martin@voltage.com. 876 Intended usage: COMMON. 878 Author/Change controller: Luther Martin, 879 martin@voltage.com. 881 5.5. Authentication 883 When a client requests a key from a PKG, the PKG MUST 884 authenticate the client before issuing the key. 885 Authentication may either be done through the key request 886 structure or as part of the secure transport protocol. 888 A client or server implementing the request protocol MUST 889 support HTTP Basic Auth [AUTH] and SHOULD also support HTTP 890 Digest Auth [AUTH]. Applications MAY also use other means 891 of authentication that are appropriate for the application. 892 An e-mail application, for example, might rely on deployed 893 e-mail infrastructure for this, for example. 895 For authentication methods that are not done by the 896 transport protocol, a client MAY include additional 897 authentication information in XML elements in the 898 element of a key request. If a client does 899 not know how to authenticate to a server, the client MAY 900 send a key request without authentication information. If 901 the key server requires the client to authenticate 902 externally, it MAY reply with an IBE201 responseCode as 903 defined below to redirect the client to the correct 904 authentication mechanism. After receiving an authentication 905 credential from this external mechanism, a client can then 906 use the credential to form a key request that contains the 907 additional authentication data. 909 5.6. Server Response Format 911 The key server replies to the HTTP request with an HTTP 912 response. If the response contains a client error or server 913 error status code, the client MUST abort the key request 914 and fail. 916 If the PKG replies with an HTTP response that has a status 917 code indicating success, the body of the reply MUST contain 918 the following XML structure that MUST be encoded as an 919 application/ibe-pkg-reply+xml MIME type: 921 922 923 924 bodyTags 925 926 928 The responseCode attribute contains an ASCII string that 929 describes the type of response from the key server. The 930 list of currently-defined responseCodes and their 931 associated meanings is: 933 IBE100 KEY_FOLLOWS 934 IBE101 RESERVED 935 IBE201 FOLLOW_ENROLL_URI 936 IBE300 SYSTEM_ERROR 937 IBE301 INVALID_REQUEST 938 IBE303 CLIENT_OBSOLETE 939 IBE304 AUTHORIZATION DENIED 941 5.6.1. The IBE100 responseCode 943 If the key request was successful, the key server responds 944 with a responseCode of IBE100, and the MUST 945 contain a element that contains a valid 946 private key. An example of this is shown below. 948 949 950 951 952 privateKey 953 954 955 957 The privateKey is the base64 [B64] encoding of the DER 958 encoding [DER] of the following structure: 960 IBEPrivateKeyReply ::= SEQUENCE { 961 pkgIdentity IBEIdentityInfo, 962 pgkAlgorithm OBJECT IDENTIFIER, 963 pkgKeyData OCTET STRING, 964 pkgOptions SEQUENCE SIZE (1..MAX) OF PKGOption 965 } 967 PKGOption ::= SEQUENCE { 968 optionID OBJECT IDENTIFIER, 969 optionValue OCTET STRING 970 } 972 The pkgIdentity is an IBEIdentityInfo structure that MUST 973 be identical to the IBEIdentityInfo structure that was sent 974 in the key request. 976 The pkgAlgorithm is an OID that identifies the algorithm of 977 the returned private key. The OIDs for the BB and BF 978 algorithms are defined in [IBCS]. 980 The pkgKeyData is a structure that contains the actual 981 private key. Private-key formats for the BB and BF 982 algorithms are defined in [IBCS]. 984 A server MAY pass back additional information to a client 985 in the pkgOptions structure. A client that receives a 986 IBEPrivateKeyReply from a PKG that contains information in 987 a pkgOptions structure that it is unable process MUST NOT 988 use the IBE private key in the IBEPrivateKeyReply structure 989 for any cryptographic operations. A client MUST be able to 990 process an IBEPrivateKeyReply that contains no PKGOptions 991 structure. 993 5.6.2. The IBE101 responseCode 995 The responseCode IBE101 is reserved to ensure 996 interoperability with earlier versions of the protocol that 997 is described in this document. An example of such a 998 response is shown below. A response with the IBE101 999 responseCode SHOULD contain no body. If information is 1000 contained in the body of such a response, the client 1001 receiving the response MUST discard any data that is 1002 contained in the body. 1004 1005 1006 1007 This message must be discarded by the recipient 1008 1011 5.6.3. The IBE201 responseCode 1013 A PKG MAY support authenticating users to external 1014 authentication mechanisms. If this is the case, the server 1015 replies to the client with responseCode IBE201 and the body 1016 of the response MUST contain a element that 1017 specifies the URI of the authentication mechanism. An 1018 example of such a response is shown below. 1020 1021 1022 1023 1025 1026 1028 The client can now contact the URI returned in such a 1029 response using the same mechanisms as defined in Section 1030 4.2 to obtain an authentication credential. Once the client 1031 has obtained the credential from the authentication 1032 mechanism at this URI, it sends a new key request to the 1033 PKG with the correct authentication credentials contained 1034 in the request, placing the authentication credential in 1035 the element of a key request as described in 1036 Section 4.4. 1038 5.6.4. The IBE300 responseCode 1040 The IBE300 responseCode indicates that an internal server 1041 error has occurred. Information that may help diagnose the 1042 error MAY be included in the body of such a response. An 1043 example of such a response is shown below. Upon receiving a 1044 IBE300 responseCode, the client MUST abort the key request 1045 and discard any data that was included in the body of the 1046 response. 1048 1049 1050 1051 Widget phlebotomy failure 1052 1053 1055 5.6.5. The IBE301 responseCode 1057 The IBE303 responseCode indicates that an invalid key 1058 request has been received by the server. Information that 1059 may help diagnose the error MAY be included in the body of 1060 such a response. An example of such a response is shown 1061 below. Upon receiving an IBE301 responseCode, the client 1062 MUST abort the key request and discard any data that was 1063 included in the body of the response. 1065 1066 1067 1068 Some additional stuff 1069 1070 1072 5.6.6. The IBE303 responseCode 1074 The IBE303 responseCode indicates that the server is unable 1075 to correctly process the request because the version of the 1076 request is no longer supported by the server. Information 1077 that may help diagnose the error MAY be included in the 1078 body of such a response. An example of such a response is 1079 shown below. Upon receiving an IBE303 responseCode, the 1080 client MUST abort the key request and discard any data that 1081 was included in the body of the response. 1083 1084 1085 1086 Version 3.3 or later needed 1087 1088 1090 5.6.7. The IBE304 responseCode 1092 The IBE304 responseCode indicates that a valid key request 1093 has been received by the server but the authentication 1094 credentials provided were invalid. Information that may 1095 help diagnose the error MAY be included in the body of such 1096 a response. An example of such a response is shown below. 1097 Upon receiving an IBE304 responseCode, the client MUST 1098 abort the key request and discard any data that was 1099 included in the body of the response. 1101 1102 1103 1104 Helpful error message 1105 1106 1108 5.7. The application/ibe-pkg-reply+xml MIME type 1110 The following summarizes the properties of the 1111 application/ibe-pkg-reply+xml MIME type. 1113 MIME media type name: application 1115 MIME subtype name: ibe-pkg-reply+xml 1117 Mandatory parameters: The only required parameter is a 1118 response code which indicates the status of a key request. 1119 Other parameters may be also required, depending on the 1120 nature of the response from the PKG. For example, for the 1121 responseCode IBE100 ("key follows"), an IBE private key is 1122 also a required parameter. 1124 Optional parameters: None. 1126 Encoding considerations: This media type MUST be encoded as 1127 us-ascii [ASCII]. 1129 Security considerations: The data conveyed as this media 1130 type is an IBE private key, so its confidentiality and 1131 integrity is extremely important. To ensure this, the 1132 response from the server that contains an IBE private key 1133 must take place over a secure protocol, TLS 1.1 or its 1134 successors. To ensure the validity of the server, the 1135 client MUST verify the server certificate and MUST abort 1136 the key request if the verification of the server 1137 certificate of the TLS connection fails. This media type 1138 contains no active content and does not use compression. 1140 Interoperability considerations: There are no known 1141 interoperability considerations for this media type. 1143 Applications that use this media type: Applications that 1144 implement IBE in compliance with this specification will 1145 use this media type. The most commonly-used of these 1146 applications are encrypted email and file encryption. 1148 Additional information: This media type is used for the 1149 response from a PKG after receiving a request for an IBE 1150 private key. This media type contains no active content and 1151 does not use compression. 1153 Person and email address for further information: Luther 1154 Martin, martin@voltage.com. 1156 Intended usage: COMMON. 1158 Author/Change controller: Luther Martin, 1159 martin@voltage.com. 1161 6. ASN.1 Module 1163 The following ASN.1 module summarizes the ASN.1 definitions 1164 discussed in this document. 1166 IBEARCH-module { joint-iso-itu-t(2) country(16) us(840) 1167 organization(1) identicrypt(114334) ibcs(1) ibearch(5) 1168 module(5) version(1) 1169 } 1171 DEFINITIONS IMPLICIT TAGS ::= BEGIN 1173 IBESysParams ::= SEQUENCE { 1174 version INTEGER { v2(2) }, 1175 districtName IA5String, 1176 districtSerial INTEGER, 1177 validity ValidityPeriod, 1178 ibePublicParameters IBEPublicParameters, 1179 ibeIdentityType OBJECT IDENTIFIER, 1180 ibeParamExtensions IBEParamExtensions OPTIONAL 1181 } 1183 ValidityPeriod ::= SEQUENCE { 1184 notBefore GeneralizedTime, 1185 notAfter GeneralizedTime 1186 } 1188 IBEPublicParameters ::= SEQUENCE (1..MAX) OF 1189 IBEPublicParameter 1191 IBEPublicParameter ::= SEQUENCE { 1192 ibeAlgorithm OBJECT IDENTIFIER, 1193 publicParameterData OCTET STRING 1194 } 1196 IBEParamExtensions ::= SEQUENCE OF IBEParamExtension 1198 IBEParamExtension ::= SEQUENCE { 1199 ibeParamExtensionOID OBJECT IDENTIFIER, 1200 ibeParamExtensionValue OCTET STRING 1201 } 1203 ibcs OBJECT IDENTIFIER ::= { 1204 joint-iso-itu-t(2) country(16) us(840) 1205 organization(1) identicrypt(114334) ibcs(1) 1206 } 1208 ibeParamExt OBJECT IDENTIFIER ::= { 1209 ibcs ibcs3(3) parameter-extensions(2) 1210 } 1212 pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) } 1213 IBEPrivateKeyReply ::= SEQUENCE { 1214 pkgIdentity IBEIdentityInfo, 1215 pgkAlgorithm OBJECT IDENTIFIER, 1216 pkgKeyData OCTET STRING, 1217 pkgOptions SEQUENCE SIZE (1..MAX) OF PKGOption 1218 } 1220 PKGOption ::= SEQUENCE { 1221 optionID OBJECT IDENTIFIER, 1222 optionValue OCTET STRING 1223 } 1225 uriPPSOID OBJECT IDENTIFIER ::= { 1226 joint-iso-itu-t(2) country(16) us(840) 1227 organization(1) identicrypt(114334) 1228 pps-schemas(3) ic-schemas(1) pps-uri(1) version(1) 1229 } 1231 IBEIdentityInfo ::= SEQUENCE { 1232 district IA5String, 1233 serial INTEGER, 1234 identityType OBJECT IDENTIFIER, 1235 identityData OCTET STRING 1236 } 1238 END 1240 7. Security Considerations 1242 7.1. Attacks outside the scope of this document 1244 Attacks on the cryptographic algorithms that are used to 1245 implement IBE are outside the scope of this document. Such 1246 attacks are detailed in [IBCS], which defines parameters 1247 that give 80-bit, 112-bit and 128-bit encryption strength. 1248 We assume that capable administrators of an IBE system will 1249 select parameters that provide a sufficient resistance to 1250 cryptanalytic attacks by adversaries. 1252 Attacks that give an adversary the ability to access or 1253 change the information on a PPS or PKG, especially the 1254 cryptographic material (referred to in this document as the 1255 master secret), will defeat the security of an IBE system. 1256 In particular, if the cryptographic material is compromised 1257 the adversary will have the ability to recreate any user's 1258 private key and therefore decrypt all messages protected 1259 with the corresponding public key. To address this concern, 1260 it is highly RECOMMENDED that best practices for physical 1261 and operational security for PPS and PKG servers be 1262 followed and that these servers be configured (sometimes 1263 known as hardened) in accordance with best current 1264 practices [NIST]. An IBE system SHOULD be operated in an 1265 environment where illicit access is infeasible for 1266 attackers to obtain. 1268 Attacks that require administrative or IBE user equivalent 1269 access to machines used by either the client or the server 1270 components defined in this document are also outside the 1271 scope of this document. 1273 We also assume that all administrators of a system 1274 implementing the protocols that are defined in this 1275 document are trustworthy and will not abuse their authority 1276 to bypass the security provided by an IBE system. 1277 Similarly, we assume that users of an IBE system will 1278 behave responsibly, not sharing their authentication 1279 credentials with others. Thus attacks that require such 1280 assumptions are outside the scope of this document. 1282 7.2. Attacks within the scope of this document 1284 Attacks within the scope of this document are those that 1285 allow an adversary to: 1287 o passively monitor information transmitted between 1288 users of an IBE system and the PPS and PKG 1290 o masquerade as a PPS or PKG 1292 o perform a DOS attack on a PPS or PKG 1294 o easily guess an IBE users authentication 1295 credential 1297 7.2.1. Attacks on the protocols defined in this document 1299 All communications between users of an IBE system and the 1300 PPS or PKG are protected using TLS 1.1 [TLS]. The IBE 1301 system defined in this document provides no additional 1302 security protections for the communications between IBE 1303 users and the PPS or PKG. Therefore the described IBE 1304 system is completely dependent on the TLS security 1305 mechanisms for authentication of the PKG or PPS server and 1306 for confidentiality and integrity of the communications. 1307 Should there be a compromise of the TLS security 1308 mechanisms, the integrity of all communications between an 1309 IBE user and the PPS or PKG will be suspect. 1311 The protocols defined in this document do not explicitly 1312 defend against an attacker masquerading as a legitimate IBE 1313 PPS or PKG. The protocols rely on the server authentication 1314 mechanism of TLS [TLS]. In addition to the TLS server 1315 authentication mechanism IBE client software can provide 1316 protection against this possibility by providing user 1317 interface capabilities that allows users to visually 1318 determine that a connection to PPS and PKG servers is 1319 legitimate. This additional capability can help ensure that 1320 users cannot easily be tricked into providing valid 1321 authorization credentials to an attacker. 1323 The protocols defined in this document are also vulnerable 1324 to attacks against an IBE PPS or PKG. Denial of service 1325 attacks against either component can result in users unable 1326 to encrypt or decrypt using IBE, and users of an IBE system 1327 SHOULD take the appropriate countermeasures [DOS, BGPDOS] 1328 that their use of IBE requires. 1330 The IBE user authentication method selected by an IBE PKG 1331 SHOULD be of sufficient strength to prevent attackers from 1332 easily guessing the IBE user's authentication credentials 1333 through trial and error. 1335 8. IANA Considerations 1337 8.1. Media types 1339 This specification proposes the registration of three media 1340 types in the standard registration tree. These are 1341 application/ibe-pp-data, application/ibe-key-request+xml, 1342 and application/ibe-pkg-reply+xml. The media type 1343 application/ibe-pp-data is defined in Section 3.3 of this 1344 document. The media type application/ibe-key-request+xml is 1345 defined in Section 4.4 of this document. The media type 1346 application/ibe-pkg-reply+xml is defined in Section 4.7 of 1347 this document. 1349 8.2. XML namespace 1351 The IANA is requested to register the following namespace 1352 identifier: 1354 urn:ietf:params:xml:ns:ibe 1356 Registrant Contact: 1358 Luther Martin 1359 Voltage Security 1360 1070 Arastradero Rd Suite 100 1361 Palo Alto CA 94304 1363 Phone: +1 650 543 1280 1364 Email: martin@voltage.com 1366 XML: 1368 BEGIN 1369 1370 1371 1372 1373 1374 1375 1376 algorithmOID 1377 1378 1379 ibeIdentityInfo 1380 1381 1382 1383 ibeAuthData 1384 1385 1386 1388 1389 1390 1391 bodyTags 1392 1393 1394 END 1396 9. References 1398 9.1. Normative References 1400 [ASCII] ISO/IEC 646:1991 - Information Technology - ISO 7- 1401 bit Coded Character Set for Information Exchange 1403 [ASN1] ITU-T Recommendation X.680: Information Technology - 1404 Abstract Syntax Notation One, 1997. 1406 [AUTH] J. Franks, et al., "HTTP Authentication: Basic and 1407 Digest Access Authentication", RFC 2617, June 1999. 1409 [B64] N. Freed and N. Borenstein, "Multipurpose Internet 1410 Mail Extensions(MIME) Part One: Format of Internet 1411 Message Bodies," RFC 2045, November 1996. 1413 [CMS] R. Housley, "Cryptographic Message Syntax (CMS)," RFC 1414 3852, July 2004. 1416 [DER] ITU-T Recommendation X.690: OSI Networking and System 1417 Aspects: Abstract Syntax Notation One (ASN.1), July 1418 2002. 1420 [DOS] P. Ferguson and D. Senie, "Network Ingress Filtering: 1421 Defeating Denial of Service Attacks which employ IP 1422 Source Address Spoofing," RFC 2827, BCP 38, May 2000. 1424 [HTTP] R. Fielding, et al., "Hypertext Transfer Protocol -- 1425 HTTP/1.1", RFC 2616, June 1999. 1427 [HTTPTLS] E. Rescorla, "HTTP over TLS," RFC 2818, May 2000. 1429 [IBCS] X. Boyen and L. Martin, "Identity-Based Cryptography 1430 Standard (IBCS) #1: Supersingular Curve 1431 Implementations of the BF and BB1 Cryptosystems," RFC 1432 5091, December 2007. 1434 [IRI] M. Deurst and M. Suignard, "Internationalized 1435 Resource Identifiers (IRIs)," RFC 3987, January 2005. 1437 [KEY] S. Brander, "Key Words for Use in RFCs to Indicate 1438 Requirement Levels," BCP 14, RFC 2119, March 1997. 1440 [PKIX] D. Cooper, et al., "Internet X.509 Public Key 1441 Infrastructure Certificate and Certificate Revocation 1442 List (CRL) Profile," RFC 5280, May 2008 1444 [SMTP] J. Klensin (ed.), "Simple Mail Transfer Protocol," 1445 RFC 2821, April 2001. 1447 [TLS] T. Dierks and E. Rescorla, "The Transport Layer 1448 Security (TLS) Protocol Version 1.1," RFC 4346, April 1449 2006. 1451 [URI] T. Berners-Lee, R. Fielding, and L. Masinter, 1452 "Uniform Resource Identifier (URI): Generic Syntax", 1453 STD 66, RFC 3986, January 2005. 1455 [XML] W3C, Extensible Markup Language (XML) 1.0 (Fourth 1456 Edition), September 2006. 1458 9.2. Informative References 1460 [BGPDOS] D. Turk, "Configuring BGP to Block Denial-of- 1461 Service Attacks," RFC 3882, September 2004. 1463 [IBECMS] L. Martin and M. Schertler, "Using the Boneh- 1464 Franklin identity-based encryption algorithm with the 1465 Cryptographic Message Syntax (CMS)," draft-ietf- 1466 smime-bfibecms-10.txt, July 2008. 1468 [NIST] M. Souppaya, J. Wack and K. Kent, "Security 1469 Configuration Checklist Program for IT Products - 1470 Guidance for Checklist Users and Developers," NIST 1471 Special Publication SP 800-70, May 2005. 1473 [P1363] IEEE P1363, "Standard Specifications for Public-Key 1474 Cryptography," 2001. 1476 Authors' Addresses 1478 Guido Appenzeller 1479 Stanford University 1480 Gates Building 3A 1481 Stanford, CA 94305 1483 Phone: +1 650 732 2273 1484 Email: appenz@cs.stanford.edu 1486 Luther Martin 1487 Voltage Security 1488 1070 Arastradero Rd Suite 100 1489 Palo Alto CA 94304 1490 USA 1492 Phone: +1 650 543 1280 1493 Email: martin@voltage.com 1495 Mark Schertler 1496 Tumbleweed Communications 1497 700 Saginaw Dr 1498 Redwood City CA 94063 1499 USA 1501 Phone: +1 650 216 2039 1502 Email: mark.schertler@tumbleweed.com 1504 Intellectual Property Statement 1506 The IETF takes no position regarding the validity or scope 1507 of any Intellectual Property Rights or other rights that 1508 might be claimed to pertain to the implementation or use of 1509 the technology described in this document or the extent to 1510 which any license under such rights might or might not be 1511 available; nor does it represent that it has made any 1512 independent effort to identify any such rights. 1513 Information on the procedures with respect to rights in RFC 1514 documents can be found in BCP 78 and BCP 79. 1516 Copies of IPR disclosures made to the IETF Secretariat and 1517 any assurances of licenses to be made available, or the 1518 result of an attempt made to obtain a general license or 1519 permission for the use of such proprietary rights by 1520 implementers or users of this specification can be obtained 1521 from the IETF on-line IPR repository at 1522 http://www.ietf.org/ipr. 1524 The IETF invites any interested party to bring to its 1525 attention any copyrights, patents or patent applications, 1526 or other proprietary rights that may cover technology that 1527 may be required to implement this standard. Please address 1528 the information to the IETF at ietf-ipr@ietf.org. 1530 Disclaimer of Validity 1532 This document and the information contained herein are 1533 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 1534 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 1535 THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET 1536 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1537 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 1538 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 1539 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR 1540 A PARTICULAR PURPOSE. 1542 Copyright Statement 1544 Copyright (C) The IETF Trust (2008). 1546 This document is subject to the rights, licenses and 1547 restrictions contained in BCP 78, and except as set forth 1548 therein, the authors retain all their rights. 1550 Acknowledgment 1552 Funding for the RFC Editor function is currently provided 1553 by the Internet Society.