S/MIME Working Group Z. Cheng Internet Draft Middlesex U. Expires: December 11, 2007 B. Dan Olym Tech. June 11, 2007 Use of the Identity-Based Cryptographic Algorithms in CMS draft-cheng-smime-ibccms-00.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 December 11, 2007. 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...................................6 Cheng & Dan Expires December 11, 2007 [Page 1] Internet-Draft Using IBC with CMS May 2007 3. Using IBS with CMS............................................6 3.1. Signed-Data Content Type for IBS.........................6 3.2. Signature Generation Process.............................7 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..................................10 4.4. Authenticated-Enveloped-Data Content Type for IBE.......11 5. ASN.1 Module.................................................11 6. Security Considerations......................................13 7. IANA Considerations..........................................14 8. Acknowledgments..............................................14 9. References...................................................14 9.1. Normative References....................................14 Author's Addresses..............................................15 Intellectual Property Statement.................................15 Disclaimer of Validity..........................................16 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] and the emerging new standard [Hou] 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 [Hou] is used to carry the necessary IBC identity information. Such information SHOULD include the user identifier, a set of system public parameters Cheng & Dan Expires December 11, 2007 [Page 2] Internet-Draft Using IBC with CMS May 2007 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 the 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, serverInfo ServerAttributes OPTIONAL, keyFetchMethod [1] IMPLICIT OBJECT IDENTIFIER OPTIONAL, identitySchema [2] IMPLICIT OBJECT IDENTIFIER, identityData ANY DEFINED BY identitySchema } Cheng & Dan Expires December 11, 2007 [Page 3] Internet-Draft Using IBC with CMS May 2007 ServerAttributes ::= SET SIZE {1..MAX} 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 that 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 includes the user identifier or a unique identity variant and other optional information. ECIdentitySchema ::= SEQUENCE { idString ECEncodeID, Cheng & Dan Expires December 11, 2007 [Page 4] Internet-Draft Using IBC with CMS May 2007 decTime GeneralizedTime OPTIONAL, policyInfo PolicyAttributes OPTIONAL } ECEncodeID ::= CHOICE { ecSignerID ECSignerID, ecRecipientID [0] ECRecipientID } ECSignerID ::= SEQUENCE{ idTag OCTET STRING {"SIGN="}, basicID OCTET STRING } ECRecipientID ::= SEQUENCE{ idTag OCTET STRING {"RECP="}, basicID OCTET STRING } PolicyAttributes ::= SET SIZE {1..MAX} Attribute idString defines the user encoded identifier used in the IBE or IBS algorithms. basicID is the raw user identifier, which can be an arbitrary OCTET STRING such as an email address that uniquely identifies a user. decTime specifies the time after which the recipient is enabled to decrypt the message. Refer to Section 11.3. in [RFC3852] for the format of GeneralizedTime. The encoded identifier is formatted as idTag|basicID if decTime and policyInfo are not present. | represents concatenating the values of two OCTET STRING's. For example, if the basicID field carries the value of an email address "ALICE@NETWORK.COM", then the encoded signer identifier is "SIGN=ALICE@NETWORK.COM" and the encoded Cheng & Dan Expires December 11, 2007 [Page 5] Internet-Draft Using IBC with CMS May 2007 recipient identifier is "RECP=ALICE@NETWORK.COM". If decTime is present, then the encoded identifier is formatted as follows. idTag|basicID|"DECTIME="|DECTIME. Some systems MAY choose to use the same encoded identifier for both signature and encryption. 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. 2.2. Double DER-en/decoding Field subjectKeyIdentifier in the SignData, the EnvelopedData and the AuthEnvelopedData content type in CMS [RFC3852, Hou] is of the type SubjectKeyIdentifier, which is encoded as an OCTET STRING. To carry the value of IBCIdentityInfo in subjectKeyIdentifier, a double- encoding method, namely, a type of data is first BER-encoded with the defined type and then the result is further BER-encoded as an OCTET STRING, MUST be used. The encoding and decoding process of SubjectKeyIdentifier are specified as follows: Encoding the field subjectKeyIdentifier 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. Cheng & Dan Expires December 11, 2007 [Page 6] Internet-Draft Using IBC with CMS May 2007 o sid is of the 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]. 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. Prepares 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: Cheng & Dan Expires December 11, 2007 [Page 7] Internet-Draft Using IBC with CMS May 2007 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. Field serverInfo MAY provide information for the parameter retrieval. If the system public parameters can't be retrieved, the signature verification process fails. 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 the type KeyAgreeRecipientInfo. o other fields are as defined in Section 6. in CMS [RFC3852]. The meanings of fields in KeyAgreeRecipientInfo are defined as follows: o version is always set to 3. Cheng & Dan Expires December 11, 2007 [Page 8] Internet-Draft Using IBC with CMS May 2007 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. 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 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 MAY 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. Cheng & Dan Expires December 11, 2007 [Page 9] Internet-Draft Using IBC with CMS May 2007 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 that 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 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 recipieint'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. Obtains 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 own by the recipient. Cheng & Dan Expires December 11, 2007 [Page 10] Internet-Draft Using IBC with CMS May 2007 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 [Hou] 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 [Hou]. The process of field version, originatorInfo and recipientInfos follows the same procedure as defined in Section 4.2 and 4.3 for EnvelopedData respectively. The process of field authEncryptedContentInfo, authAttrs, mac and unauthAttrs follows the same procedure as defined in [Hou]. 5. ASN.1 Module IBCIdentityInfo ::= SEQUENCE { version INTEGER { v1(1) }, domain OCTET STRING, serial INTEGER, serverInfo ServerAttributes OPTIONAL, keyFetchMethod [1] IMPLICIT OBJECT IDENTIFIER OPTIONAL, identitySchema [2] IMPLICIT OBJECT IDENTIFIER, identityData ANY DEFINED BY identitySchema } ServerAttributes ::= SET SIZE {1..MAX} Attribute Cheng & Dan Expires December 11, 2007 [Page 11] Internet-Draft Using IBC with CMS May 2007 Attribute ::= SEQUENCE { attrType OBJECT IDENTIFIER, attrValues SET OF AttributeValue } AttributeValue ::= ANY cmsECSchemaOID OBJECT IDENTIFIER ::= TBD ECIdentitySchema ::= SEQUENCE { idString ECEncodeID, decTime GeneralizedTime OPTIONAL, policyInfo PolicyAttributes OPTIONAL } ECEncodeID ::= CHOICE { ecSignerID ECSignerID, ecRecipientID [0] ECRecipientID } ECSignerID ::= SEQUENCE{ idTag OCTET STRING {"SIGN="}, basicID OCTET STRING } ECRecipientID ::= SEQUENCE{ idTag OCTET STRING {"RECP="}, basicID OCTET STRING } PolicyAttributes ::= SET SIZE {1..MAX} Attribute Cheng & Dan Expires December 11, 2007 [Page 12] Internet-Draft Using IBC with CMS May 2007 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] and [Hou] 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 attack on specific IBC algorithm is beyond the scope of the 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 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. 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. Cheng & Dan Expires December 11, 2007 [Page 13] Internet-Draft Using IBC with CMS May 2007 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. Protection of 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. 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 cmsECSchemaOID should have an OBJECT IDENTIFIER assigned. 8. Acknowledgments The author would like to thank Richard Read and Manos Nistazakis for their comments. This document was prepared using 2-Word-v2.0.template.dot. 9. References 9.1. Normative References [AMS] G. Appenzeller, L. Martin, M. Schertler, "Identity-based Encryption Architecture", draft-ietf-ibearch-03.txt. Cheng & Dan Expires December 11, 2007 [Page 14] Internet-Draft Using IBC with CMS May 2007 [ASN1] CCITT, "Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)", 1998. [Hou] R. Housley, "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type",