idnits 2.17.1 draft-ietf-smime-ibepps-00.txt: -(60): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(99): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(334): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(337): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(346): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(356): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(360): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(364): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 401. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 407. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 17 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Overview' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7. IANA Considerations' ) ** There are 110 instances of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: A client SHOULD verify if system parameters that it obtains are currently valid and SHOULD not use these parameters if they are not valid. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2006) is 6518 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'IBCS' on line 356 looks like a reference -- Missing reference section? 'IBEPKG' on line 364 looks like a reference -- Missing reference section? 'KEY' on line 337 looks like a reference -- Missing reference section? 'IBECMS' on line 360 looks like a reference -- Missing reference section? 'RFC2616' on line 371 looks like a reference -- Missing reference section? 'SSL3' on line 343 looks like a reference -- Missing reference section? 'TLS' on line 346 looks like a reference -- Missing reference section? 'RFC2618' on line 137 looks like a reference -- Missing reference section? 'RFC1035' on line 159 looks like a reference -- Missing reference section? 'CMS' on line 334 looks like a reference -- Missing reference section? 'P1363' on line 340 looks like a reference -- Missing reference section? 'X509' on line 349 looks like a reference -- Missing reference section? 'IBEARCH' on line 353 looks like a reference -- Missing reference section? 'RFC2396' on line 367 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S/MIME Working Group G. Appenzeller 3 Internet Draft Voltage Security 4 Expires: December 2006 June 2006 6 Identity-based Encryption 7 Parameter and Policy Lookup 9 11 Status of this Document 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware have been 15 or will be disclosed, and any of which he or she becomes aware will be 16 disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 This document describes a protocol to obtain public parameters and 37 policy information for an identity-based encryption system. 39 Table of Contents 41 1. Introduction...................................................2 42 1.1. Terminology...............................................2 43 2. Overview.......................................................2 44 3. Request Method.................................................3 45 4. Parameter and Policy Format....................................4 46 5. ASN.1 Module...................................................7 47 6. Security Considerations........................................8 48 7. IANA Considerations............................................8 49 8. References.....................................................9 50 8.1. Normative References......................................9 51 Author's Address.................................................10 52 Intellectual Property Statement..................................10 53 Disclaimer of Validity...........................................10 54 Copyright Statement..............................................10 55 Acknowledgment...................................................11 57 1. Introduction 59 An identity-based encryption system (IBE) allows the encryption of 60 messages using a user�s identity plus a set of public parameters. 61 Theses public parameters are a global piece of data that is generated 62 together with the master secret of the IBE system when the IBE system 63 is set up. This document defines a protocol to retrieve public 64 parameters as well as configuration parameters of the private key 65 generator (PKG) of an IBE system. 67 This document does not describe the actual algorithms used for 68 encryption or the mathematical structure of the public parameters, 69 they are described in [IBCS]. It also does not describe the 70 communication protocol to the PKG, which is described in [IBEPKG]. 72 1.1. Terminology 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC-2119 [KEY]. 78 2. Overview 80 For an identity-based encryption (IBE) system to operate correctly, 81 the sender, receiver and the private key generator (PKG) have to 82 agree on a number of parameters. This protocol specifies how a system 83 component of an IBE system can retrieve these parameters, 84 specifically: 86 1. The Public Parameters of the PKG. The public parameters are part 87 of the encryption (and in some cases decryption) operation of 88 the IBE system. Generation of public parameters and the master 89 secret, as well as the mathematical structure of the public 90 parameters for the BF and BB1 algorithms are described in 91 [IBCS]. 93 2. The URI of the PKG. Knowledge of this URI allows recipients to 94 request a private key as described in [IBEPKG]. 96 3. The schema to format the identity strings. When issuing a 97 private key, the PKG often wants to limit who can obtain private 98 keys. For example for an identity string that contains 99 �bob@example.com�, only the owner of the identity string should 100 be able to request the private key. To ensure that the PKG can 101 interpret the identity string for which a private key is 102 requested, the encryption engine and the PKG have to use the 103 same schema for identity strings. Identity schemas are described 104 in [IBECMS] 106 A sending or receiving client MUST allow configuration of these 107 parameters manually, e.g. through editing a configuration file. 109 However for simplified configuration a client MAY also implement the 110 PP URI request method described in this document to fetch the system 111 parameters based on a configured URI. This is especially useful for 112 federating between IBE systems. By specifying a single URL a client 113 can be configured to fetch all the relevant parameters for a remote 114 PKG. These public parameters can then be used to encrypt messages to 115 recipients who authenticate to and retrieve private keys from that 116 PKG. 118 Section 3 of this document outlines the URI request method to 119 retrieve a parameter block based on a URI. Section 4 describes the 120 schema of the parameter block itself. 122 3. Request Method 124 The configuration URI SHOULD be an HTTPS URL [RFC2616] of the format: 126 http_URL = "https:" "//" host [ ":" port ] [ abs_path ] 128 An example URL for ibe system parameters is 130 https://ibe-0000.example.com/example.com.pem 132 To retrieve the IBE system parameters, the client SHOULD use the HTTP 133 GET method as defined in [RFC2616]. The request SHOULD happen over a 134 secure protocol. The requesting client MUST support either SSL v 3.0 135 [SSL3] protocol or TLS v 1.1 [TLS]. When requesting the URL the 136 client MUST only accept the system parameter block if the server 137 identity was verified successfully by SSL or TLS [RFC2618]. 139 A successful GET request returns in its body the DER and Base64 140 encoded ASN.1 structure that is described in the next section. 142 4. Parameter and Policy Format 144 The IBE System parameters are a set of 146 IBESysParams ::= SEQUENCE { 147 version INTEGER, 148 districtName UTF8String, 149 districtSerial INTEGER, 150 validity Validity, 151 ibePublicParameters IBEPublicParameters, 152 ibeIdentitySchema OBJECT IDENTIFIER, 153 ibeParamExtensions IBEParamExtensions 154 } 156 The version specifies the version of the parameter format. For the 157 format described in this standard it MUST be set to 2 The district 158 name is a UTF8String that MUST be a valid domain name as defined by 159 [RFC1035]. The districtSerial is a serial number. If new parameters 160 are published for a district, it MUST be increased. 162 The Validity is identical to the Validity definition for an X.509 163 certificate: 165 Validity ::= SEQUENCE { 166 notBefore CertificateValidityDate, 167 notAfter CertificateValidityDate 168 } 170 CertificateValidityDate ::= CHOICE { 171 utcTime UTCTime, 172 generalTime GeneralizedTime 173 } 175 A client SHOULD verify if system parameters that it obtains are 176 currently valid and SHOULD not use these parameters if they are not 177 valid. 179 IBEPublicParameters is a set of public parameters that correspond to 180 encryption algorithms that the PKG associated with this district 181 understands. 183 IBEPublicParameters ::= SEQUENCE OF IBEPublicParameter 185 IBEPublicParameter ::= SEQUENCE { 186 ibeAlgorithm OBJECT IDENTIFIER, 187 publicParameterData OCTET STRING 188 } 190 The ibeAlgorithm OID specifies an IBE algorithm. The 191 publicParameterData is a DER encoded ASN.1 structure that contains 192 the actual cryptographic parameters. Its specific structure depends 193 on the algorithm. The OIDs for two IBE algorithms, the Boneh-Franklin 194 and Boneh-Boyen algorithms and their publicParameterData structures 195 are defined in [IBCS]. 197 The IBESysParams of a district MUST contain at least one algorithm 198 and MAY contain several algorithms. It MUST NOT contain two or more 199 IBEPublicParameter entries with the same algorithm. A client that 200 wants to use IBESysParams can chose any of the algorithms specified 201 in the publicParameterData structure. If a client does not support 202 any of the supported algorithms it MUST generate an error message.A 203 client MUST implement at least the Boneh-Franklin algorithm and MAY 204 implement the Boneh-Boyens and other algorithms. 206 ibeIdentitySchema is an OID that defines the type of identities that 207 are used with this district. The OIDs and the required and optional 208 fields for each OID are described in [IBECMS]. 210 IBEParamExtensions is a set of extensions that are defined the same 211 way as X.509 extensions. 213 IBEParamExtensions ::= SEQUENCE OF Extensions 215 Extension ::= SEQUENCE { 216 id OBJECT IDENTIFIER, 217 critical BOOLEAN DEFAULT FALSE, 218 value OCTET STRING 219 } 221 ibeParamExt OBJECT IDENTIFIER ::= { 222 ibcs ibcs3(3) parameter-extensions(2) 223 } 225 The contents of the octet string are defined by the specific 226 extension type. The System Parameters of a district MAY have any 227 number of extensions, including zero. A client that encounters an 228 extension SHOULD fail if the extension is critical and SHOULD ignore 229 it silently if the extension is not critical. 231 The Extension pkgURL as defined in section 5 defines the URL of the 232 Private Key Generator of the district. If the PKG is publicly 233 accessible, this extension SHOULD be present to allow the automatic 234 retrieval of private keys for recipients of encrypted messages. For 235 this extension the OCTET STRING contains a UTF8String with the full 236 URL of the key server. 238 5. ASN.1 Module 240 This section defines the ASN.1 module for the encodings discussed in 241 section 4. 243 IBEPP { joint-iso-itu(2) country(16) us(840) organization(1) 244 identicrypt(114334) ibcs(1) pps(4) version(1) } 246 DEFINITIONS IMPLICIT TAGS ::= BEGIN 248 IMPORTS IBEIdentitySchema 249 FROM BFCMS 250 { joint-iso-itu(2) country(16) us(840) organization(1) 251 identicrypt(114334) ibcs(1) cms(4) module(5) version(1) 252 }; 254 ibcs OBJECT IDENTIFIER ::= { 255 joint-iso-itu(2) country(16) us(840) organization(1) 256 identicrypt(114334) ibcs(1) 257 } 259 -- The IBE System parameters consist of a set of public parameters 260 -- for the encryption algorithms supported by the district, 261 -- the identity schema, the URL of the PKG and further optional 262 -- parameters 264 IBESysParams ::= SEQUENCE { 265 version INTEGER, 266 districtName UTF8String, 267 districtSerial INTEGER, 268 validity Validity, 269 ibePublicParameters IBEPublicParameters, 270 ibeIdentitySchema OBJECT IDENTIFIER, 271 ibeParamExtensions IBEParamExtensions 272 } 274 -- Validity designates the time interval for which these parameters 275 -- are valid. It is defined the same as in X.509 277 Validity ::= SEQUENCE { 278 notBefore CertificateValidityDate, 279 notAfter CertificateValidityDate 280 } 282 CertificateValidityDate ::= CHOICE { 283 utcTime UTCTime, 284 generalTime GeneralizedTime 286 } 288 -- Public Parameters for the IBE Algorithm 289 -- ibeAlgorithm is the algorithm OID from IBCS, e.g. "bb" or "bf" 290 -- publicParameterData is a DER encoded ASN.1 public parameter 291 -- block, e.g. BFPublicParamaters, BBPublicParamaters 293 IBEPublicParameters ::= SEQUENCE OF IBEPublicParameter 295 IBEPublicParameter ::= SEQUENCE { 296 ibeAlgorithm OBJECT IDENTIFIER, 297 publicParameterData OCTET STRING 298 } 300 -- Extensions are defined the same as in X.509 302 IBEParamExtensions ::= SEQUENCE OF Extension 304 Extension ::= SEQUENCE { 305 id OBJECT IDENTIFIER, 306 critical BOOLEAN DEFAULT FALSE, 307 value OCTET STRING 308 } 310 ibeParamExt OBJECT IDENTIFIER ::= { 311 ibcs ibcs3(3) parameter-extensions(2) 312 } 314 -- Defined Extensions: 315 -- pkgURL: URL of the PKG, value is a UTF8String 317 pkgURL OBJECT IDENTIFIER ::= { ibeParamExt pkgURL(1) } 319 END 321 6. Security Considerations 323 This entire document relates to security considerations. 325 7. IANA Considerations 327 No further action by the IANA is necessary for the protocols 328 described in this document. 330 8. References 332 8.1. Normative References 334 [CMS] R. Housley, �Cryptographic Message Syntax,� RFC 3369, August 335 2002. 337 [KEY] S. Brander, �Key Words for Use in RFCs to Indicate Requirement 338 Levels,� BCP 14, RFC 2119, March 1997. 340 [P1363] IEEE P1363.3, �Standards Specifications for Public-Key 341 Cryptography,� 2001. 343 [SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", 344 Netscape Communications Corp., Nov 18, 1996. 346 [TLS] T. Dierks, E. Rescorla, �The Transport Layer Security Protocol 347 Version 1.1,� RFC 4346, April 2006. 349 [X509] ITU-T Recommendation X.509 (1997 E): Information Technology - 350 Open Systems Interconnection - The Directory: Authentication 351 Framework, June 1997. 353 [IBEARCH] L. Martin, M. Schertler, �Identity-based Encryption 354 Architecture,� draft-ietf-smime-ibearch-00.txt. 356 [IBCS] X. Boyen, L. Martin, �Identity-Based Cryptography Standard 357 (IBCS) #1: Supersingular Curve Implementations of the BF and 358 BB1 Cryptosystems,� draft-ietf-smime-ibcs-00.txt. 360 [IBECMS] M. Schertler, L. Martin, �Using the Boneh-Franklin identity- 361 based encryption algorithm with the Cryptographic Message 362 Syntax (CMS),� draft-ietf-smime-bfibecms-01.txt. 364 [IBEPKG] G. Appezeller �Private Key Request protocol for Identity- 365 Based Encryption,� draft-ietf-smime-ibepkg-00.txt. 367 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 368 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 369 1998.Author's Address 371 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frysyk, H., Masinter, 372 L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol 373 -- HTTP/1.1", RFC 2616, June 1999. 375 Author's Address 377 Guido Appenzeller 378 Voltage Security 379 1070 Arastradero Rd Suite 100 380 Palo Alto CA 94304 382 Phone: +1 650 543 1280 383 Email: guido@voltage.com 385 Intellectual Property Statement 387 The IETF takes no position regarding the validity or scope of any 388 Intellectual Property Rights or other rights that might be claimed to 389 pertain to the implementation or use of the technology described in 390 this document or the extent to which any license under such rights 391 might or might not be available; nor does it represent that it has 392 made any independent effort to identify any such rights. Information 393 on the procedures with respect to rights in RFC documents can be 394 found in BCP 78 and BCP 79. 396 Copies of IPR disclosures made to the IETF Secretariat and any 397 assurances of licenses to be made available, or the result of an 398 attempt made to obtain a general license or permission for the use of 399 such proprietary rights by implementers or users of this 400 specification can be obtained from the IETF on-line IPR repository at 401 http://www.ietf.org/ipr. 403 The IETF invites any interested party to bring to its attention any 404 copyrights, patents or patent applications, or other proprietary 405 rights that may cover technology that may be required to implement 406 this standard. Please address the information to the IETF at 407 ietf-ipr@ietf.org. 409 Disclaimer of Validity 411 This document and the information contained herein are provided on an 412 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 413 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 414 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 415 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 416 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 417 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 419 Copyright Statement 421 Copyright (C) The Internet Society (2006). 423 This document is subject to the rights, licenses and restrictions 424 contained in BCP 78, and except as set forth therein, the authors 425 retain all their rights. 427 Acknowledgment 429 Funding for the RFC Editor function is currently provided by the 430 Internet Society.