[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                           Voltage Security
     Internet Draft                                   Mark Schertler
     Expires: March 2008                   Tumbleweed Communications
                                                      September 2007
     
     
          Using the Boneh-Franklin and Boneh-Boyen identity-based
        encryption algorithms with the Cryptographic Message Syntax
                                   (CMS)
     
     
                     <draft-ietf-smime-bfibecms-06.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 March 2008           [Page 1]
     

     Internet-Draft            Using IBE with CMS     September 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....................7
        4. Processing by the sender................................7
        5. Processing by the receiver..............................8
        6. ASN.1 module............................................9
        7. Security considerations................................10
           7.1. Attacks that are outside the scope of this document10
           7.2. Attacks that are within the scope of this document11
           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....................................15
        Copyright statement.......................................15
        Acknowledgment............................................15
     
     1. Introduction
     
        This document defines the way to use the Boneh-Franklin
        [IBCS] and Boneh-Boyen [IBCS] 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 March 2008           [Page 2]
     

     Internet-Draft            Using IBE with CMS     September 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:
     
     
     
     
     Martin, Schertler         Expires March 2008           [Page 3]
     

     Internet-Draft            Using IBE with CMS     September 2007
     
     
        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
     
        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 SIZE (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].
     
     
     
     
     Martin, Schertler         Expires March 2008           [Page 4]
     

     Internet-Draft            Using IBE with CMS     September 2007
     
     
        IBEIdentityInfo ::= SEQUENCE {
          district        IA5String,
          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].
     
        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) TEXTMSGemail(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 [DER] before
        placing it in the OCTET STRING.
     
        EmailIdentitySchema ::= SEQUENCE {
          TEXTMSGEmail IA5String,
          time        GeneralizedTime
        }
     
        The TEXTMSGEmail is the e-mail address of the recipient in
        the format defined by [TEXTMSG]. E-mail addresses that
        contain non-ASCII characters MUST be encoded using punycode
        [PUNYCODE].
     
        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.
     
     
     
     Martin, Schertler         Expires March 2008           [Page 5]
     

     Internet-Draft            Using IBE with CMS     September 2007
     
     
        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.
     
           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
     
     
     Martin, Schertler         Expires March 2008           [Page 6]
     

     Internet-Draft            Using IBE with CMS     September 2007
     
     
        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].
     
        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.
     
     
     
     
     Martin, Schertler         Expires March 2008           [Page 7]
     

     Internet-Draft            Using IBE with CMS     September 2007
     
     
           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:
     
           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 March 2008           [Page 8]
     

     Internet-Draft            Using IBE with CMS     September 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 SIZE (1..MAX) OF
            OIDValuePairs OPTIONAL,
          encryptedKey       EncryptedKey
        }
     
        IBEIdentityInfo ::= SEQUENCE {
          district        IA5String,
          serial          INTEGER,
          identitySchema  OBJECT IDENTIFIER,
          identityData    OCTET STRING
        }
     
        OIDValuePairs ::= SEQUENCE {
          fieldID     OBJECT IDENTIFIER,
          fieldData   OCTET STRING
        }
     
        EncryptedKey ::= OCTET STRING
     
        EmailIdentitySchema ::= SEQUENCE {
          TEXTMSGEmail IA5String,
          time         GeneralizedTime
        }
     
     
     Martin, Schertler         Expires March 2008           [Page 9]
     

     Internet-Draft            Using IBE with CMS     September 2007
     
     
     
        cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
        country(16)
          us(840) organization(1) identicrypt(114334) keyschemas(2)
          icschemas(1) TEXTMSGemail(1)
        }
     
        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.
     
     
     
     
     Martin, Schertler         Expires March 2008          [Page 10]
     

     Internet-Draft            Using IBE with CMS     September 2007
     
     
        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 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
     
     
     Martin, Schertler         Expires March 2008          [Page 11]
     

     Internet-Draft            Using IBE with CMS     September 2007
     
     
        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 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 [DOS, BGPDOS]
        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 March 2008          [Page 12]
     

     Internet-Draft            Using IBE with CMS     September 2007
     
     
     9. References
     
     9.1. Normative references
     
        [CMS] R. Housley, "Cryptographic Message Syntax," RFC 3852,
                  July 2004.
     
        [DOS] 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.
     
        [KEYWORDS] S. Brander, "Key Words for Use in RFCs to
                  Indicate Requirement Levels," BCP 14, RFC 2119,
                  March 1997.
     
        [PUNYCODE] A. Costello, "Punycode: A Bootstring encoding of
                  Unicode for Internationalized Domain Names in
                  Applications (IDNA)," RFC 3492, March 2003.
     
        [TEXTMSG] D. Crocker, "Standard for the format of ARPA
                  internet text messages," RFC 2822, April 2001.
     
        [TLS] T. Dierks and E. Rescorla, "The Transport Layer
                  Security (TLS) Protocol Version 1.1," RFC 4346,
                  April 2006.
     
     9.2. Informative references
     
        [ASN1] CCITT, "Recommendation X.209: Specification of Basic
                  Encoding Rules for Abstract Syntax Notation One
                  (ASN.1)," 1998.
     
        [DER] ITU-T Recommendation X.680: Information Technology -
                  Abstract Syntax Notation One, 1997.
     
        [IBCS] X. Boyen, L. Martin, "Identity-based Cryptography
                  Standard (IBCS) #1: Supersingular Curve
                  Implementations of the BF and BB1 Cryptosystems,"
                  draft-martin-ibcs-06.txt.
     
        [IBE] G. Appenzeller, L. Martin and M. Schertler, "Identity-
                  based Encryption Architecture," draft-ietf-smime-
                  ibearch-04.txt.
     
        [BGPDOS] D. Turk, "Configuring BGP to Block Denial-of-
                  Service Attacks," RFC 3882, September 2004.
     
     
     
     Martin, Schertler         Expires March 2008          [Page 13]
     

     Internet-Draft            Using IBE with CMS     September 2007
     
     
     
     
        [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.
     
     
     
     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
        Tumbleweed Communications
        700 Saginaw Dr
        Redwood City CA 94063
     
        Phone: +1 650 216 2039
        Email: mark.schertler@tumbleweed.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.
     
     
     Martin, Schertler         Expires March 2008          [Page 14]
     

     Internet-Draft            Using IBE with CMS     September 2007
     
     
        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, 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 March 2008          [Page 15]
     

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