Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS)
draft-ietf-smime-bfibecms-10

L. Martin 
     S/MIME Working Group                           Voltage Security 
     Internet Draft                                     M. Schertler 
     Intended status: Standards Track      Tumbleweed Communications 
     Expires: January 2009                                 July 2008 
      
                                       
          Using the Boneh-Franklin and Boneh-Boyen Identity-based 
        Encryption Algorithms with the Cryptographic Message Syntax 
                                   (CMS)  

                     <draft-ietf-smime-bfibecms-10.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 January 2009          [Page 1] 
      

     Internet-Draft            Using IBE with CMS          July 2008 
         

     Table of Contents 

         
        1. Introduction............................................2 
           1.1. Terminology........................................3 
           1.2. IBE overview.......................................3 
        2. Using identity-based encryption.........................4 
        3. Key encryption algorithm identifiers....................7 
        4. Processing by the sender................................8 
        5. Processing by the receiver..............................8 
        6. ASN.1 module............................................9 
        7. Security considerations................................11 
           7.1. Attacks that are outside the scope of this 
           document...............................................11 
           7.2. Attacks that are within the scope of this 
           document...............................................12 
           7.3. Attacks to which the protocols defined in this 
           document are susceptible...............................12 
        8. IANA considerations....................................13 
        9. References.............................................14 
           9.1. Normative references..............................14 
           9.2. Informative references............................14 
        Authors' Addresses........................................15 
        Intellectual property statement...........................15 
        Disclaimer of validity....................................16 
        Copyright statement.......................................16 
        Acknowledgment............................................16 
         
     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 
      
      
     Martin, Schertler        Expires January 2009          [Page 2] 
         

     Internet-Draft            Using IBE with CMS          July 2008 
         

        algorithms, and these steps are defined in Sections 4 and 5 
        of this document respectively. 

        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 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]. All communications 
           between users of an IBE system and the PPS or PKG MUST be 
           protected using TLS [TLS] as described in [IBE]. This 
           provides confidentiality and integrity of all information 
           that is delivered to users as well as authentication of 
           the PPS and PKG. 

      
      
     Martin, Schertler        Expires January 2009          [Page 3] 
         

     Internet-Draft            Using IBE with CMS          July 2008 
         

     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 the following: 

        ibeORIType OBJECT IDENTIFIER ::= {  
          joint-iso-itu(2) country(16) us(840)  
          organization(1) identicrypt(114334)  
          ibcs(1) cms(4) ori-oid(1) version(1) 
        } 
         
        ibeORIValue defines the identity that was used in the IBE 
        algorithm to encrypt the CEK. This is an IBERecipientInfo 
        type, which is defined as follows:  

        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 MUST be set as follows. 

        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. This 
        SHOULD be set to uriPPSOID [IBE] which is defined to be the 
        following: 

      
      
     Martin, Schertler        Expires January 2009          [Page 4] 
         

     Internet-Draft            Using IBE with CMS          July 2008 
         

        uriPPSOID OBJECT IDENTIFIER ::= {  
          joint-iso-itu-t(2) country(16) us(840)  
          organization(1) identicrypt(114334)  
          pps-schemas(3) ic-schemas(1) pps-uri(1) version(1)  
        } 
         
        The recipientIdentity is the data that the sender used to 
        calculate the IBE public key that the sender used to encrypt 
        the content-encryption key. This recipientIdentity is used 
        to calculate IBE public and private keys as described in 
        [IBCS]. This MUST be a DER-encoded [DER] IBEIdentityInfo 
        type [IBE], which is defined as follows:  

        IBEIdentityInfo ::= SEQUENCE { 
          district        IA5String, 
          serial          INTEGER, 
          identityType    OBJECT IDENTIFIER, 
          identityData    OCTET STRING 
        } 
         
        The identityType 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 EmailIdentityData type. The value 
        of cmsIdentityOID is the following:  

        cmsIdentityOID OBJECT IDENTIFIER ::= {  
          joint-iso-itu-t(2) country(16) us(840)  
          organization(1) identicrypt(114334)  
          keyschemas(2) icschemas(1) email(1) version(1) 
        } 
         
        The identityData MUST be an EmailIdentityData type, which is 
        defined as follows: 

        EmailIdentityData ::= SEQUENCE { 
          rfc822Name   IA5String, 
          time         GeneralizedTime 
        } 
         
        The rfc822Name field is the e-mail address of the recipient 
        in the format defined in Section 4.2.1.6 of [PKIX] for the 
        rfc822Name subjectAltName variant. Rules for encoding 
        Internet mail addresses that include internationalized 
        domain names are specified in Section 7.5 of [PKIX].  

      
      
     Martin, Schertler        Expires January 2009          [Page 5] 
         

     Internet-Draft            Using IBE with CMS          July 2008 
         

        The value of the time field 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. The value of "time" MUST be expressed in 
        Greenwich Mean Time(Zulu), MUST include seconds (i.e. times 
        are always YYYYMMDDHHMMSSZ), even where the number of 
        seconds is equal to zero and MUST be 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. 

           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. Suppose that 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 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 
      
      
     Martin, Schertler        Expires January 2009          [Page 6] 
         

     Internet-Draft            Using IBE with CMS          July 2008 
         

        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 sequence of OID-value pairs 
        that are defined to be the following: 

        OIDValuePairs ::= SEQUENCE { 
          fieldID     OBJECT IDENTIFIER,   
          fieldData   OCTET STRING 
        } 
         
        These 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. A client 
        MUST ignore any part of serverInfo that it is unable to 
        process. 

        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. 

      
      
     Martin, Schertler        Expires January 2009          [Page 7] 
         

     Internet-Draft            Using IBE with CMS          July 2008 
         

        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: 

           1. Determines that the CEK is IBE-encrypted by noting that 
             the oriType of the OtherRecipientInfo type is set to 
             ibeORIType. 
      
      
     Martin, Schertler        Expires January 2009          [Page 8] 
         

     Internet-Draft            Using IBE with CMS          July 2008 
         

           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]. 

     6. ASN.1 module 

        The following ASN.1 module summarizes the ASN.1 definitions 
        defined by this document.  

      
      
     Martin, Schertler        Expires January 2009          [Page 9] 
         

     Internet-Draft            Using IBE with CMS          July 2008 
         

        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 
         
        IMPORTS IBEIdentityInfo, uriPPSOID FROM  
         
           IBEARCH-module { joint-iso-itu-t(2) country(16) 
              us(840) organization(1) identicrypt(114334) ibcs(1) 
              ibearch(5) module(5) version(1)  
           };   
         
        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) version(1) 
        } 
         
        IBERecipientInfo ::= SEQUENCE { 
          cmsVersion         INTEGER { v3(3) }, 
          keyFetchMethod     OBJECT IDENTIFIER, 
          recipientIdentity  IBEIdentityInfo, 
          serverInfo         SEQUENCE SIZE (1..MAX) OF  
            OIDValuePairs OPTIONAL, 
          encryptedKey       EncryptedKey 
        } 
         
         
        OIDValuePairs ::= SEQUENCE { 
          fieldID     OBJECT IDENTIFIER,   
          fieldData   OCTET STRING 
        } 
         
        EncryptedKey ::= OCTET STRING 
         
        EmailIdentityData ::= SEQUENCE { 
          rfc822Name   IA5String, 
          time         GeneralizedTime 
        } 
      
      
     Martin, Schertler        Expires January 2009         [Page 10] 
         

     Internet-Draft            Using IBE with CMS          July 2008 
         

         
        cmsIdentityOID OBJECT IDENTIFIER ::= {  
          joint-iso-itu-t(2) country(16) us(840)  
          organization(1) identicrypt(114334)  
          keyschemas(2) icschemas(1) email(1) version(1)  
        } 
      
        END 
         
     7. Security considerations 

        This document is based on [CMS], [IBCS] and [IBE], 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 PKG or the ability to modify the 
        information distributed by the PPS 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. 

      
      
     Martin, Schertler        Expires January 2009         [Page 11] 
         

     Internet-Draft            Using IBE with CMS          July 2008 
         

        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 
        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. 
      
      
     Martin, Schertler        Expires January 2009         [Page 12] 
         

     Internet-Draft            Using IBE with CMS          July 2008 
         

        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 

        No further action by the IANA is necessary for this 
        document. 

      
      
     Martin, Schertler        Expires January 2009         [Page 13] 
         

     Internet-Draft            Using IBE with CMS          July 2008 
         

     9. References 

     9.1. Normative references 

        [ASN1] ITU-T Recommendation X.680: Information Technology - 
                  Abstract Syntax Notation One (ASN.1): 
                  Specification of Basic Notation," July 2002. 

        [CMS] R. Housley, "Cryptographic Message Syntax," RFC 3852, 
                  July 2004. 

        [DER] ITU-T Recommendation X.690: OSI Networking and System 
                  Aspects: Abstract Syntax Notation One (ASN.1), 
                  July 2002. 

        [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. 

        [IBCS] X. Boyen and L. Martin, "Identity-based Cryptography 
                  Standard (IBCS) #1: Supersingular Curve 
                  Implementations of the BF and BB1 Cryptosystems," 
                  RFC 5091, December 2007.  

        [IBE] G. Appenzeller, L. Martin and M. Schertler, "Identity-
                  based Encryption Architecture," draft-ietf-smime-
                  ibearch-06.txt. 

        [KEYWORDS] S. Brander, "Key Words for Use in RFCs to 
                  Indicate Requirement Levels," BCP 14, RFC 2119, 
                  March 1997. 

        [PKIX] D. Cooper, et al., "Internet X.509 Public Key 
                  Infrastructure Certificate and Certificate 
                  Revocation List (CRL) Profile," RFC 5280, May 
                  2008. 

        [TLS] T. Dierks and E. Rescorla, "The Transport Layer 
                  Security (TLS) Protocol Version 1.1," RFC 4346, 
                  April 2006. 

     9.2. Informative references 

        [BGPDOS] D. Turk, "Configuring BGP to Block Denial-of-
                  Service Attacks," RFC 3882, September 2004. 

      
      
     Martin, Schertler        Expires January 2009         [Page 14] 
         

     Internet-Draft            Using IBE with CMS          July 2008 
         

        [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 
        USA 
            
        Phone: +1 650 543 1280 
        Email: martin@voltage.com 
         
        Mark Schertler 
        Tumbleweed Communications 
        700 Saginaw Dr 
        Redwood City CA 94063 
        USA 
            
        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 January 2009         [Page 15] 
         

     Internet-Draft            Using IBE with CMS          July 2008 
         

        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 (2008). 

        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 January 2009         [Page 16]