[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits] [IPR]

Versions: 00

     S/MIME Working Group                                     G. Appenzeller
     Internet Draft                                         Voltage Security
     Expires: December 2006                                        June 2006
     
     
                              Identity-based Encryption
                             Parameter and Policy Lookup
     
     
                          <draft-ietf-smime-ibepps-00.txt>
     
     
     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]
     

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/