S/MIME Working Group G. Appenzeller Internet Draft Voltage Security Expires: December 2006 June 2006 Identity-based Encryption Parameter and Policy Lookup Status of this Document By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes a protocol to obtain public parameters and policy information for an identity-based encryption system. Table of Contents 1. Introduction...................................................2 1.1. Terminology...............................................2 2. Overview.......................................................2 3. Request Method.................................................3 4. Parameter and Policy Format....................................4 5. ASN.1 Module...................................................7 Appenzeller Expires December 2006 [Page 1] Internet-Draft Parameter and Policy Lookup June 2006 6. Security Considerations........................................8 7. IANA Considerations............................................8 8. References.....................................................9 8.1. Normative References......................................9 Author's Address.................................................10 Intellectual Property Statement..................................10 Disclaimer of Validity...........................................10 Copyright Statement..............................................10 Acknowledgment...................................................11 1. Introduction An identity-based encryption system (IBE) allows the encryption of messages using a user’s identity plus a set of public parameters. Theses public parameters are a global piece of data that is generated together with the master secret of the IBE system when the IBE system is set up. This document defines a protocol to retrieve public parameters as well as configuration parameters of the private key generator (PKG) of an IBE system. This document does not describe the actual algorithms used for encryption or the mathematical structure of the public parameters, they are described in [IBCS]. It also does not describe the communication protocol to the PKG, which is described in [IBEPKG]. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [KEY]. 2. Overview For an identity-based encryption (IBE) system to operate correctly, the sender, receiver and the private key generator (PKG) have to agree on a number of parameters. This protocol specifies how a system component of an IBE system can retrieve these parameters, specifically: 1. The Public Parameters of the PKG. The public parameters are part of the encryption (and in some cases decryption) operation of the IBE system. Generation of public parameters and the master secret, as well as the mathematical structure of the public parameters for the BF and BB1 algorithms are described in [IBCS]. Appenzeller Expires December 14, 2006 [Page 2] Internet-Draft Parameter and Policy Lookup June 2006 2. The URI of the PKG. Knowledge of this URI allows recipients to request a private key as described in [IBEPKG]. 3. The schema to format the identity strings. When issuing a private key, the PKG often wants to limit who can obtain private keys. For example for an identity string that contains “bob@example.com”, only the owner of the identity string should be able to request the private key. To ensure that the PKG can interpret the identity string for which a private key is requested, the encryption engine and the PKG have to use the same schema for identity strings. Identity schemas are described in [IBECMS] A sending or receiving client MUST allow configuration of these parameters manually, e.g. through editing a configuration file. However for simplified configuration a client MAY also implement the PP URI request method described in this document to fetch the system parameters based on a configured URI. This is especially useful for federating between IBE systems. By specifying a single URL a client can be configured to fetch all the relevant parameters for a remote PKG. These public parameters can then be used to encrypt messages to recipients who authenticate to and retrieve private keys from that PKG. Section 3 of this document outlines the URI request method to retrieve a parameter block based on a URI. Section 4 describes the schema of the parameter block itself. 3. Request Method The configuration URI SHOULD be an HTTPS URL [RFC2616] of the format: http_URL = "https:" "//" host [ ":" port ] [ abs_path ] An example URL for ibe system parameters is https://ibe-0000.example.com/example.com.pem To retrieve the IBE system parameters, the client SHOULD use the HTTP GET method as defined in [RFC2616]. The request SHOULD happen over a secure protocol. The requesting client MUST support either SSL v 3.0 [SSL3] protocol or TLS v 1.1 [TLS]. When requesting the URL the client MUST only accept the system parameter block if the server identity was verified successfully by SSL or TLS [RFC2618]. Appenzeller Expires December 14, 2006 [Page 3] Internet-Draft Parameter and Policy Lookup June 2006 A successful GET request returns in its body the DER and Base64 encoded ASN.1 structure that is described in the next section. 4. Parameter and Policy Format The IBE System parameters are a set of IBESysParams ::= SEQUENCE { version INTEGER, districtName UTF8String, districtSerial INTEGER, validity Validity, ibePublicParameters IBEPublicParameters, ibeIdentitySchema OBJECT IDENTIFIER, ibeParamExtensions IBEParamExtensions } The version specifies the version of the parameter format. For the format described in this standard it MUST be set to 2 The district name is a UTF8String that MUST be a valid domain name as defined by [RFC1035]. The districtSerial is a serial number. If new parameters are published for a district, it MUST be increased. The Validity is identical to the Validity definition for an X.509 certificate: Validity ::= SEQUENCE { notBefore CertificateValidityDate, notAfter CertificateValidityDate } CertificateValidityDate ::= CHOICE { utcTime UTCTime, generalTime GeneralizedTime } A client SHOULD verify if system parameters that it obtains are currently valid and SHOULD not use these parameters if they are not valid. IBEPublicParameters is a set of public parameters that correspond to encryption algorithms that the PKG associated with this district understands. Appenzeller Expires December 14, 2006 [Page 4] Internet-Draft Parameter and Policy Lookup June 2006 IBEPublicParameters ::= SEQUENCE OF IBEPublicParameter IBEPublicParameter ::= SEQUENCE { ibeAlgorithm OBJECT IDENTIFIER, publicParameterData OCTET STRING } The ibeAlgorithm OID specifies an IBE algorithm. The publicParameterData is a DER encoded ASN.1 structure that contains the actual cryptographic parameters. Its specific structure depends on the algorithm. The OIDs for two IBE algorithms, the Boneh-Franklin and Boneh-Boyen algorithms and their publicParameterData structures are defined in [IBCS]. The IBESysParams of a district MUST contain at least one algorithm and MAY contain several algorithms. It MUST NOT contain two or more IBEPublicParameter entries with the same algorithm. A client that wants to use IBESysParams can chose any of the algorithms specified in the publicParameterData structure. If a client does not support any of the supported algorithms it MUST generate an error message.A client MUST implement at least the Boneh-Franklin algorithm and MAY implement the Boneh-Boyens and other algorithms. ibeIdentitySchema is an OID that defines the type of identities that are used with this district. The OIDs and the required and optional fields for each OID are described in [IBECMS]. IBEParamExtensions is a set of extensions that are defined the same way as X.509 extensions. IBEParamExtensions ::= SEQUENCE OF Extensions Extension ::= SEQUENCE { id OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, value OCTET STRING } ibeParamExt OBJECT IDENTIFIER ::= { ibcs ibcs3(3) parameter-extensions(2) } The contents of the octet string are defined by the specific extension type. The System Parameters of a district MAY have any number of extensions, including zero. A client that encounters an Appenzeller Expires December 14, 2006 [Page 5] Internet-Draft Parameter and Policy Lookup June 2006 extension SHOULD fail if the extension is critical and SHOULD ignore it silently if the extension is not critical. The Extension pkgURL as defined in section 5 defines the URL of the Private Key Generator of the district. If the PKG is publicly accessible, this extension SHOULD be present to allow the automatic retrieval of private keys for recipients of encrypted messages. For this extension the OCTET STRING contains a UTF8String with the full URL of the key server. Appenzeller Expires December 14, 2006 [Page 6] Internet-Draft Parameter and Policy Lookup June 2006 5. ASN.1 Module This section defines the ASN.1 module for the encodings discussed in section 4. IBEPP { joint-iso-itu(2) country(16) us(840) organization(1) identicrypt(114334) ibcs(1) pps(4) version(1) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS IBEIdentitySchema FROM BFCMS { joint-iso-itu(2) country(16) us(840) organization(1) identicrypt(114334) ibcs(1) cms(4) module(5) version(1) }; ibcs OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) us(840) organization(1) identicrypt(114334) ibcs(1) } -- The IBE System parameters consist of a set of public parameters -- for the encryption algorithms supported by the district, -- the identity schema, the URL of the PKG and further optional -- parameters IBESysParams ::= SEQUENCE { version INTEGER, districtName UTF8String, districtSerial INTEGER, validity Validity, ibePublicParameters IBEPublicParameters, ibeIdentitySchema OBJECT IDENTIFIER, ibeParamExtensions IBEParamExtensions } -- Validity designates the time interval for which these parameters -- are valid. It is defined the same as in X.509 Validity ::= SEQUENCE { notBefore CertificateValidityDate, notAfter CertificateValidityDate } CertificateValidityDate ::= CHOICE { utcTime UTCTime, generalTime GeneralizedTime Appenzeller Expires December 14, 2006 [Page 7] Internet-Draft Parameter and Policy Lookup June 2006 } -- Public Parameters for the IBE Algorithm -- ibeAlgorithm is the algorithm OID from IBCS, e.g. "bb" or "bf" -- publicParameterData is a DER encoded ASN.1 public parameter -- block, e.g. BFPublicParamaters, BBPublicParamaters IBEPublicParameters ::= SEQUENCE OF IBEPublicParameter IBEPublicParameter ::= SEQUENCE { ibeAlgorithm OBJECT IDENTIFIER, publicParameterData OCTET STRING } -- Extensions are defined the same as in X.509 IBEParamExtensions ::= SEQUENCE OF Extension Extension ::= SEQUENCE { id OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, value OCTET STRING } ibeParamExt OBJECT IDENTIFIER ::= { ibcs ibcs3(3) parameter-extensions(2) } -- Defined Extensions: -- pkgURL: URL of the PKG, value is a UTF8String pkgURL OBJECT IDENTIFIER ::= { ibeParamExt pkgURL(1) } END 6. Security Considerations This entire document relates to security considerations. 7. IANA Considerations No further action by the IANA is necessary for the protocols described in this document. Appenzeller Expires December 14, 2006 [Page 8] Internet-Draft Parameter and Policy Lookup June 2006 8. References 8.1. Normative References [CMS] R. Housley, “Cryptographic Message Syntax,” RFC 3369, August 2002. [KEY] S. Brander, “Key Words for Use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997. [P1363] IEEE P1363.3, “Standards Specifications for Public-Key Cryptography,” 2001. [SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", Netscape Communications Corp., Nov 18, 1996. [TLS] T. Dierks, E. Rescorla, “The Transport Layer Security Protocol Version 1.1,” RFC 4346, April 2006. [X509] ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, June 1997. [IBEARCH] L. Martin, M. Schertler, “Identity-based Encryption Architecture,” draft-ietf-smime-ibearch-00.txt. [IBCS] X. Boyen, L. Martin, “Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems,” draft-ietf-smime-ibcs-00.txt. [IBECMS] M. Schertler, L. Martin, “Using the Boneh-Franklin identity- based encryption algorithm with the Cryptographic Message Syntax (CMS),” draft-ietf-smime-bfibecms-01.txt. [IBEPKG] G. Appezeller “Private Key Request protocol for Identity- Based Encryption,” draft-ietf-smime-ibepkg-00.txt. [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.Author's Address [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frysyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Appenzeller Expires December 14, 2006 [Page 9] Internet-Draft Parameter and Policy Lookup June 2006 Author's Address Guido Appenzeller Voltage Security 1070 Arastradero Rd Suite 100 Palo Alto CA 94304 Phone: +1 650 543 1280 Email: guido@voltage.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). Appenzeller Expires December 14, 2006 [Page 10] Internet-Draft Parameter and Policy Lookup June 2006 This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Appenzeller Expires December 14, 2006 [Page 11]