S/MIME Working Group Z. Cheng Internet Draft Middlesex U. Expires: October 11, 2008 B. Dan Olym Tech. April 11, 2008 Use of the Identity-Based Cryptographic Algorithms in CMS draft-cheng-smime-ibccms-04.txt Status of this Memo 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 This Internet-Draft will expire on October 11 2008. Abstract This document describes the conventions for using identity-based cryptography algorithms in the Cryptographic Message Syntax (CMS). Table of Contents 1. Introduction..................................................2 1.1. Terminology..............................................3 2. Identity Information Structure................................3 2.1. IBCIdentityInfo Structure................................3 2.2. Double DER-en/decoding...................................5 Cheng & Dan Expires October 11, 2008 [Page 1] Internet-Draft Using IBC with CMS April 2008 3. Using IBS with CMS............................................6 3.1. Signed-Data Content Type for IBS.........................6 3.2. Signature Generation Process.............................6 3.3. Signature Verification Process...........................7 4. Using IBE with CMS............................................8 4.1. Enveloped-Data Content Type for IBE......................8 4.2. CEK Encryption Process...................................9 4.3. CEK Decryption Process...................................9 4.4. Authenticated-Enveloped-Data Content Type for IBE.......10 5. ASN.1 Module.................................................11 6. Security Considerations......................................12 7. IANA Considerations..........................................13 8. Acknowledgments..............................................13 9. References...................................................14 9.1. Normative References....................................14 Author's Addresses..............................................14 Intellectual Property Statement.................................15 Disclaimer of Validity..........................................15 1. Introduction Identity-Based Cryptography (IBC) is a type of public key cryptography in which a public and private key pair is set up in a special way. In an IBC system, there exits a Key Generation Center (KGC), which chooses a master secret and a set of system public parameters. Each user has a unique identifier which can be an arbitrary string. The public key of the user is the identifier or a prescribed unique variant of the user identifier. The corresponding private key is created by using an identity-based key extraction algorithm, which binds the user identifier or the prescribed unique identifier variant with the master secret of the KGC. This document describes the cryptographic message syntax for using identity-based cryptography (IBC) including identity-based encryption (IBE) algorithms and also identity-based signature (IBS) algorithms. The design goal of this set of message syntax's is to make sure that IBE and IBS protected messages can be encoded with the existing CMS [RFC3852, RFC5083] without difficulty. The CMS described in this document takes a unified approach to support both IBE and IBS. Specifically, the subjectKeyIdentifier field in both the SignedData structure [RFC3852], the EnvelopedData structure [RFC3852] and the AuthEnvelopedData structure [RFC5083] is used to carry the necessary IBC identity information. Such information SHOULD include the user identifier, a set of system Cheng & Dan Expires September 11, 2008 [Page 2] Internet-Draft Using IBC with CMS April 2008 public parameters or the system parameter identity and other optional information such as identity-based encryption policies. 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 [RFC2119]. 2. Identity Information Structure To represent the necessary identity information required by IBC algorithms, a generic identity information structure is defined. All the IBC user identity information is organized within this generic structure. Each concrete type of identity encoding schema, which describes a specific identifier format, SHOULD be defined separately and the use of the identity information MAY vary with each IBC algorithm. 2.1. IBCIdentityInfo Structure IBCIdentityInfo defines a generic identity information structure for IBC, which provides the necessary information for a signature verifier or an encrypted-message recipient to locate the IBC system public parameters and to reconstruct the signer or the recipient's encoded identifier used in the signing or encryption process respectively. The definition has considered the general requirements of an IBC system and the proposals in [AMS, MS]. IBCIdentityInfo ::= SEQUENCE { version INTEGER { v1(1) }, domain OCTET STRING, serial INTEGER, identitySchema OBJECT IDENTIFIER, identityData ANY DEFINED BY identitySchema, serverInfo ServerAttributes OPTIONAL, keyFetchMethod OBJECT IDENTIFIER OPTIONAL } Cheng & Dan Expires September 11, 2008 [Page 3] Internet-Draft Using IBC with CMS April 2008 ServerAttributes ::= SET SIZE {1..MAX} OF Attribute Attribute ::= SEQUENCE { attrType OBJECT IDENTIFIER, attrValues SET OF AttributeValue } AttributeValue ::= ANY domain and serial are used to uniquely identify a set of IBC system public parameters. The system public parameters MAY vary with each IBC algorithm. serverInfo provides information of the server which is in charge of the IBC service in the domain. A server MAY act as a KGC to publish the system parameters and provide private keys to users, or it MAY just publish the system public parameters. keyFetchMethod defines a method to retrieve the private key corresponding to the user encoded identifier defined in identityData. This field is designed to be compatible with the IBE architecture [AMS]. The value SHOULD be the following OBJECT IDENTIFIER defined in [MS] if the key fetch method defined in [AMS] is used. cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) us(840) organization(1) identicrypt(114334) pps-schemas(3) ic- schemas(1) pps-uri(1)} or other OBJECT IDENTIFIER defined in a separate document. identitySchema defines the format which is used to encode the information included in identityData to represent a user encoded identifier. The value can be the following OBJECT IDENTIFIER: cmsECSchemaOID OBJECT IDENTIFIER ::= TBD If the cmsECSchemaOID schema is used, identityData MUST carry the value of the following ECIdentitySchema structure, which specifies a unique variant of a user's identifier. ECIdentitySchema ::= SEQUENCE { idTag OCTET STRING, Cheng & Dan Expires September 11, 2008 [Page 4] Internet-Draft Using IBC with CMS April 2008 basicID OCTET STRING, decTime GeneralizedTime OPTIONAL, policyInfo PolicyAttributes OPTIONAL } PolicyAttributes ::= SET SIZE {1..MAX} OF Attribute idTag is used as the prefix of an encoded identifier. It has two possible values "RECP=" and "SIGN=". The idTag "SIGN=" indicates the encoded identifier is used to generate a signature, while the tag "RECP=" indicates that the encoded identifier is used in encryption. Some systems MAY also use the "RECP=" tagged identifiers in the signature. basicID is the user's basic identifier, which can be an arbitrary OCTET STRING such as an email address that uniquely identifies a user in the domain. decTime specifies the time after which the recipient is enabled to decrypt the message. The format of GeneralizedTime can be found in [RFC3852]. policyInfo specifies other encryption policies which control the recipient's decryption process. How to apply a policy and how the policy affects the encoded identifier should be defined in separate documents. The value of identityData defines a unique variant of the user's identifier. 2.2. Double DER-en/decoding The field subjectKeyIdentifier in the SignedData, the EnvelopedData and the AuthEnvelopedData content type in CMS [RFC3852, RFC5083] is of type SubjectKeyIdentifier, which is encoded as an OCTET STRING. To carry the value of IBCIdentityInfo in subjectKeyIdentifier, a double- encoding method MUST be used, namely, the given type of data is first DER-encoded with the defined type and then the result is further DER- encoded as an OCTET STRING. The encoding and decoding process of SubjectKeyIdentifier are specified as follows: Encoding the field subjectKeyIdentifier Cheng & Dan Expires September 11, 2008 [Page 5] Internet-Draft Using IBC with CMS April 2008 1. DER-encode the IBCIdentityInfo. 2. DER-encode the output of Step 1 as the data of an OCTET STRING. Decoding the field subjectKeyIdentifier 1. DER-decode the field as an OCTET STRING 2. DER-decode the output value of Step 1 to an IBCIdentityInfo. Note that, Step 2 in the decoding procedure is only executed when an IBC algorithm is used. 3. Using IBS with CMS 3.1. Signed-Data Content Type for IBS If a signer uses an IBS algorithm, the fields in SignerInfo in the SignedData content type in CMS [RFC3852] have the following meanings: o version is always set to 3, because the subjectKeyIdentifier is used. o sid is of type SubjectKeyIdentifier and the field carries the output of double-DER encoding the IBCIdentityInfo structure as defined in Section 2.2. o digestAlgorithm identifies the message digest algorithm, and any associated parameters, used by the IBS algorithm. o signedAttrs, as defined in CMS [RFC3852], is a collection of attributes that are signed. o signatureAlgorithm identifies the used IBS algorithm. o signature is the result of digital signature generation. The details of the signature depend on the used IBS algorithm. o unsignedAttrs, as defined in CMS [RFC3852], is a collection of attributes that are not signed. 3.2. Signature Generation Process The identity-based signature generation process works as follows: 1. Calculate the message digest by following the procedure defined in Section 5.4. in CMS [RFC3852]. Cheng & Dan Expires September 11, 2008 [Page 6] Internet-Draft Using IBC with CMS April 2008 2. Choose a set of system public parameters, and encode the signer's identifier by following the chosen identitySchema, and obtain the identity-based private key corresponding to the encoded signer identifier. 3. Generate the signature value with the chosen IBS algorithm given the result of Step 1 and 2. 4. Prepare the value of IBCIdentityInfo. The information stored in the structure SHOULD enable the verifier to identify the used system public parameters and reconstruct the encoded signer identifier used for signing. The structure MAY include the information of the server that is in charge of the domain, which MAY further provide information of the system public parameters. 5. Set the value of each field in SignerInfo. The sid field MUST carry the output of double-encoding IBCIdentityInfo. 3.3. Signature Verification Process The identity-based signature verification process works as follows: 1. Decode the fields in SignerInfo with the process as required in CMS [RFC3852]. 2. Calculate the message digest as defined in Section 5.4. in CMS [RFC3852]. 3. If signatureAlgorithm field indicates that the signer used an IBS algorithm, then a. Decode the octet string value of sid with the type IBCIdentityInfo. If the output is not an IBCIdentityInfo structure, the signature verification process fails. b. Use the identity information in the IBCIdentityInfo structure to obtain the system public parameters, and to reconstruct the signer's encoded identifier by following the specified identitySchema. The domain and serial field provide the unique identity of the used system public parameters. The verifier MAY obtain the parameters by any means. The field serverInfo MAY provide information for the parameter retrieval. If the system public parameters can't be retrieved, the signature verification process fails. Cheng & Dan Expires September 11, 2008 [Page 7] Internet-Draft Using IBC with CMS April 2008 4. Verify the signature value with the chosen IBS algorithm given the signature value, the signer's encoded identifier and the system public parameters. 4. Using IBE with CMS 4.1. Enveloped-Data Content Type for IBE If a sender uses an IBE algorithm to encrypt the content-encryption key (CEK), the fields in the EnvelopedData content type in CMS [RFC3852] have the following meaning: o version is always set to 3. o originator MUST be omitted. o recipientInfos MUST be of type KeyAgreeRecipientInfo. o other fields are as defined in Section 6. in CMS [RFC3852]. The meanings of the fields in KeyAgreeRecipientInfo are defined as follows: o version is always set to 3. o originator MUST be of type SubjectKeyIdentifier. The value of the field varies with the used IBE algorithm. If the used IBE algorithm uses the sender's identifier, then the field carries the output of double-encoding the sender's IBCIdentityInfo. Otherwise, the value of the field MUST be a DER-encoded OCTET STRING of value NULL. o ukm depends on the IBE algorithm used. o keyEncryptionAlgorithm identifies the IBE algorithm used. o recipientEncryptedKeys, as defined in CMS [RFC3852], includes a recipient identifier and encrypted key for one or more recipients. Each field in the structure has the following meaning: o rid MUST be of type RecipientKeyIdentifier, and each field in the structure has the following meaning: subjectKeyIdentifier carries the output of double- encoding the recipient's identity information structure IBCIdentityInfo. Cheng & Dan Expires September 11, 2008 [Page 8] Internet-Draft Using IBC with CMS April 2008 date has the meaning as defined in CMS [RFC3852]. other has the meaning as defined in CMS [RFC3852]. o encryptedKey is the ciphertext of encrypting the CEK with the IBE algorithm, and which varies with each IBE algorithm. 4.2. CEK Encryption Process To encrypt a CEK to a recipient, in general the sender performs the following steps: 1. If the algorithm involves the sender's identity, choose a set of system public parameters and encode the sender's identifier for encryption by following the chosen identitySchema, and OPTIONALLY obtain the identity-based private key corresponding to the sender's encoded identifier. 2. Choose a set of system public parameters for the intended recipient. If Step 1 has chosen a parameter set, the same parameter set MUST be used for the recipient. Encode the recipient identifier by following the chosen identitySchema. 3. Compute the ciphertext as the value of encryptedKey by the IBE encryption algorithm given the recipient's encoded identitifier, the system public parameters, CEK, the optional sender's encoded identifier and the corresponding private key and the optional encryption policy. Note that enforcing the decryption time after which that the recipient can decrypt the encryptedKey is also an encryption policy. Which encryption policies should be applied depends on the application requirements. How to apply the policies varies with IBE algorithms and applications. 4. Set the fields of KeyAgreeRecipientInfo as defined in Section 4.1. How to represent the encryption policies in ECIdentitySchema should be specified in separate documents. 4.3. CEK Decryption Process To decrypt a CEK, the recipient performs the following steps in general. 1. Decode originator as an OCTET STRING as required in CMS [RFC3852]. The result value MAY be NULL. 2. If the used algorithm is an IBE algorithm then Cheng & Dan Expires September 11, 2008 [Page 9] Internet-Draft Using IBC with CMS April 2008 a. If the output value of Step 1 is not NULL, then further decode the output as an IBCIdentityInfo. b. Decode the output value of decoding RecipientKeyIdentifier's subjectKeyIdentifier as an IBCIdentityInfo. 3. Obtain a set of system public parameters uniquely identified by the domain name and serial number in the recipient's IBCIdentityInfo. The recipient MAY obtain the system public parameters by any means. The IBCIdentityInfo MAY provide information to help the recipient to retrieve such information. If sender's IBCIdentityInfo is present, then it MUST refer to the same set of parameters as in the recipient's IBCIdentityInfo and the sender's encoded identifier should be reconstructed. 4. Obtain the private key corresponding to the recipient's encoded identifier which is specified by the chosen identitySchema and other optional keys that are required to apply encryption policies. The recipient MAY obtain these keys by any means. The serverInfo and keyFetchMethod fields if present SHOULD provide the information necessary to locate private keys. But to retrieve these keys MUST rely on other credentials that are owned by the recipient. 5. Apply other policies that do not require corresponding keys. How to enforce those polices varies with the system and applications. 6. Decrypt the encryptedKey to recover the CEK with the IBE decryption algorithm given the private keys, system public parameters, recipient encoded identifier, the optional encoded sender identifier and the optional policies. 4.4. Authenticated-Enveloped-Data Content Type for IBE [RFC5083] defines a new AuthEnvelopedData content type. One MAY choose to use this content type for an IBE. o originatorInfo and recipientInfos in the AuthEnvelopedData content type have the same meaning as in the EnvelopedData content type defined in Section 4.1. o Other fields have the same meaning as defined in [RFC5083]. The process of field version, originatorInfo and recipientInfos follows the same procedure as defined in Section 4.2 and 4.3 for EnvelopedData respectively. Cheng & Dan Expires September 11, 2008 [Page 10] Internet-Draft Using IBC with CMS April 2008 The process of field authEncryptedContentInfo, authAttrs, mac and unauthAttrs follows the same procedure as defined in [RFC5083]. 5. ASN.1 Module IBCIdentityInfo ::= SEQUENCE { version INTEGER { v1(1) }, domain OCTET STRING, serial INTEGER, identitySchema OBJECT IDENTIFIER, identityData ANY DEFINED BY identitySchema, serverInfo ServerAttributes OPTIONAL, keyFetchMethod OBJECT IDENTIFIER OPTIONAL } ServerAttributes ::= SET SIZE {1..MAX} OF Attribute Attribute ::= SEQUENCE { attrType OBJECT IDENTIFIER, attrValues SET OF AttributeValue } AttributeValue ::= ANY cmsECSchemaOID OBJECT IDENTIFIER ::= TBD ECIdentitySchema ::= SEQUENCE { idTag OCTET STRING, basicID OCTET STRING, decTime GeneralizedTime OPTIONAL, policyInfo PolicyAttributes OPTIONAL Cheng & Dan Expires September 11, 2008 [Page 11] Internet-Draft Using IBC with CMS April 2008 } PolicyAttributes ::= SET SIZE {1..MAX} OF Attribute 6. Security Considerations This document describes the use of cryptographic message syntax for the SignedData, EnvelopedData and AuthEnvelopedData content type with IBC algorithms. Hence the relevant security considerations in CMS [RFC3852, RFC5083] also apply. Generally the following rules MUST be observed: o The chosen IBC algorithm MUST be secure and the appropriate security level MUST be chosen. The security of a specific IBC algorithm is beyond the scope of this document. o The IBC system public parameters MUST be authentic and any parameter retrieving process MUST be secure against modification and impersonation. In particular, the verifier of an identity- based signature MUST be assured that it has obtained authentic system public parameters identified by the domain name and the serial number. Otherwise, an adversary can deceive the verifier into accepting a forged signature in the following way: 1. Generate a master secret and the corresponding set of system public parameters. 2. Generate the private key corresponding to the signer's encoded identifier by using the identity-based key extraction algorithm and the master secret from Step 1. 3. Generate the signature in SignerInfo using the IBS algorithm and the private key from Step 2. 4. Deceive the verifier into accepting the system public parameter from Step 1 and then the verification process will conclude that the signature from Step 3 is therefore authentic. Similarly, in the enveloping data process the sender MUST obtain authentic system public parameters used by the intended recipient. Otherwise, an adversary can decrypt a message in the following way: 1. Generate a master secret and the corresponding set of system public parameters. Cheng & Dan Expires September 11, 2008 [Page 12] Internet-Draft Using IBC with CMS April 2008 2. Deceive the sender into accepting the system public parameter from Step 1 and then the sender will encrypt the content- encryption key with false parameters. 3. Generate the private key corresponding to the recipient's encoded identifier by using the identity-based key extraction algorithm and the master secret from Step 1. 4. Decrypt encryptedKey with the IBE algorithm and the private key from Step 3, in order to decrypt encryptedContentInfo. o The master secret owned by the KGC MUST be well protected. If the master key is compromised, the adversary can generate the private key corresponding to a signer or recipient's encoded identifier, and hence forge signatures or decrypt messages. How to protect the master key is beyond the scope of this document. o Any private key retrieving process MUST be protected from information leakage or impersonation or modification. The IBE architecture [AMS] supports online private key retrieving. Such process MUST be protected; otherwise, the leak of IBE private key will compromise the security of encryptedContentInfo. In general the private key verification process, which verifies the authenticity of a given private key corresponding to a claimed identifier, SHOULD be carried out by the key recipient. o The signer's private key MUST be protected from leakage in any implementation. o The recipient's private key MUST be protected from leakage in any implementation. o The content-encryption key MUST be protected from leakage and MUST be generated randomly in any implementation. 7. IANA Considerations IANA is requested to allocate OID for cmsECSchemaOID to replace "TBD" in sections 2.1 and 5. 8. Acknowledgments The author would like to thank Richard Read, Manos Nistazakis and Alfred Hoenes for their comments. This document was prepared using 2-Word-v2.0.template.dot. Cheng & Dan Expires September 11, 2008 [Page 13] Internet-Draft Using IBC with CMS April 2008 9. References 9.1. Normative References [AMS] G. Appenzeller, L. Martin, M. Schertler, "Identity-based Encryption Architecture", draft-ietf-ibearch-06.txt. [X.208-88]CCITT, "X.208: Specification of Abstract Syntax Notation One (ASN.1)", 1998. [X.690] International Telecommunication Union Telecommunication Standardization Sector, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER)", X.690, 2002. [RFC5083] R. Housley, "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007. [MS] L. Martin and M. Schertler, "Using the Boneh-Franklin and Boneh-Boyen identity-based encryption algorithms with the Cryptographic Message Syntax (CMS)", draft-ietf-smime- bfibecms-08.txt. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3852] R. Housley, "Cryptographic Message Syntax", RFC 3852, July 2004. Author's Addresses Zhaohui Cheng Middlesex University The Burroughs Hendon, London NW4 4BT, UK Phone: +44 20 84114932 Email: m.z.cheng@mdx.ac.uk Bo Dan Olymtech. Tower A, International Tech-Innovation Institute, The Tenth Keji Nan Road, Shenzhen, P.R.C., 518057 Phone: +86 755 26727161 Email: dennydan@olymtech.net Cheng & Dan Expires September 11, 2008 [Page 14] Internet-Draft Using IBC with CMS April 2008 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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. Cheng & Dan Expires September 11, 2008 [Page 15]