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

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 5409

                                                                   L. Martin
     S/MIME Working Group                                       M. Schertler
     Internet Draft                                         Voltage Security
     Expires: November 2007                                         May 2007
     
     
     
         Using the Boneh-Franklin and Boneh-Boyen identity-based encryption
               algorithms with the Cryptographic Message Syntax (CMS)
     
     
                         <draft-ietf-smime-bfibecms-03.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 the conventions for using the Boneh-Franklin
        (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in
        the Cryptographic Message Syntax (CMS) to encrypt content encryption
        keys. Object identifiers and the convention for encoding a
        recipient's identity are also defined.
     
     
     
     
     
     
     Martin, Schertler       Expires November 2007                  [Page 1]
     

     Internet-Draft            Using IBE with CMS                   May 2007
     
     
     Table of Contents
     
     
        1. Introduction...................................................2
           1.1. Terminology...............................................3
           1.2. IBE overview..............................................3
        2. Using identity-based encryption................................3
        3. Key encryption algorithm identifiers...........................6
        4. Processing by the sender.......................................7
        5. Processing by the receiver.....................................7
        6. ASN.1 module...................................................9
        7. Security considerations.......................................10
           7.1. Attacks that are outside the scope of this document......10
           7.2. Attacks that are within the scope of this document.......11
           7.3. Attacks to which the protocols defined in this document are
           susceptible...................................................11
        8. IANA considerations...........................................12
        9. References....................................................13
           9.1. Normative references.....................................13
           9.2. Informative references...................................13
        Authors' Addresses...............................................14
        Intellectual property statement..................................14
        Disclaimer of validity...........................................14
        Copyright statement..............................................15
        Acknowledgment...................................................15
     
     1. Introduction
     
        This document defines the way to use the Boneh-Franklin [BF] and
        Boneh-Boyen [BB1] identity-based encryption (IBE) public-key
        algorithms in the Cryptographic Message Syntax (CMS) [CMS]. IBE is a
        public key technology for encrypting content-encryption keys (CEKs)
        that can be implemented within the framework of the CMS: the
        recipient's identity is incorporated into the EnvelopedData CMS
        content type using the OtherRecipientInfo CHOICE in the RecipientInfo
        field as defined in section 6.2.5 of [CMS]. This document does not
        describe the implementation of the BF and BB1 algorithms, which are
        described in detail in [IBCS].
     
        IBE algorithms are a type of public-key cryptographic algorithm in
        which the public key is calculated directly from a user's identity
        instead of being generated randomly. This requires a different set of
        steps for encryption and decryption than would be used with other
        public-key algorithms, and these steps are defined in Sections 4 and
        5 of this document respectively.
     
     
     
     
     Martin, Schertler       Expires November 2007                  [Page 2]
     

     Internet-Draft            Using IBE with CMS                   May 2007
     
     
        This document also defines the object identifiers and syntax of the
        object that is used to define the identity of a message recipient.
     
        CMS values and identity objects are defined using ASN.1 [ASN1].
     
     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 [KEYWORDS].
     
     1.2. IBE overview
     
        In addition to the client components that are described in this
        document, the following additional components are required for a
        complete IBE messaging system:
     
              o  A Private-key Generator (PKG). The PKG contains the
                 cryptographic material, known as a master secret, for
                 generating an individual's IBE private key. A PKG accepts an
                 IBE user's private key request and, after successfully
                 authenticating them in some way, returns their IBE private
                 key.
     
              o  A Public Parameter Server (PPS). IBE System Parameters
                 include publicly sharable cryptographic material, known as
                 IBE public parameters, and policy information for the PKG. A
                 PPS provides a well-known location for secure distribution
                 of IBE public parameters and policy information for the IBE
                 PKG.
     
           The interaction of senders and receivers of IBE-encrypted messages
           are described in [IBE].
     
     2. Using identity-based encryption
     
        To use IBE, the ori field in RecipientInfo MUST be used. The fields
        are set as follows: oriType is set to ibeORIType; oriValue is set to
        ibeORIValue.
     
        These fields have the following meanings:
     
        ibeORIType defines the object identifier (OID) that indicates that
        the subsequent ibeORIValue is the information necessary to decrypt
        the message using IBE. This field MUST be set to
     
     
     
     
     Martin, Schertler       Expires November 2007                  [Page 3]
     

     Internet-Draft            Using IBE with CMS                   May 2007
     
     
        ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16)
          us(840) organization(1) identicrypt(114334) ibcs(1)
          cms(4) ori-oid(1) }
     
        ibeORIValue defines the identity that was used in the IBE algorithm
        to encrypt the CEK. This is an IBERecipientInfo type.
     
        IBERecipientInfo ::= SEQUENCE {
          cmsVersion         INTEGER { v3(3) },
          keyFetchMethod     OBJECT IDENTIFIER,
          recipientIdentity  IBEIdentityInfo,
          serverInfo         SEQUENCE (1..MAX) OF OIDValuePairs OPTIONAL,
          encryptedKey       EncryptedKey
        }
     
        The fields of IBERecipientInfo have the following meanings:
     
        The cmsVersion MUST be set to 3.
     
        The keyFetchMethod is the OID that defines the method of retrieving
        the private key that the recipient MUST use. How to retrieve an IBE
        private key using the steps defined in [IBE] is defined by the
        keyFetchMethod OID. The method for retrieving private keys that is
        specified in [IBE] is defined by cmsPPSOID.
     
        cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
          us(840) organization(1) identicrypt(114334) pps-schemas(3)
          ic-schemas(1) pps-uri(1)
        }
     
        The recipientIdentity is the data that was used to calculate the IBE
        public key that was used to encrypt the content-encryption key. This
        MUST be an IBEIdentityInfo type. This recipientIdentity is used to
        calculate IBE public and private keys as described in [IBCS].
     
        IBEIdentityInfo ::= SEQUENCE {
          district        UTF8STRING,
          serial          INTEGER,
          identitySchema  OBJECT IDENTIFIER,
          identityData    OCTET STRING
        }
     
        The fields of IBEIdentityInfo have the following meanings.
     
        The district and serial are unique identifiers that are used to
        construct the URI for the location of the necessary IBE public
        parameters. The construction and use of this URI is defined in [IBE].
     
     
     Martin, Schertler       Expires November 2007                  [Page 4]
     

     Internet-Draft            Using IBE with CMS                   May 2007
     
     
        The identitySchema defines the format that is used to encode the
        information that defines the identity of the recipient. This MUST be
        set to cmsIdentityOID to indicate that identityData contains an
        EmailIdentitySchema type.
     
        cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
           us(840) organization(1) identicrypt(114334) keyschemas(2)
           icschemas(1) rfc822email(1)
        }
     
        The identityData field contains the identify information for the
        recipient. If the contents of the field is an ASN.1 structure, the
        structure MUST be DER encoded before placing it in the OCTET STRING.
     
        EmailIdentitySchema ::= SEQUENCE {
          rfc822Email UTF8STRING,
          time        GeneralizedTime
        }
     
        The rfc822Email is the e-mail address of the recipient in the format
        defined by [RFC822]. E-mail addresses that contain non-ASCII
        characters MUST be encoded using punycode [RFC3492].
     
        The value of "time" is the UTC time after which the sender wants to
        let the recipient decrypt the message, so it may be called the "not-
        before" time. This is usually set to the time when the message is
        encrypted, but MAY be set to a future time. UTC time values are
        expressed to the nearest second.
     
        The sender of an IBE-encrypted message may want to express this time
        rounded to a time interval to create a key lifetime. A key lifetime
        reduces the number of IBE private keys that a recipient needs to
        retrieve, but still forces the IBE user to periodically re-
        authenticate. Based on the time interval chosen a recipient would
        only have to retrieve a new IBE key once during the interval. To do
        this, follow the following steps. Let "time-interval" be the number
        of seconds in this larger time interval.
     
     
     
     
     
     
     
     
     
     
     
     
     Martin, Schertler       Expires November 2007                  [Page 5]
     

     Internet-Draft            Using IBE with CMS                   May 2007
     
     
           1. Find the GeneralizedTime for the not-before value.
           2. Convert this GeneralizedTime into the number of seconds
              since January 1, 1970. Call this "total-time."
           3. Calculate reduced-time = (floor (total-time /
              time-interval)) * time-interval.
           4. Convert reduced-time to a GeneralizedTime to get the
              not-before "time" value.
     
        An example of this algorithm for computing a one week time interval
        is as follows.
     
           1. Say the GeneralizedTime is 20020401000000Z.
           2. Then the total-time is 1017612000.
           3. A time-interval of 1 week is 604800 seconds.
              So the reduced-time = (floor(1017612000/604800))*
              604800 = 1017273600.
           4. This gives the reduced-time GeneralizedTime form of the
              reduced-time of 20020328000000Z.
     
        When issuing IBE private keys, a PKG SHOULD NOT issue them too far
        into the future. This restriction is to prevent an adversary who
        obtains an IBE user's authentication credentials from requesting
        private keys far into the future and therefore negating the periodic
        IBE user re-authentication that key lifetime provides. For example if
        a one week period is chosen for the key lifetime, then IBE private
        keys should not be issued more than 1 week in advance. Otherwise once
        an adversary gains access to the PKG via the stolen IBE user
        credentials they can request all future keys and negate the IBE user
        authentication restraints in place.
     
        The serverInfo is an optional series of OID-value pairs that can be
        used to convey any other information that might be used by a PKG.
        Examples of such information could include the user interface that
        the recipient will experience. Differences in the user interface
        could include localization information or commercial branding
        information.
     
        The encryptedKey is the result of encrypting the CEK with an IBE
        algorithm using recipientIdentity as the IBE public key.
     
     3. Key encryption algorithm identifiers
     
        The BF and BB1 algorithms as defined in [IBCS] have the following
        object identifiers. These object identifiers are also defined in the
        ASN.1 module in [IBCS].
     
     
     
     
     Martin, Schertler       Expires November 2007                  [Page 6]
     

     Internet-Draft            Using IBE with CMS                   May 2007
     
     
        bf OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
           organization(1) identicrypt(114334) ibcs(1) ibcs1(1)
           ibe-algorithms(2) bf(1) }
     
        This is the object identifier that MUST be inserted in the
        keyEncryptionAlgorithm field in the CMS when the BF algorithm is used
        to encrypt the CEK.
     
        bb1 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
           organization(1) identicrypt(114334) ibcs(1) ibcs1(1)
           ibe-algorithms(2) bb1(2) }
     
        This is the object identifier that MUST be inserted in the
        keyEncryptionAlgorithm field in the CMS when the BB1 algorithm is
        used to encrypt the CEK.
     
     4. Processing by the sender
     
        The sender of a message that uses IBE to encrypt content encryption
        keys performs the following steps:
     
           1. Selects a set of IBE public parameters to use in the subsequent
        steps in accordance with his local security policy. He then
        determines the URI where the public parameters can be obtained using
        the process described in [IBE]. This information MUST be encoded in
        the IBEIdentityInfo as described in Section 2.
     
           2. Sets the fields of an OtherRecipientInfo object to their
        appropriate values as described in Section 2.
     
           3. Calculates an IBE public key as defined in [IBCS] using this
        IBEIdentityInfo as the identity information.
     
           4. This IBE public key is then used to encrypt the content
        encryption key (CEK), using the algorithms that are defined in
        [IBCS].
     
           5. Sets encryptedKey to the IBE-encrypted CEK.
     
           6. Within the CMS, keyEncryptionAlgorithm MUST then be set to the
        appropriate OID for the IBE algorithm that was used (see Section 3).
     
     5. Processing by the receiver
     
        Upon receiving a message that has a CEK encrypted with IBE, the
        recipient performs the following steps to decrypt the CEK:
     
     
     
     Martin, Schertler       Expires November 2007                  [Page 7]
     

     Internet-Draft            Using IBE with CMS                   May 2007
     
     
           1. Determines that the CEK is IBE-encrypted by noting that the
             oriType of the OtherRecipientInfo type is set to ibeORIType.
     
           2. Determines that the recipientIdentity was used as the identity
             in IBE encryption of the CEK.
     
           3. Determines the location of the IBE public parameters and the
             IBE Private Key Generator as described in [IBE].
     
           4. Obtains the IBE public parameters from the location determined
             in Step 3 using the process defined in [IBE].
     
           5. Obtains the IBE private key needed to decrypt the encrypted CEK
             using the process defined in [IBE].
     
           6. Decrypts the CEK using the IBE private key obtained in Step 4
             using the algorithms described in [IBCS].
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Martin, Schertler       Expires November 2007                  [Page 8]
     

     Internet-Draft            Using IBE with CMS                   May 2007
     
     
     6. ASN.1 module
     
        IBECMS-module { joint-iso-itu-t(2) country(16) us(840)
        organization(1)
          identicrypt(114334) ibcs(1) cms(4) module(5) version(1)
        }
     
        DEFINITIONS IMPLICIT TAGS ::= BEGIN
     
        IBEOtherRecipientInfo ::= SEQUENCE {
          oriType   OBJECT IDENTIFIER,
          oriValue  IBERecipientInfo
        }
     
        ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
          us(840) organization(1) identicrypt(114334) ibcs(1)
          cms(4) ori-oid(1)
        }
     
        IBERecipientInfo ::= SEQUENCE {
          cmsVersion         INTEGER { v3(3) },
          keyFetchMethod     OBJECT IDENTIFIER,
          recipientIdentity  IBEIdentityInfo,
          serverInfo         SEQUENCE (1..MAX) OF OIDValuePairs OPTIONAL,
          encryptedKey       EncryptedKey
        }
     
        IBEIdentityInfo ::= SEQUENCE {
          district        UTF8STRING,
          serial          INTEGER,
          identitySchema  OBJECT IDENTIFIER,
          identityData    OCTET STRING
        }
     
        OIDValuePairs ::= SEQUENCE {
          fieldID     OBJECT IDENTIFIER,
          fieldData   OCTET STRING
        }
     
        EmailIdentitySchema ::= SEQUENCE {
          rfc822Email  UTF8STRING,
          time         GeneralizedTime
        }
     
        cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
          us(840) organization(1) identicrypt(114334) keyschemas(2)
          icschemas(1) rfc822email(1)
     
     
     Martin, Schertler       Expires November 2007                  [Page 9]
     

     Internet-Draft            Using IBE with CMS                   May 2007
     
     
        }
     
        cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
          us(840) organization(1) identicrypt(114334) pps-schemas(3)
          ic-schemas(1) pps-uri(1)
        }
     
        END
     
     7. Security considerations
     
        This document is based on [CMS] and [IBCS], and the relevant security
        considerations of those documents apply.
     
     7.1. Attacks that are outside the scope of this document
     
        Attacks on the cryptographic algorithms that are used to implement
        IBE are outside the scope of this document. Such attacks are detailed
        in [IBCS], which defines parameters that give 80-bit, 112-bit, 128-
        bit and 256-bit encryption strength. We assume that capable
        administrators of an IBE system will select parameters that provide a
        sufficient resistance to cryptanalytic attacks by adversaries.
     
        Attacks that give an adversary the ability to access or change the
        information on a PPS or PKG, especially the cryptographic material
        (referred to in this document as the master secret), will defeat the
        security of an IBE system. In particular, if the cryptographic
        material is compromised the adversary will have the ability to
        recreate any user's private key and therefore decrypt all messages
        protected with the corresponding public key. To address this concern,
        it is highly RECOMMENDED that best practices for physical and
        operational security for PPS and PKG servers be followed and that
        these servers be configured (sometimes known as hardened) in
        accordance with best current practices [NIST]. An IBE system SHOULD
        be operated in an environment where illicit access to the PPS and PKG
        is infeasible for attackers to obtain.
     
        Attacks that require administrative or IBE user equivalent access to
        machines used by either the client or the server components defined
        in this document are also outside the scope of this document.
     
        We also assume that all administrators of a system implementing the
        protocols that are defined in this document are trustworthy and will
        not abuse their authority to bypass the security provided by an IBE
        system. This is of particular importance with an IBE system, for an
        administrator of a PKG could potentially abuse his authority and
        configure the PKG to grant him any IBE private key that the PKG is
     
     
     Martin, Schertler       Expires November 2007                 [Page 10]
     

     Internet-Draft            Using IBE with CMS                   May 2007
     
     
        capable of calculating. To minimize the possibility of administrators
        doing this, a system implementing IBE SHOULD implement n-out-of-m
        control for critical administrative functions and SHOULD maintain
        auditable logs of all security-critical events that occur in an
        operating IBE system.
     
        Similarly, we assume that users of an IBE system will behave
        responsibly, not sharing their authentication credentials with
        others. Thus attacks that require such assumptions are outside the
        scope of this document.
     
     7.2. Attacks that are within the scope of this document
     
        Attacks within the scope of this document are those that allow an
        adversary to:
     
              o  passively monitor information transmitted between users of
                 an IBE system and the PPS and PKG
     
              o  masquerade as a PPS or PKG
     
              o  perform a DOS attack on a PPS or PKG
     
              o  easily guess an IBE user's authentication credential
     
     7.3. Attacks to which the protocols defined in this document are
        susceptible
     
        All communications between users of an IBE system and the PPS or PKG
        are protected using TLS [TLS]. The IBE system defined in this
        document provides no additional security for the communications
        between IBE users and the PPS or PKG. Therefore the described IBE
        system is completely dependent on the TLS security mechanisms for
        authentication of the PKG or PPS server and for confidentiality and
        integrity of the communications. Should there be a compromise of the
        TLS security mechanisms, the integrity of all communications between
        an IBE user and the PPS or PKG will be suspect.
     
        The protocols defined in this document do not explicitly defend
        against an attacker masquerading as a legitimate IBE PPS or PKG. The
        protocols rely on the server authentication mechanism of TLS [TLS].
        In addition to the TLS server authentication mechanism IBE client
        software can provide protection against this possibility by providing
        user interface capabilities that allows users to visually determine
        that a connection to PPS and PKG servers is legitimate. This
        additional capability can help ensure that users cannot easily be
     
     
     
     Martin, Schertler       Expires November 2007                 [Page 11]
     

     Internet-Draft            Using IBE with CMS                   May 2007
     
     
        tricked into providing valid authorization credentials to an
        attacker.
     
        The protocols defined in this document are also vulnerable to attacks
        against an IBE PPS or PKG. Denial of service attacks against either
        component can result in users unable to encrypt or decrypt using IBE,
        and users of an IBE system SHOULD take the appropriate
        countermeasures [RFC2827, RFC3882] that their use of IBE requires.
     
        The IBE user authentication method used by an IBE PKG SHOULD be of
        sufficient strength to prevent attackers from easily guessing the IBE
        user's authentication credentials through trial and error.
     
     8. IANA considerations
     
        All of the object identifiers used in this document were assigned by
        the National Institute of Standards and Technology (NIST), so no
        further action by the IANA is necessary for this document.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Martin, Schertler       Expires November 2007                 [Page 12]
     

     Internet-Draft            Using IBE with CMS                   May 2007
     
     
     9. References
     
     9.1. Normative references
     
        [ASN1] CCITT, "Recommendation X.209: Specification of Basic Encoding
                  Rules for Abstract Syntax Notation One (ASN.1)," 1998.
     
        [CMS] R. Housley, "Cryptographic Message Syntax," RFC 3369, August
                  2002.
     
        [IBCS] X. Boyen, L. Martin, "Identity-based Cryptography Standard
                  (IBCS) #1: Supersingular Curve Implementations of the BF
                  and BB1 Cryptosystems," draft-ieft-martin-ibcs-03.txt.
     
        [IBE] G. Appenzeller, L. Martin and M. Schertler, "Identity-based
                  Encryption Architecture," draft-ietf-ibearch-01.txt.
     
        [KEYWORDS] S. Brander, "Key Words for Use in RFCs to Indicate
                  Requirement Levels," BCP 14, RFC 2119, March 1997.
     
        [RFC822] D. Crocker, "Standard for the format of ARPA internet text
                  messages," RFC 822, August 1982.
     
        [RFC2827] P. Ferguson and D. Senie, "Network Ingress Filtering:
                  Defeating Denial of Service Attacks which employ IP Source
                  Address Spoofing," RFC 2827, BCP 38, May 2000.
     
        [RFC3492] A. Costello, "Punycode: A Bootstring encoding of Unicode
                  for Internationalized Domain Names in Applications (IDNA),"
                  RFC 3492, March 2003.
     
        [RFC3882] D. Turk, "Configuring BGP to Block Denial-of-Service
                  Attacks," RFC 3882, September 2004.
     
        [TLS] T. Dierks and E. Rescorla, "The Transport Layer Security (TLS)
                  Protocol Version 1.1," RFC 4346, April 2006.
     
     9.2. Informative references
     
        [NIST] M. Souppaya, J. Wack and K. Kent, "Security Configuration
                  Checklist Program for IT Products - Guidance for Checklist
                  Users and Developers," NIST Special Publication SP 800-70,
                  May 2005.
     
     
     
     
     
     
     Martin, Schertler       Expires November 2007                 [Page 13]
     

     Internet-Draft            Using IBE with CMS                   May 2007
     
     
     Authors' Addresses
     
        Luther Martin
        Voltage Security
        1070 Arastradero Rd Suite 100
        Palo Alto CA 94304
     
        Phone: +1 650 543 1280
        Email: martin@voltage.com
     
        Mark Schertler
        Voltage Security
        1070 Arastradero Rd Suite 100
        Palo Alto CA 94304
     
        Phone: +1 650 543 1280
        Email: mark@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
     
     
     Martin, Schertler       Expires November 2007                 [Page 14]
     

     Internet-Draft            Using IBE with CMS                   May 2007
     
     
        OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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 IETF Trust (2007).
     
        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.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Martin, Schertler       Expires November 2007                 [Page 15]
     

Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/