idnits 2.17.1 draft-ietf-smime-ibearch-07.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 1533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1521. 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 (August 2008) is 5730 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: February 2009 Tumbleweed Communications 8 August 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. This step is shown below in Figure 1. 246 IBE Public Parameter Request 247 -----------------------------> 248 Sender PPS 249 <----------------------------- 250 IBE Public Parameters 252 Figure 1 Requesting IBE Public Parameters 254 The sender of an IBE-encrypted message selects the PPS and 255 corresponding PKG based on his local security policy. 256 Different PPS servers may provide public parameters that 257 specify different IBE algorithms or different key 258 strengths, for example, or require the use of PKG servers 259 that require different levels of authentication before 260 granting IBE private keys. 262 2.2.2. Construct and Send IBE-encrypted Message 264 To IBE-encrypt a message, the sender chooses a content- 265 encryption key (CEK) and uses it to encrypt his message and 266 then encrypts the CEK with the recipient's IBE public key 267 as described in [CMS]. This operation is shown below in 268 Figure 2. The document [IBCS] describes the algorithms 269 needed to implement two forms of IBE and [IBECMS] describes 270 how to use the Cryptographic Message Syntax (CMS) to 271 encapsulate the encrypted message along with the IBE 272 information that the recipient needs to decrypt an e-mail 273 message. 275 CEK ----> Sender ----> IBE-encrypted CEK 277 ^ 278 | 279 | 281 Recipient's Identity 282 and IBE Public Parameters 284 Figure 2 Using an IBE Public-key Algorithm to Encrypt 286 2.3. Receiving and Viewing an IBE-encrypted Message 288 In order to read an IBE-encrypted message, a recipient of 289 such a message parses the message to find the URI or IRI he 290 needs to obtain the IBE public parameters that are required 291 to perform IBE calculations as well as a component of the 292 identity that was used to encrypt the message. Next the 293 recipient carries out the following steps: 295 1. Obtain the IBE public parameters 297 An IBE system's public parameters allow it to 298 uniquely create public and private keys. The 299 recipient of an IBE-encrypted message can decrypt an 300 IBE-encrypted message if he has both the IBE public 301 parameters and the necessary IBE private key. The 302 public parameters also provide the URI or IRI of the 303 PKG where the recipient of an IBE-encrypted message 304 can obtain the IBE private keys. 306 2. Obtain the IBE private key from the PKG 308 To decrypt an IBE-encrypted message, in addition to 309 the IBE public parameters, the recipient needs to 310 obtain the private key that corresponds to the public 311 key that the sender used. The IBE private key is 312 obtained after successfully authenticating to a 313 private key generator (PKG), a trusted third party 314 that calculates private keys for users. The recipient 315 then receives the IBE private key over a secure 316 connection. 318 3. Decrypt IBE-encrypted message 320 The IBE private key decrypts the CEK (see Section 321 2.2.2). The CEK is then used to decrypt encrypted 322 message. 324 It may be useful for a PKG to allow users other than the 325 intended recipient to receive some IBE private keys. Giving 326 a mail filtering appliance permission to obtain IBE private 327 keys on behalf of users, for example, can allow the 328 appliance to decrypt and scan encrypted messages for 329 viruses or other malicious features. 331 2.3.1. Recipient Obtains Public Parameters 333 Before he can perform any IBE calculations related to the 334 message that he has received, the recipient of an IBE- 335 encrypted message needs to obtain the IBE public parameters 336 that were used in the encryption operation. This operation 337 is shown below in Figure 3. Because the use of the correct 338 public parameters is vital to the overall security of an 339 IBE system, IBE public parameters MUST be transported to 340 recipients over a secure protocol. PPS servers MUST support 341 TLS 1.1 [TLS] or its successors, using the latest version 342 supported by both parties, for transport of IBE public 343 parameters. In addition, users MUST verify that the subject 344 name in the server certificate matches the URI/IRI of the 345 PPS. The comments in Section 2.2.1 also apply to this 346 operation. 348 IBE Public Parameter Request 349 -----------------------------> 350 Recipient PPS 351 <----------------------------- 352 IBE Public Parameters 354 Figure 3 Requesting IBE Public Parameters 356 2.3.2. Recipient Obtains IBE Private Key 358 To obtain an IBE private key, the recipient of an IBE- 359 encrypted message provides the IBE public key used to 360 encrypt the message and their authentication credentials to 361 a PKG and requests the private key that corresponds to the 362 IBE public key. Section 5 of this document defines the 363 protocol for communicating with a PKG as well as a minimum 364 interoperable way to authenticate to a PKG that all IBE 365 implementations MUST support. Because the security of IBE 366 private keys is vital to the overall security of an IBE 367 system, IBE private keys MUST be transported to recipients 368 over a secure protocol. PKG servers MUST support TLS 1.1 369 [TLS] or its successors, using the latest version supported 370 by both parties, for transport of IBE private keys. This 371 operation is shown below in Figure 4. 373 IBE Private Key Request 374 ----------------------------> 375 Recipient PKG 376 <---------------------------- 377 IBE Private Key 379 Figure 4 Obtaining an IBE Private Key 381 2.3.3. Recipient Decrypts IBE-encrypted Message 383 After obtaining the necessary IBE private key, the 384 recipient uses that IBE private key and the corresponding 385 IBE public parameters to decrypt the CEK. This operation is 386 shown below in Figure 5. He then uses the CEK to decrypt 387 the encrypted message content. An example of how to do this 388 with e-mail messages is given in [IBECMS]. 390 IBE-encrypted CEK ----> Recipient ----> CEK 392 ^ 393 | 394 | 396 IBE Private Key 397 and IBE Public Parameters 399 Figure 5 Using an IBE Public-key Algorithm to Decrypt 401 3. Identity Format 403 An IBEIdentityInfo type MUST be used to represent the 404 identity of a recipient. This is defined to be the 405 following: 407 IBEIdentityInfo ::= SEQUENCE { 408 district IA5String, 409 serial INTEGER, 410 identityType OBJECT IDENTIFIER, 411 identityData OCTET STRING 412 } 414 An IBEIdentityInfo type is used to calculate public and 415 private IBE keys. Because of this, such a structure is 416 typically DER-encoded [DER]. 418 The fields of an IBEIdentityInfo structure have the 419 following meanings. 421 The district is an IA5String that represents the URI [URI] 422 or IRI [IRI] where the recipient of an IBE-encrypted 423 message can retrieve the IBE public parameters needed to 424 encrypt or decrypt a message encrypted for this identity. 425 Applications MUST support the method described in Section 4 426 for doing this and MAY support other methods. IRIs MUST be 427 handled according to the procedures specified in Section 428 7.4 of [PKIX]. 430 The serial is an INTEGER that defines a unique set of IBE 431 public parameters in the event that more than one set of 432 parameters is used by a single district. 434 identityType is an OBJECT IDENTIFIER that defines the 435 format that the identityData field is encoded with. 437 An example of a useful IBEIdentityInfo type is given in 438 [IBECMS]. This example is tailored to the use of IBE in 439 encrypting e-mail. Because the information that comprises 440 an identity is very dependent on the application, this 441 document does not define an identityType that all 442 applications MUST support. 444 4. Public Parameter Lookup 446 This section specifies how a component of an IBE system can 447 retrieve these parameters. A sending or receiving client 448 MUST allow configuration of these parameters manually, for 449 example, through editing a configuration file. However for 450 simplified configuration a client SHOULD also implement the 451 public parameter URI/IRI request method described in this 452 document to fetch the public parameters based on a 453 configured URI/IRI. This is especially useful for 454 federating between IBE systems. By specifying a single 455 URI/IRI, a client can be configured to fetch all the 456 relevant parameters for a remote PKG. These public 457 parameters can then be used to encrypt messages to 458 recipients who authenticate to and retrieve private keys 459 from that PKG. 461 The following section outlines the URI/IRI request method 462 to retrieve a parameter block and describes the structure 463 of the parameter block itself. The technique for fetching 464 IBE public parameters using the process defined in this 465 section is indicated by the OBJECT IDENTIFIER uriPPSOID, 466 which is defined to be the following: 468 uriPPSOID OBJECT IDENTIFIER ::= { 469 joint-iso-itu-t(2) country(16) us(840) 470 organization(1) identicrypt(114334) 471 pps-schemas(3) ic-schemas(1) pps-uri(1) version(1) 472 } 474 4.1. Request Method 476 The configuration URI/IRI SHOULD be an HTTPS URI [HTTP] and 477 MAY additionally support IRIs [IRI] for this purpose. To 478 retrieve the IBE public parameters, the client SHOULD use 479 the HTTP GET method as defined in [HTTP]. The request MUST 480 happen over a secure protocol. The requesting client MUST 481 support TLS 1.1 [TLS] or its successors and SHOULD use the 482 latest version supported by both parties. When requesting 483 the URI/IRI the client MUST only accept the system 484 parameter block if the server identity was verified 485 successfully by TLS 1.1 [TLS] or its successors. 487 A successful GET request returns in its body the base64 488 [B64] encoding of the DER-encoded [DER] IBESysParams 489 structure that is described in the next section. This 490 structure MUST be encoded as an application/ibe-pp-data 491 MIME type. 493 4.2. Parameter and Policy Format 495 The IBE Public parameters are a structure of the form 497 IBESysParams ::= SEQUENCE { 498 version INTEGER { v2(2) }, 499 districtName IA5String, 500 districtSerial INTEGER, 501 validity ValidityPeriod, 502 ibePublicParameters IBEPublicParameters, 503 ibeIdentityType OBJECT IDENTIFIER, 504 ibeParamExtensions IBEParamExtensions OPTIONAL 505 } 507 The fields of an IBESysParams structure have the following 508 meanings. 510 The version field specifies the version of the IBESysParams 511 format. For the format described in this document, this 512 MUST be set to 2. 514 The districtName field is an IA5String that MUST be an 515 encoding of an URI [URI] or IRI [IRI]. IRIs MUST be handled 516 according to the procedures specified in Section 7.4 of 517 [PKIX]. 519 The districtSerial field is an integer that represents a 520 unique set of IBE public parameters that are available at 521 the URI or IRI defined by the districtName. If new 522 parameters are published for a districtName, the 523 districtSerial MUST be increased to a number greater than 524 the previously-used districtSerial. 526 The validity field defines lifetime of a specific instance 527 of the IBESysParams and is defined to be the following: 529 ValidityPeriod ::= SEQUENCE { 530 notBefore GeneralizedTime, 531 notAfter GeneralizedTime 532 } 534 A client MUST verify that the date on which it uses the IBE 535 public parameters falls between the notBefore time and the 536 notAfter time of the IBE public parameters and MUST NOT use 537 the parameters for IBE encryption operations if they do 538 not. 540 IBE public parameters MUST be regenerated and republished 541 whenever the values of ibePublicParameters, 542 ibeIdentityType, or ibeParamExtensions change for a 543 district. A client SHOULD refetch the IBE public parameters 544 at an application-configurable interval to ensure that it 545 has the most current version on the IBE public parameters. 547 It is possible to create identities for use in IBE that 548 have a time component, as described in [IBECMS], for 549 example. If such an identity is used, the time component of 550 the identity MUST fall between the notBefore time and the 551 notAfter times of the IBE public parameters. 553 IBEPublicParameters is a structure containing public 554 parameters that correspond to IBE algorithms that the PKG 555 supports. This structure is defined to be following: 557 IBEPublicParameters ::= SEQUENCE (1..MAX) OF 558 IBEPublicParameter 560 IBEPublicParameter ::= SEQUENCE { 561 ibeAlgorithm OBJECT IDENTIFIER, 562 publicParameterData OCTET STRING 563 } 565 The ibeAlgorithm OBJECT IDENTIFIER specifies an IBE 566 algorithm. The OIDs for two IBE algorithms, the Boneh- 567 Franklin and Boneh-Boyen algorithms and their 568 publicParameterData structures are defined in [IBCS]. 570 The publicParameterData is a DER-encoded [DER] structure 571 that contains the actual cryptographic parameters. Its 572 specific structure depends on the algorithm. 574 The IBESysParams of a district MUST contain an OID that 575 identifies at least one algorithm and MAY contain OIDs that 576 identify more than one algorithm. It MUST NOT contain two 577 or more IBEPublicParameter entries with the same algorithm. 578 A client that wants to use IBESysParams can chose any of 579 the algorithms specified in the publicParameterData 580 structure. A client MUST implement at least the Boneh- 581 Franklin algorithm [IBCS] and MAY implement the Boneh-Boyen 582 [IBCS] and other algorithms. If a client does not support 583 any of the supported algorithms it MUST generate an error 584 message and fail. 586 ibeIdentityType is an OID that defines the type of 587 identities that are used with this district. The OIDs and 588 the required and optional fields for each OID are 589 application dependent. An example of this is given in 590 [IBECMS], which defines an identity format suitable for use 591 in encrypting e-mail. 593 IBEParamExtensions is a set of extensions that can be used 594 to define additional parameters that particular 595 implementations may require. This structure is defined as 596 follows: 598 IBEParamExtensions ::= SEQUENCE OF IBEParamExtension 600 IBEParamExtension ::= SEQUENCE { 601 ibeParamExtensionOID OBJECT IDENTIFIER, 602 ibeParamExtensionValue OCTET STRING 603 } 605 The contents of the octet string ibeParamExtensionValue are 606 defined by the specific ibeParamExtensionOID. The 607 IBEParamExtensions of a district MAY have any number of 608 extensions, including zero. One example of extensions that 609 have been used in practice is to provide a URI where an 610 encrypted message can be decrypted and viewed by users of 611 webmail systems. Another example is to provide commercial 612 branding information, so that a bank can provide a 613 different user interface for customers of different lines 614 of business. 616 If a client receives Public parameters that contain an 617 extension that it is unable to process, it MUST NOT use the 618 values in the IBESysParams structure for any cryptographic 619 operations. Clients MUST be able to process an IBESysParams 620 structure that contains no IBEParamExtensions. 622 The pkgURI OBJECT IDENTIFIER that is defined below defines 623 an IBEParamExtensions structure that contains the URI or 624 IRI of a Private Key Generator. The presence of this OBJECT 625 IDENTIFIER in an IBEParamExtension indicates that clients 626 MUST use the protocol defined in Section 5 of this document 627 to obtain IBE private keys from the PKG and do so using the 628 URI/IRI that is defined by the value defined by the 629 ibeParamExtensionValue in the IBEParamExtension. 631 If the PKG is publicly-accessible, this extension SHOULD be 632 present to allow the automatic retrieval of private keys 633 for recipients of encrypted messages. For this extension 634 the ibeParamExtensionValue OCTET STRING is an IA5String 635 containing the URI [URI] or IRI [IRI] of the PKG where IBE 636 private keys can be obtained. IRIs MUST be handled 637 according to the procedures specified in Section 7.4 of 638 [PKIX]. 640 ibeParamExt OBJECT IDENTIFIER ::= { 641 ibcs ibcs3(3) parameter-extensions(2) 642 } 644 pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) } 646 4.3. The application/ibe-pp-data MIME type 648 The following summarizes the properties of the 649 application/ibe-pp-data MIME type. 651 MIME media type name: application 653 MIME subtype name: ibe-pp-data 655 Mandatory parameters: The single required parameter is a 656 base64-encoded DER-encoded IBESysParams structure. 658 Optional parameters: There are no optional parameters. 660 Encoding considerations: This media type MUST be encoded as 661 7bit (us-ascii text [ASCII]). 663 Security considerations: The data conveyed as this media 664 type are the public parameters needed for the operation of 665 a cryptographic system. To ensure that the parameters can 666 be trusted, the request for these parameters must take 667 place over a secure protocol, TLS 1.1 or its successors. To 668 ensure the validity of the server, the client MUST verify 669 the server certificate and MUST abort the parameter request 670 if the verification of the server certificate of the TLS 671 connection fails. This media type contains no active 672 content and does not use compression. 674 Interoperability considerations: There are no known 675 interoperability considerations for this media type. 677 Applications that use this media type: Applications that 678 implement IBE in compliance with this specification will 679 use this media type. The most commonly-used of these 680 applications are encrypted email and file encryption. 682 Additional information: This media type is used for the 683 response from a public parameter server after receiving a 684 request for IBE public parameters. This media type contains 685 no active content and does not use compression. 687 Person and email address for further information: Luther 688 Martin, martin@voltage.com. 690 Intended usage: COMMON. 692 Author/Change controller: Luther Martin, 693 martin@voltage.com. 695 5. Private Key Request Protocol 697 5.1. Overview 699 When requesting a private key, a client has to transmit 700 three parameters: 702 1. The IBE algorithm for which the key is being 703 requested 705 2. The identity for which it is requesting a key 707 3. Authentication credentials for the individual 708 requesting the key 710 These two are often not the same as a single user may have 711 access to multiple aliases. For example an email user may 712 have access to the keys that correspond to two different 713 email addresses, e.g. bob@example.com and 714 bob.smith@example.com. 716 This section defines the protocol to request private keys, 717 a minimum user authentication method for interoperability, 718 and how to pass authentication credentials to the server. 719 It assumes that a client has already determined the URI/IRI 720 of the PKG. This can be done from information included in 721 the IBE message format and the public parameters of the IBE 722 system. 724 The technique for fetching an IBE private key using the 725 process defined in this section is indicated by the OBJECT 726 IDENTIFIER pkgURI, which is defined to be the following: 728 ibcs OBJECT IDENTIFIER ::= { 729 joint-iso-itu-t(2) country(16) us(840) 730 organization(1) identicrypt(114334) ibcs(1) 731 } 733 ibeParamExt OBJECT IDENTIFIER ::= { 734 ibcs ibcs3(3) parameter-extensions(2) 735 } 737 pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) } 739 5.2. Private Key Request 741 To request a private key, a client MUST perform a HTTP POST 742 method as defined in [HTTP]. The request MUST take place 743 over a secure protocol. The requesting client MUST support 744 TLS 1.1 [TLS] or its successors, using the latest version 745 supported by both the client and the PKG. When requesting 746 the URI/IRI the client MUST verify the server certificate 747 [HTTPTLS], and MUST abort the key request if the server 748 certificate verification of the TLS connection fails. Doing 749 so is critical to protect the authentication credentials 750 and the private key against man-in-the-middle attacks when 751 it is transmitted from the key server to the client. 753 5.3. Request Structure 755 The POST method contains in its body the following XML 756 structure that MUST be encoded as an application/ibe-key- 757 request+xml MIME type: 759 760 761 762 763 764 765 766 algorithmOID 767 768 769 ibeIdentityInfo 770 771 772 773 ibeAuthData 774 775 776 778 A SHOULD include an element in 779 the part of a key request that contains an 780 ASCII string that identifies the client type and client 781 version. 783 A key request MUST contain an element that 784 contains the base64 [B64] encoding of a DER-encoded [DER] 785 object identifier that identifies the algorithm for which a 786 key is requested. OIDs for the BB1 and BF algorithms are 787 listed in [IBCS]. 789 A key request MUST contain an element that 790 contains the identity that the private key is being 791 requested for. This identity is the base64 [B64] encoding 792 of a DER-encoded [DER] ASN.1 structure. This structure 793 defines a user's identity in a way appropriate for the 794 application. An example of such a structure that is 795 appropriate for use in encrypting e-mail is defined in 796 [IBECMS]. 798 A key request MAY contain an element. This 799 element contains authentication information that the PKG 800 can use to determine whether or not a request for a 801 particular IBE private key should be granted. 803 A client MAY include optional additional XML elements in 804 the part of the key request. A PKG MUST be able 805 to process key requests that contain no such optional 806 elements. 808 5.4. The application/ibe-key-request+xml MIME type 810 The following summarizes the properties of the application/ 811 ibe-key-request+xml MIME type. 813 MIME media type name: application 815 MIME subtype name: ibe-key-request+xml 817 Mandatory parameters: The required parameters are the 818 identity for which an IBE private key is being requested 819 and an object identifier that identifies which 820 cryptographic algorithm the key is being requested for. The 821 identity is the base64-encoding of a DER-encoded 822 ibeIdentityInfo structure. The object identifier is the 823 base64-encoding of a DER-encoded object identifier, like 824 those defined in [IBCS]. 826 Optional parameters: Any optional parameters may be defined 827 by an administrator of a particular PKG. The most common 828 optional parameter is an authentication credential. A PKG 829 may redirect a request for an IBE private key to an 830 external authentication mechanism, the reply from which is 831 then included as this optional parameter in a subsequent 832 key request. Other optional parameters may include other 833 information as required by particular implementations. An 834 example of this from an existing implementation is a bank 835 that has clients pass branding information along with a key 836 request so that mortgage customers see a different user 837 interface than non-mortgage customers do, for example. 839 Encoding considerations: This media type MUST be encoded as 840 us-ascii [ASCII]. 842 Security considerations: The data conveyed in this media 843 type may contain authentication credentials. Because of 844 this, its confidentiality and integrity is extremely 845 important. To ensure this, the request for an IBE private 846 key must take place over a secure protocol, TLS 1.1 or its 847 successors. To ensure the validity of the server, the 848 client MUST verify the server certificate and MUST abort 849 the key request if the verification of the server 850 certificate of the TLS connection fails. This media type 851 contains no active content and does not use compression. 853 Interoperability considerations: There are no known 854 interoperability considerations for this media type. 856 Applications that use this media type: Applications that 857 implement IBE in compliance with this specification will 858 use this media type. The most commonly-used of these 859 applications are encrypted email and file encryption. 861 Additional information: This media type is used for the 862 data that is passed to an IBE PKG by a client requesting an 863 IBE private key. This media type contains no active content 864 and does not use compression. 866 Person and email address for further information: Luther 867 Martin, martin@voltage.com. 869 Intended usage: COMMON. 871 Author/Change controller: Luther Martin, 872 martin@voltage.com. 874 5.5. Authentication 876 When a client requests a key from a PKG, the PKG MUST 877 authenticate the client before issuing the key. 878 Authentication may either be done through the key request 879 structure or as part of the secure transport protocol. 881 A client or server implementing the request protocol MUST 882 support HTTP Basic Auth [AUTH] and SHOULD also support HTTP 883 Digest Auth [AUTH]. Applications MAY also use other means 884 of authentication that are appropriate for the application. 885 An e-mail application, for example, might rely on deployed 886 e-mail infrastructure for this, for example. 888 For authentication methods that are not done by the 889 transport protocol, a client MAY include additional 890 authentication information in XML elements in the 891 element of a key request. If a client does 892 not know how to authenticate to a server, the client MAY 893 send a key request without authentication information. If 894 the key server requires the client to authenticate 895 externally, it MAY reply with an IBE201 responseCode as 896 defined below to redirect the client to the correct 897 authentication mechanism. After receiving an authentication 898 credential from this external mechanism, a client can then 899 use the credential to form a key request that contains the 900 additional authentication data. 902 5.6. Server Response Format 904 The key server replies to the HTTP request with an HTTP 905 response. If the response contains a client error or server 906 error status code, the client MUST abort the key request 907 and fail. 909 If the PKG replies with an HTTP response that has a status 910 code indicating success, the body of the reply MUST contain 911 the following XML structure that MUST be encoded as an 912 application/ibe-pkg-reply+xml MIME type: 914 915 916 917 bodyTags 918 919 921 The responseCode attribute contains an ASCII string that 922 describes the type of response from the key server. The 923 list of currently-defined responseCodes and their 924 associated meanings is: 926 IBE100 KEY_FOLLOWS 927 IBE101 RESERVED 928 IBE201 FOLLOW_ENROLL_URI 929 IBE300 SYSTEM_ERROR 930 IBE301 INVALID_REQUEST 931 IBE303 CLIENT_OBSOLETE 932 IBE304 AUTHORIZATION DENIED 934 5.6.1. The IBE100 responseCode 936 If the key request was successful, the key server responds 937 with a responseCode of IBE100, and the MUST 938 contain a element that contains a valid 939 private key. An example of this is shown below. 941 942 943 944 945 privateKey 946 947 948 950 The privateKey is the base64 [B64] encoding of the DER 951 encoding [DER] of the following structure: 953 IBEPrivateKeyReply ::= SEQUENCE { 954 pkgIdentity IBEIdentityInfo, 955 pgkAlgorithm OBJECT IDENTIFIER, 956 pkgKeyData OCTET STRING, 957 pkgOptions SEQUENCE SIZE (1..MAX) OF PKGOption 958 } 960 PKGOption ::= SEQUENCE { 961 optionID OBJECT IDENTIFIER, 962 optionValue OCTET STRING 963 } 965 The pkgIdentity is an IBEIdentityInfo structure that MUST 966 be identical to the IBEIdentityInfo structure that was sent 967 in the key request. 969 The pkgAlgorithm is an OID that identifies the algorithm of 970 the returned private key. The OIDs for the BB and BF 971 algorithms are defined in [IBCS]. 973 The pkgKeyData is a structure that contains the actual 974 private key. Private-key formats for the BB and BF 975 algorithms are defined in [IBCS]. 977 A server MAY pass back additional information to a client 978 in the pkgOptions structure. A client that receives a 979 IBEPrivateKeyReply from a PKG that contains information in 980 a pkgOptions structure that it is unable process MUST NOT 981 use the IBE private key in the IBEPrivateKeyReply structure 982 for any cryptographic operations. A client MUST be able to 983 process an IBEPrivateKeyReply that contains no PKGOptions 984 structure. 986 5.6.2. The IBE101 responseCode 988 The responseCode IBE101 is reserved to ensure 989 interoperability with earlier versions of the protocol that 990 is described in this document. An example of such a 991 response is shown below. A response with the IBE101 992 responseCode SHOULD contain no body. If information is 993 contained in the body of such a response, the client 994 receiving the response MUST discard any data that is 995 contained in the body. 997 998 999 1000 This message must be discarded by the recipient 1001 1004 5.6.3. The IBE201 responseCode 1006 A PKG MAY support authenticating users to external 1007 authentication mechanisms. If this is the case, the server 1008 replies to the client with responseCode IBE201 and the body 1009 of the response MUST contain a element that 1010 specifies the URI of the authentication mechanism. An 1011 example of such a response is shown below. 1013 1014 1015 1016 1018 1019 1021 The client can now contact the URI returned in such a 1022 response using the same mechanisms as defined in Section 1023 4.2 to obtain an authentication credential. Once the client 1024 has obtained the credential from the authentication 1025 mechanism at this URI, it sends a new key request to the 1026 PKG with the correct authentication credentials contained 1027 in the request, placing the authentication credential in 1028 the element of a key request as described in 1029 Section 4.4. 1031 5.6.4. The IBE300 responseCode 1033 The IBE300 responseCode indicates that an internal server 1034 error has occurred. Information that may help diagnose the 1035 error MAY be included in the body of such a response. An 1036 example of such a response is shown below. Upon receiving a 1037 IBE300 responseCode, the client MUST abort the key request 1038 and discard any data that was included in the body of the 1039 response. 1041 1042 1043 1044 Widget phlebotomy failure 1045 1046 1048 5.6.5. The IBE301 responseCode 1050 The IBE303 responseCode indicates that an invalid key 1051 request has been received by the server. Information that 1052 may help diagnose the error MAY be included in the body of 1053 such a response. An example of such a response is shown 1054 below. Upon receiving an IBE301 responseCode, the client 1055 MUST abort the key request and discard any data that was 1056 included in the body of the response. 1058 1059 1060 1061 Some additional stuff 1062 1063 1065 5.6.6. The IBE303 responseCode 1067 The IBE303 responseCode indicates that the server is unable 1068 to correctly process the request because the version of the 1069 request is no longer supported by the server. Information 1070 that may help diagnose the error MAY be included in the 1071 body of such a response. An example of such a response is 1072 shown below. Upon receiving an IBE303 responseCode, the 1073 client MUST abort the key request and discard any data that 1074 was included in the body of the response. 1076 1077 1078 1079 Version 3.3 or later needed 1080 1081 1083 5.6.7. The IBE304 responseCode 1085 The IBE304 responseCode indicates that a valid key request 1086 has been received by the server but the authentication 1087 credentials provided were invalid. Information that may 1088 help diagnose the error MAY be included in the body of such 1089 a response. An example of such a response is shown below. 1090 Upon receiving an IBE304 responseCode, the client MUST 1091 abort the key request and discard any data that was 1092 included in the body of the response. 1094 1095 1096 1097 Helpful error message 1098 1099 1101 5.7. The application/ibe-pkg-reply+xml MIME type 1103 The following summarizes the properties of the 1104 application/ibe-pkg-reply+xml MIME type. 1106 MIME media type name: application 1108 MIME subtype name: ibe-pkg-reply+xml 1110 Mandatory parameters: The only required parameter is a 1111 response code which indicates the status of a key request. 1112 Other parameters may be also required, depending on the 1113 nature of the response from the PKG. For example, for the 1114 responseCode IBE100 ("key follows"), an IBE private key is 1115 also a required parameter. 1117 Optional parameters: None. 1119 Encoding considerations: This media type MUST be encoded as 1120 us-ascii [ASCII]. 1122 Security considerations: The data conveyed as this media 1123 type is an IBE private key, so its confidentiality and 1124 integrity is extremely important. To ensure this, the 1125 response from the server that contains an IBE private key 1126 must take place over a secure protocol, TLS 1.1 or its 1127 successors. To ensure the validity of the server, the 1128 client MUST verify the server certificate and MUST abort 1129 the key request if the verification of the server 1130 certificate of the TLS connection fails. This media type 1131 contains no active content and does not use compression. 1133 Interoperability considerations: There are no known 1134 interoperability considerations for this media type. 1136 Applications that use this media type: Applications that 1137 implement IBE in compliance with this specification will 1138 use this media type. The most commonly-used of these 1139 applications are encrypted email and file encryption. 1141 Additional information: This media type is used for the 1142 response from a PKG after receiving a request for an IBE 1143 private key. This media type contains no active content and 1144 does not use compression. 1146 Person and email address for further information: Luther 1147 Martin, martin@voltage.com. 1149 Intended usage: COMMON. 1151 Author/Change controller: Luther Martin, 1152 martin@voltage.com. 1154 6. ASN.1 Module 1156 The following ASN.1 module summarizes the ASN.1 definitions 1157 discussed in this document. 1159 IBEARCH-module { joint-iso-itu-t(2) country(16) us(840) 1160 organization(1) identicrypt(114334) ibcs(1) ibearch(5) 1161 module(5) version(1) 1162 } 1164 DEFINITIONS IMPLICIT TAGS ::= BEGIN 1166 IBESysParams ::= SEQUENCE { 1167 version INTEGER { v2(2) }, 1168 districtName IA5String, 1169 districtSerial INTEGER, 1170 validity ValidityPeriod, 1171 ibePublicParameters IBEPublicParameters, 1172 ibeIdentityType OBJECT IDENTIFIER, 1173 ibeParamExtensions IBEParamExtensions OPTIONAL 1174 } 1176 ValidityPeriod ::= SEQUENCE { 1177 notBefore GeneralizedTime, 1178 notAfter GeneralizedTime 1179 } 1181 IBEPublicParameters ::= SEQUENCE (1..MAX) OF 1182 IBEPublicParameter 1184 IBEPublicParameter ::= SEQUENCE { 1185 ibeAlgorithm OBJECT IDENTIFIER, 1186 publicParameterData OCTET STRING 1187 } 1189 IBEParamExtensions ::= SEQUENCE OF IBEParamExtension 1191 IBEParamExtension ::= SEQUENCE { 1192 ibeParamExtensionOID OBJECT IDENTIFIER, 1193 ibeParamExtensionValue OCTET STRING 1194 } 1196 ibcs OBJECT IDENTIFIER ::= { 1197 joint-iso-itu-t(2) country(16) us(840) 1198 organization(1) identicrypt(114334) ibcs(1) 1199 } 1201 ibeParamExt OBJECT IDENTIFIER ::= { 1202 ibcs ibcs3(3) parameter-extensions(2) 1203 } 1205 pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) } 1206 IBEPrivateKeyReply ::= SEQUENCE { 1207 pkgIdentity IBEIdentityInfo, 1208 pgkAlgorithm OBJECT IDENTIFIER, 1209 pkgKeyData OCTET STRING, 1210 pkgOptions SEQUENCE SIZE (1..MAX) OF PKGOption 1211 } 1213 PKGOption ::= SEQUENCE { 1214 optionID OBJECT IDENTIFIER, 1215 optionValue OCTET STRING 1216 } 1218 uriPPSOID OBJECT IDENTIFIER ::= { 1219 joint-iso-itu-t(2) country(16) us(840) 1220 organization(1) identicrypt(114334) 1221 pps-schemas(3) ic-schemas(1) pps-uri(1) version(1) 1222 } 1224 IBEIdentityInfo ::= SEQUENCE { 1225 district IA5String, 1226 serial INTEGER, 1227 identityType OBJECT IDENTIFIER, 1228 identityData OCTET STRING 1229 } 1231 END 1233 7. Security Considerations 1235 7.1. Attacks outside the scope of this document 1237 Attacks on the cryptographic algorithms that are used to 1238 implement IBE are outside the scope of this document. Such 1239 attacks are detailed in [IBCS], which defines parameters 1240 that give 80-bit, 112-bit and 128-bit encryption strength. 1241 We assume that capable administrators of an IBE system will 1242 select parameters that provide a sufficient resistance to 1243 cryptanalytic attacks by adversaries. 1245 Attacks that give an adversary the ability to access or 1246 change the information on a PPS or PKG, especially the 1247 cryptographic material (referred to in this document as the 1248 master secret), will defeat the security of an IBE system. 1249 In particular, if the cryptographic material is compromised 1250 the adversary will have the ability to recreate any user's 1251 private key and therefore decrypt all messages protected 1252 with the corresponding public key. To address this concern, 1253 it is highly RECOMMENDED that best practices for physical 1254 and operational security for PPS and PKG servers be 1255 followed and that these servers be configured (sometimes 1256 known as hardened) in accordance with best current 1257 practices [NIST]. An IBE system SHOULD be operated in an 1258 environment where illicit access is infeasible for 1259 attackers to obtain. 1261 Attacks that require administrative or IBE user equivalent 1262 access to machines used by either the client or the server 1263 components defined in this document are also outside the 1264 scope of this document. 1266 We also assume that all administrators of a system 1267 implementing the protocols that are defined in this 1268 document are trustworthy and will not abuse their authority 1269 to bypass the security provided by an IBE system. 1270 Similarly, we assume that users of an IBE system will 1271 behave responsibly, not sharing their authentication 1272 credentials with others. Thus attacks that require such 1273 assumptions are outside the scope of this document. 1275 7.2. Attacks within the scope of this document 1277 Attacks within the scope of this document are those that 1278 allow an adversary to: 1280 o passively monitor information transmitted between 1281 users of an IBE system and the PPS and PKG 1283 o masquerade as a PPS or PKG 1285 o perform a DOS attack on a PPS or PKG 1287 o easily guess an IBE users authentication 1288 credential 1290 7.2.1. Attacks on the protocols defined in this document 1292 All communications between users of an IBE system and the 1293 PPS or PKG are protected using TLS 1.1 [TLS]. The IBE 1294 system defined in this document provides no additional 1295 security protections for the communications between IBE 1296 users and the PPS or PKG. Therefore the described IBE 1297 system is completely dependent on the TLS security 1298 mechanisms for authentication of the PKG or PPS server and 1299 for confidentiality and integrity of the communications. 1300 Should there be a compromise of the TLS security 1301 mechanisms, the integrity of all communications between an 1302 IBE user and the PPS or PKG will be suspect. 1304 The protocols defined in this document do not explicitly 1305 defend against an attacker masquerading as a legitimate IBE 1306 PPS or PKG. The protocols rely on the server authentication 1307 mechanism of TLS [TLS]. In addition to the TLS server 1308 authentication mechanism IBE client software can provide 1309 protection against this possibility by providing user 1310 interface capabilities that allows users to visually 1311 determine that a connection to PPS and PKG servers is 1312 legitimate. This additional capability can help ensure that 1313 users cannot easily be tricked into providing valid 1314 authorization credentials to an attacker. 1316 The protocols defined in this document are also vulnerable 1317 to attacks against an IBE PPS or PKG. Denial of service 1318 attacks against either component can result in users unable 1319 to encrypt or decrypt using IBE, and users of an IBE system 1320 SHOULD take the appropriate countermeasures [DOS, BGPDOS] 1321 that their use of IBE requires. 1323 The IBE user authentication method selected by an IBE PKG 1324 SHOULD be of sufficient strength to prevent attackers from 1325 easily guessing the IBE user's authentication credentials 1326 through trial and error. 1328 8. IANA Considerations 1330 8.1. Media types 1332 This specification proposes the registration of three media 1333 types in the standard registration tree. These are 1334 application/ibe-pp-data, application/ibe-key-request+xml, 1335 and application/ibe-pkg-reply+xml. The media type 1336 application/ibe-pp-data is defined in Section 3.3 of this 1337 document. The media type application/ibe-key-request+xml is 1338 defined in Section 4.4 of this document. The media type 1339 application/ibe-pkg-reply+xml is defined in Section 4.7 of 1340 this document. 1342 8.2. XML namespace 1344 The IANA is requested to register the following namespace 1345 identifier: 1347 urn:ietf:params:xml:ns:ibe 1349 Registrant Contact: 1351 Luther Martin 1352 Voltage Security 1353 1070 Arastradero Rd Suite 100 1354 Palo Alto CA 94304 1356 Phone: +1 650 543 1280 1357 Email: martin@voltage.com 1359 XML: 1361 BEGIN 1362 1363 1364 1365 1366 1367 1368 1369 algorithmOID 1370 1371 1372 ibeIdentityInfo 1373 1374 1375 1376 ibeAuthData 1377 1378 1379 1381 1382 1383 1384 bodyTags 1385 1386 1387 END 1389 9. References 1391 9.1. Normative References 1393 [ASCII] ISO/IEC 646:1991 - Information Technology - ISO 7- 1394 bit Coded Character Set for Information Exchange 1396 [ASN1] ITU-T Recommendation X.680: Information Technology - 1397 Abstract Syntax Notation One, 1997. 1399 [AUTH] J. Franks, et al., "HTTP Authentication: Basic and 1400 Digest Access Authentication", RFC 2617, June 1999. 1402 [B64] N. Freed and N. Borenstein, "Multipurpose Internet 1403 Mail Extensions(MIME) Part One: Format of Internet 1404 Message Bodies," RFC 2045, November 1996. 1406 [CMS] R. Housley, "Cryptographic Message Syntax (CMS)," RFC 1407 3852, July 2004. 1409 [DER] ITU-T Recommendation X.690: OSI Networking and System 1410 Aspects: Abstract Syntax Notation One (ASN.1), July 1411 2002. 1413 [DOS] P. Ferguson and D. Senie, "Network Ingress Filtering: 1414 Defeating Denial of Service Attacks which employ IP 1415 Source Address Spoofing," RFC 2827, BCP 38, May 2000. 1417 [HTTP] R. Fielding, et al., "Hypertext Transfer Protocol -- 1418 HTTP/1.1", RFC 2616, June 1999. 1420 [HTTPTLS] E. Rescorla, "HTTP over TLS," RFC 2818, May 2000. 1422 [IBCS] X. Boyen and L. Martin, "Identity-Based Cryptography 1423 Standard (IBCS) #1: Supersingular Curve 1424 Implementations of the BF and BB1 Cryptosystems," RFC 1425 5091, December 2007. 1427 [IRI] M. Deurst and M. Suignard, "Internationalized 1428 Resource Identifiers (IRIs)," RFC 3987, January 2005. 1430 [KEY] S. Brander, "Key Words for Use in RFCs to Indicate 1431 Requirement Levels," BCP 14, RFC 2119, March 1997. 1433 [PKIX] D. Cooper, et al., "Internet X.509 Public Key 1434 Infrastructure Certificate and Certificate Revocation 1435 List (CRL) Profile," RFC 5280, May 2008 1437 [SMTP] J. Klensin (ed.), "Simple Mail Transfer Protocol," 1438 RFC 2821, April 2001. 1440 [TLS] T. Dierks and E. Rescorla, "The Transport Layer 1441 Security (TLS) Protocol Version 1.1," RFC 4346, April 1442 2006. 1444 [URI] T. Berners-Lee, R. Fielding, and L. Masinter, 1445 "Uniform Resource Identifier (URI): Generic Syntax", 1446 STD 66, RFC 3986, January 2005. 1448 [XML] W3C, Extensible Markup Language (XML) 1.0 (Fourth 1449 Edition), September 2006. 1451 9.2. Informative References 1453 [BGPDOS] D. Turk, "Configuring BGP to Block Denial-of- 1454 Service Attacks," RFC 3882, September 2004. 1456 [IBECMS] L. Martin and M. Schertler, "Using the Boneh- 1457 Franklin identity-based encryption algorithm with the 1458 Cryptographic Message Syntax (CMS)," draft-ietf- 1459 smime-bfibecms-10.txt, July 2008. 1461 [NIST] M. Souppaya, J. Wack and K. Kent, "Security 1462 Configuration Checklist Program for IT Products - 1463 Guidance for Checklist Users and Developers," NIST 1464 Special Publication SP 800-70, May 2005. 1466 [P1363] IEEE P1363, "Standard Specifications for Public-Key 1467 Cryptography," 2001. 1469 Authors' Addresses 1471 Guido Appenzeller 1472 Stanford University 1473 Gates Building 3A 1474 Stanford, CA 94305 1476 Phone: +1 650 732 2273 1477 Email: appenz@cs.stanford.edu 1479 Luther Martin 1480 Voltage Security 1481 1070 Arastradero Rd Suite 100 1482 Palo Alto CA 94304 1483 USA 1485 Phone: +1 650 543 1280 1486 Email: martin@voltage.com 1488 Mark Schertler 1489 Tumbleweed Communications 1490 700 Saginaw Dr 1491 Redwood City CA 94063 1492 USA 1494 Phone: +1 650 216 2039 1495 Email: mark.schertler@tumbleweed.com 1497 Intellectual Property Statement 1499 The IETF takes no position regarding the validity or scope 1500 of any Intellectual Property Rights or other rights that 1501 might be claimed to pertain to the implementation or use of 1502 the technology described in this document or the extent to 1503 which any license under such rights might or might not be 1504 available; nor does it represent that it has made any 1505 independent effort to identify any such rights. 1506 Information on the procedures with respect to rights in RFC 1507 documents can be found in BCP 78 and BCP 79. 1509 Copies of IPR disclosures made to the IETF Secretariat and 1510 any assurances of licenses to be made available, or the 1511 result of an attempt made to obtain a general license or 1512 permission for the use of such proprietary rights by 1513 implementers or users of this specification can be obtained 1514 from the IETF on-line IPR repository at 1515 http://www.ietf.org/ipr. 1517 The IETF invites any interested party to bring to its 1518 attention any copyrights, patents or patent applications, 1519 or other proprietary rights that may cover technology that 1520 may be required to implement this standard. Please address 1521 the information to the IETF at ietf-ipr@ietf.org. 1523 Disclaimer of Validity 1525 This document and the information contained herein are 1526 provided on an "AS IS" basis and THE CONTRIBUTOR, THE 1527 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), 1528 THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET 1529 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1530 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 1531 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS 1532 OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR 1533 A PARTICULAR PURPOSE. 1535 Copyright Statement 1537 Copyright (C) The IETF Trust (2008). 1539 This document is subject to the rights, licenses and 1540 restrictions contained in BCP 78, and except as set forth 1541 therein, the authors retain all their rights. 1543 Acknowledgment 1545 Funding for the RFC Editor function is currently provided 1546 by the Internet Society.