From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5990.txt | 1515 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1515 insertions(+) create mode 100644 doc/rfc/rfc5990.txt (limited to 'doc/rfc/rfc5990.txt') diff --git a/doc/rfc/rfc5990.txt b/doc/rfc/rfc5990.txt new file mode 100644 index 0000000..98afafe --- /dev/null +++ b/doc/rfc/rfc5990.txt @@ -0,0 +1,1515 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Randall +Request for Comments: 5990 Randall Consulting +Category: Standards Track B. Kaliski +ISSN: 2070-1721 EMC + J. Brainard + RSA + S. Turner + IECA + September 2010 + + + Use of the RSA-KEM Key Transport Algorithm + in the Cryptographic Message Syntax (CMS) + +Abstract + + The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) + mechanism for transporting keying data to a recipient using the + recipient's RSA public key. ("KEM" stands for "key encapsulation + mechanism".) This document specifies the conventions for using the + RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax + (CMS). The ASN.1 syntax is aligned with an expected forthcoming + change to American National Standard (ANS) X9.44. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5990. + + + + + + + + + + + + + + +Randall, et al. Standards Track [Page 1] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Conventions Used in This Document ..........................4 + 2. Use in CMS ......................................................4 + 2.1. Underlying Components ......................................4 + 2.2. RecipientInfo Conventions ..................................5 + 2.3. Certificate Conventions ....................................5 + 2.4. SMIMECapabilities Attribute Conventions ....................6 + 3. Security Considerations .........................................7 + 4. IANA Considerations .............................................9 + 5. Acknowledgements ................................................9 + 6. References .....................................................10 + 6.1. Normative References ......................................10 + 6.2. Informative References ....................................11 + Appendix A. RSA-KEM Key Transport Algorithm ......................12 + A.1. Underlying Components ....................................12 + A.2. Sender's Operations ......................................12 + A.3. Recipient's Operations ...................................13 + Appendix B. ASN.1 Syntax .........................................15 + B.1. RSA-KEM Key Transport Algorithm ..........................16 + B.2. Selected Underlying Components ...........................18 + B.2.1. Key Derivation Functions ............................18 + B.2.2. Symmetric Key-Wrapping Schemes ......................19 + B.3. ASN.1 Module .............................................20 + B.4. Examples .................................................25 + + + + + + + + + + +Randall, et al. Standards Track [Page 2] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + +1. Introduction + + The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) + mechanism for transporting keying data to a recipient using the + recipient's RSA public key. + + Most previous key transport algorithms based on the RSA public-key + cryptosystem (e.g., the popular PKCS #1 v1.5 algorithm [PKCS1]) have + the following general form: + + 1. Format or "pad" the keying data to obtain an integer m. + + 2. Encrypt the integer m with the recipient's RSA public key: + + c = m^e mod n + + 3. Output c as the encrypted keying data. + + The RSA-KEM Key Transport Algorithm takes a different approach that + provides higher security assurance, by encrypting a _random_ integer + with the recipient's public key, and using a symmetric key-wrapping + scheme to encrypt the keying data. It has the following form: + + 1. Generate a random integer z between 0 and n-1. + + 2. Encrypt the integer z with the recipient's RSA public key: + + c = z^e mod n + + 3. Derive a key-encrypting key KEK from the integer z. + + 4. Wrap the keying data using KEK to obtain wrapped keying data WK. + + 5. Output c and WK as the encrypted keying data. + + This different approach provides higher security assurance because + (a) the input to the underlying RSA operation is effectively a random + integer between 0 and n-1, where n is the RSA modulus, so it does not + have any structure that could be exploited by an adversary, and + (b) the input is independent of the keying data so the result of the + RSA decryption operation is not directly available to an adversary. + As a result, the algorithm enjoys a "tight" security proof in the + random oracle model. (In other padding schemes, such as PKCS #1 + v1.5, the input has structure and/or depends on the keying data, and + the provable security assurances are not as strong.) The approach is + also architecturally convenient because the public-key operations are + + + + + +Randall, et al. Standards Track [Page 3] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + + separate from the symmetric operations on the keying data. Another + benefit is that the length of the keying data is bounded only by the + symmetric key-wrapping scheme, not the size of the RSA modulus. + + The RSA-KEM Key Transport Algorithm in various forms is being adopted + in several draft standards as well as in American National Standard + (ANS) X9.44 [ANS-X9.44]. It has also been recommended by the New + European Schemes for Signatures, Integrity, and Encryption (NESSIE) + project [NESSIE]. Originally, [ANS-X9.44] specified a different + object identifier to identify the RSA-KEM Key Transport Algorithm. + [ANS-X9.44] used id-ac-generic-hybrid, while this document uses + id-rsa-kem. These OIDs are used in the KeyTransportInfo field to + indicate the key encryption algorithm, in certificates to allow + recipients to restrict their public keys for use with RSA-KEM only, + and in SMIME Capability attributes to allow recipients to advertise + their support for RSA-KEM. Legacy implementations that wish to + interoperate with [ANS-X9.44] should consult that specification for + more information on id-ac-generic-hybrid. + + For completeness, a specification of the algorithm is given in + Appendix A of this document; ASN.1 syntax is given in Appendix B. + + NOTE: The term "KEM" stands for "key encapsulation mechanism" and + refers to the first three steps of the process above. The + formalization of key transport algorithms (or more generally, + asymmetric encryption schemes) in terms of key encapsulation + mechanisms is described further in research by Victor Shoup + leading to the development of the ISO/IEC 18033-2 standard + [SHOUP]. + +1.1. Conventions Used in This Document + + 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 [STDWORDS]. + +2. Use in CMS + + The RSA-KEM Key Transport Algorithm MAY be employed for one or more + recipients in the CMS enveloped-data content type (Section 6 of + [CMS]), where the keying data processed by the algorithm is the CMS + content-encryption key. + +2.1. Underlying Components + + A CMS implementation that supports the RSA-KEM Key Transport + Algorithm MUST support at least the following underlying components: + + + + +Randall, et al. Standards Track [Page 4] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + + o For the key derivation function, KDF3 (see [ANS-X9.44]) based on + SHA-256 (see [FIPS-180-3]). KDF3 is an instantiation of the + Concatenation Key Derivation Function defined in [NIST-SP800-56A]. + + o For the key-wrapping scheme, AES-Wrap-128, i.e., the AES Key Wrap + with a 128-bit key-encrypting key (see [AES-WRAP]). + + An implementation SHOULD also support KDF2 (see [ANS-X9.44]) based on + SHA-1 (this function is also specified as the key derivation function + in [ANS-X9.63]). The Camellia key wrap algorithm (see [CAMELLIA]) + SHOULD be supported if Camellia is supported as a content-encryption + cipher. The Triple-DES Key Wrap (see [3DES-WRAP]) SHOULD also be + supported if Triple-DES is supported as a content-encryption cipher. + + It MAY support other underlying components. When AES or Camellia is + used, the data block size is 128 bits and the key size can be 128, + 192, or 256 bits, while Triple-DES requires a data block size of + 64 bits and a key size of 112 or 168 bits. + +2.2. RecipientInfo Conventions + + When the RSA-KEM Key Transport Algorithm is employed for a recipient, + the RecipientInfo alternative for that recipient MUST be + KeyTransRecipientInfo. The algorithm-specific fields of the + KeyTransRecipientInfo value MUST have the following values: + + o keyEncryptionAlgorithm.algorithm MUST be id-rsa-kem (see + Appendix B); + + o keyEncryptionAlgorithm.parameters MUST be a value of type + GenericHybridParameters, identifying the RSA-KEM key encapsulation + mechanism (see Appendix B); + + o encryptedKey MUST be the encrypted keying data output by the + algorithm, where the keying data is the content-encryption key + (see Appendix A). + +2.3. Certificate Conventions + + The conventions specified in this section augment RFC 5280 [PROFILE]. + + A recipient who employs the RSA-KEM Key Transport Algorithm MAY + identify the public key in a certificate by the same + AlgorithmIdentifier as for the PKCS #1 v1.5 algorithm, i.e., using + the rsaEncryption object identifier [PKCS1]. The fact that the user + will accept RSA-KEM with this public key is not indicated by the use + + + + + +Randall, et al. Standards Track [Page 5] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + + of this identifier. This MAY be signaled by the use of the + appropriate SMIME Capabilities either in a message or in the + certificate. + + If the recipient wishes only to employ the RSA-KEM Key Transport + Algorithm with a given public key, the recipient MUST identify the + public key in the certificate using the id-rsa-kem object identifier + (see Appendix B). When the id-rsa-kem algorithm identifier appears + in the SubjectPublicKeyInfo algorithm field, the encoding SHALL omit + the parameters field from AlgorithmIdentifier. That is, the + AlgorithmIdentifier SHALL be a SEQUENCE of one component, the object + identifier id-rsa-kem. + + Regardless of the AlgorithmIdentifier used, the RSA public key is + encoded in the same manner in the subject public key information. + The RSA public key MUST be encoded using the type RSAPublicKey type: + + RSAPublicKey ::= SEQUENCE { + modulus INTEGER, -- n + publicExponent INTEGER -- e + } + + Here, the modulus is the modulus n, and publicExponent is the public + exponent e. The Distinguished Encoding Rules (DER)-encoded + RSAPublicKey is carried in the subjectPublicKey BIT STRING within the + subject public key information. + + The intended application for the key MAY be indicated in the key + usage certificate extension (see [PROFILE], Section 4.2.1.3). If the + keyUsage extension is present in a certificate that conveys an RSA + public key with the id-rsa-kem object identifier as discussed above, + then the key usage extension MUST contain the following value: + + keyEncipherment + + dataEncipherment SHOULD NOT be present. That is, a key intended to + be employed only with the RSA-KEM Key Transport Algorithm SHOULD NOT + also be employed for data encryption or for authentication such as in + signatures. Good cryptographic practice employs a given RSA key pair + in only one scheme. This practice avoids the risk that vulnerability + in one scheme may compromise the security of the other, and may be + essential to maintain provable security. + +2.4. SMIMECapabilities Attribute Conventions + + RFC 3851 [MSG], Section 2.5.2 defines the SMIMECapabilities signed + attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be + used to specify a partial list of algorithms that the software + + + +Randall, et al. Standards Track [Page 6] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + + announcing the SMIMECapabilities can support. When constructing a + signedData object, compliant software MAY include the + SMIMECapabilities signed attribute announcing that it supports the + RSA-KEM Key Transport Algorithm. + + The SMIMECapability SEQUENCE representing the RSA-KEM Key Transport + Algorithm MUST include the id-rsa-kem object identifier (see + Appendix B) in the capabilityID field and MUST include a + GenericHybridParameters value in the parameters field identifying the + components with which the algorithm is to be employed. + + The DER encoding of a SMIMECapability SEQUENCE is the same as the DER + encoding of an AlgorithmIdentifier. Example DER encodings for + typical sets of components are given in Appendix B.4. + +3. Security Considerations + + The RSA-KEM Key Transport Algorithm should be considered for new CMS- + based applications as a replacement for the widely implemented RSA + encryption algorithm specified originally in PKCS #1 v1.5 (see + [PKCS1] and Section 4.2.1 of [CMSALGS]), which is vulnerable to + chosen-ciphertext attacks. The RSA Encryption Scheme - Optimal + Asymmetric Encryption Padding (RSAES-OAEP) Key Transport Algorithm + has also been proposed as a replacement (see [PKCS1] and [CMS-OAEP]). + RSA-KEM has the advantage over RSAES-OAEP of a tighter security + proof, but the disadvantage of slightly longer encrypted keying data. + + The security of the RSA-KEM Key Transport Algorithm described in this + document can be shown to be tightly related to the difficulty of + either solving the RSA problem or breaking the underlying symmetric + key-wrapping scheme, if the underlying key derivation function is + modeled as a random oracle, and assuming that the symmetric key- + wrapping scheme satisfies the properties of a data encapsulation + mechanism [SHOUP]. While in practice a random-oracle result does not + provide an actual security proof for any particular key derivation + function, the result does provide assurance that the general + construction is reasonable; a key derivation function would need to + be particularly weak to lead to an attack that is not possible in the + random oracle model. + + The RSA key size and the underlying components should be selected + consistent with the desired symmetric security level for an + application. Several security levels have been identified in the + NIST FIPS PUB 800-57 [NIST-GUIDELINE]. For brevity, the first three + levels are mentioned here: + + + + + + +Randall, et al. Standards Track [Page 7] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + + o 80-bit security. The RSA key size SHOULD be at least 1024 bits, + the hash function underlying the KDF SHOULD be SHA-1 or above, and + the symmetric key-wrapping scheme SHOULD be AES Key Wrap, Triple- + DES Key Wrap, or Camellia Key Wrap. + + o 112-bit security. The RSA key size SHOULD be at least 2048 bits, + the hash function underlying the KDF SHOULD be SHA-224 or above, + and the symmetric key-wrapping scheme SHOULD be AES Key Wrap, + Triple-DES Key Wrap, or Camellia Key Wrap. + + o 128-bit security. The RSA key size SHOULD be at least 3072 bits, + the hash function underlying the KDF SHOULD be SHA-256 or above, + and the symmetric key-wrapping scheme SHOULD be AES Key Wrap or + Camellia Key Wrap. + + Note that the AES Key Wrap or Camellia Key Wrap MAY be used at all + three of these levels; the use of AES or Camellia does not require a + 128-bit security level for other components. + + Implementations MUST protect the RSA private key and the content- + encryption key. Compromise of the RSA private key may result in the + disclosure of all messages protected with that key. Compromise of + the content-encryption key may result in disclosure of the associated + encrypted content. + + Additional considerations related to key management may be found in + [NIST-GUIDELINE]. + + The security of the algorithm also depends on the strength of the + random number generator, which SHOULD have a comparable security + level. For further discussion on random number generation, please + see [RANDOM]. + + Implementations SHOULD NOT reveal information about intermediate + values or calculations, whether by timing or other "side channels", + or otherwise an opponent may be able to determine information about + the keying data and/or the recipient's private key. Although not all + intermediate information may be useful to an opponent, it is + preferable to conceal as much information as is practical, unless + analysis specifically indicates that the information would not be + useful. + + Generally, good cryptographic practice employs a given RSA key pair + in only one scheme. This practice avoids the risk that vulnerability + in one scheme may compromise the security of the other, and may be + essential to maintain provable security. While RSA public keys have + often been employed for multiple purposes such as key transport and + digital signature without any known bad interactions, for increased + + + +Randall, et al. Standards Track [Page 8] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + + security assurance, such combined use of an RSA key pair is NOT + RECOMMENDED in the future (unless the different schemes are + specifically designed to be used together). + + Accordingly, an RSA key pair used for the RSA-KEM Key Transport + Algorithm SHOULD NOT also be used for digital signatures. (Indeed, + the Accredited Standards Committee X9 (ASC X9) requires such a + separation between key establishment key pairs and digital signature + key pairs.) Continuing this principle of key separation, a key pair + used for the RSA-KEM Key Transport Algorithm SHOULD NOT be used with + other key establishment schemes, or for data encryption, or with more + than one set of underlying algorithm components. + + Parties MAY formalize the assurance that one another's + implementations are correct through implementation validation, e.g., + NIST's Cryptographic Module Validation Program (CMVP). + +4. IANA Considerations + + Within the CMS, algorithms are identified by object identifiers + (OIDs). With one exception, all of the OIDs used in this document + were assigned in other IETF documents, in ISO/IEC standards + documents, by the National Institute of Standards and Technology + (NIST), and in Public-Key Cryptography Standards (PKCS) documents. + The two exceptions are the ASN.1 module's identifier (see Appendix + B.3) and id-rsa-kem that are both assigned in this document. The + module object identifiers are defined in an arc delegated by the + former company RSA Data Security Inc. to the S/MIME Working Group. + When the S/MIME Working Group closes, this arc and its registration + procedures will be transferred to IANA. + +5. Acknowledgements + + This document is one part of a strategy to align algorithm standards + produced by ASC X9, ISO/IEC JTC1 SC27, NIST, and the IETF. We would + like to thank the members of the ASC X9F1 working group for their + contributions to drafts of ANS X9.44, which led to this + specification. + + Our thanks to Russ Housley as well for his guidance and + encouragement. We also appreciate the helpful direction we've + received from Blake Ramsdell and Jim Schaad in bringing this document + to fruition. A special thanks to Magnus Nystrom for his assistance + on Appendix B. Thanks also to Bob Griffin and John Linn for both + editorial direction and procedural guidance. + + + + + + +Randall, et al. Standards Track [Page 9] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + +6. References + +6.1. Normative References + + [3DES-WRAP] Housley, R., "Triple-DES and RC2 Key Wrapping", + RFC 3217, December 2001. + + [AES-WRAP] Schaad, J. and R. Housley, "Advanced Encryption + Standard (AES) Key Wrap Algorithm", RFC 3394, + September 2002. + + [ANS-X9.44] ASC X9F1 Working Group. American National Standard + X9.44: Public Key Cryptography for the Financial + Services Industry -- Key Establishment Using + Integer Factorization Cryptography. 2007. + + [ANS-X9.63] American National Standard X9.63-2002: Public Key + Cryptography for the Financial Services Industry: + Key Agreement and Key Transport Using Elliptic + Curve Cryptography. + + [CAMELLIA] Moriai, S. and A. Kato, "Use of the Camellia + Encryption Algorithm in Cryptographic Message + Syntax (CMS)", RFC 3657, January 2004. + + [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", + RFC 5652, September 2009. + + [CMSALGS] Housley, R., "Cryptographic Message Syntax (CMS) + Algorithms", RFC 3370, August 2002. + + [FIPS-180-3] National Institute of Standards and Technology + (NIST). FIPS 180-3: Secure Hash Standard. October + 2008. + + [MSG] Ramsdell, B. and S. Turner, "Secure/Multipurpose + Internet Mail Extensions (S/MIME) Version 3.2 + Message Specification", RFC 5751, January 2010. + + [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public + Key Infrastructure Certificate and Certificate + Revocation List (CRL) Profile", RFC 5280, May 2008. + + [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + + + +Randall, et al. Standards Track [Page 10] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + +6.2. Informative References + + [AES-WRAP-PAD] Housley, R. and M. Dworkin, "Advanced Encryption + Standard (AES) Key Wrap with Padding Algorithm", + RFC 5649, September 2009. + + [CMS-OAEP] Housley, R., "Use of the RSAES-OAEP Key Transport + Algorithm in Cryptographic Message Syntax (CMS)", + RFC 3560, July 2003. + + [NESSIE] NESSIE Consortium. Portfolio of Recommended + Cryptographic Primitives. February 2003. + http://www.cryptonessie.org/. + + [NIST-GUIDELINE] National Institute of Standards and Technology. + Special Publication 800-57: Recommendation for Key + Management - Part 1: General (Revised). March + 2007. + http://csrc.nist.gov/publications/index.html. + + [NIST-SP800-56A] National Institute of Standards and Technology. + Special Publication 800-56A: Recommendation for + Pair-Wise Key Establishment Schemes Using Discrete + Logarithm Cryptography (Revised). March 2007. + http://csrc.nist.gov/publications/index.html. + + [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key + Cryptography Standards (PKCS) #1: RSA Cryptography + Specifications Version 2.1", RFC 3447, February + 2003. + + [RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, + RFC 4086, June 2005. + + [SHOUP] Shoup, V. A Proposal for an ISO Standard for + Public Key Encryption. Version 2.1, December 20, + 2001. http://eprint.iacr.org/2001/112. + + + + + + + + + + + + + +Randall, et al. Standards Track [Page 11] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + +Appendix A. RSA-KEM Key Transport Algorithm + + The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) + mechanism for transporting keying data to a recipient using the + recipient's RSA public key. + + With this type of algorithm, a sender encrypts the keying data using + the recipient's public key to obtain encrypted keying data. The + recipient decrypts the encrypted keying data using the recipient's + private key to recover the keying data. + +A.1. Underlying Components + + The algorithm has the following underlying components: + + o KDF, a key derivation function, which derives keying data of a + specified length from a shared secret value; + + o Wrap, a symmetric key-wrapping scheme, which encrypts keying Data + using a key-encrypting key. + + In the following, kekLen denotes the length in bytes of the key- + encrypting key for the underlying symmetric key-wrapping scheme. + + In this scheme, the length of the keying data to be transported MUST + be among the lengths supported by the underlying symmetric key- + wrapping scheme. (Both the AES and Camellia Key Wraps, for instance, + require the length of the keying data to be a multiple of 8 bytes, + and at least 16 bytes.) Usage and formatting of the keying data + (e.g., parity adjustment for Triple-DES keys) is outside the scope of + this algorithm. With some key derivation functions, it is possible + to include other information besides the shared secret value in the + input to the function. Also, with some symmetric key-wrapping + schemes, it is possible to associate a label with the keying data. + Such uses are outside the scope of this document, as they are not + directly supported by CMS. + +A.2. Sender's Operations + + Let (n,e) be the recipient's RSA public key (see [PKCS1] for + details), and let K be the keying data to be transported. + + Let nLen denote the length in bytes of the modulus n, i.e., the least + integer such that 2^{8*nLen} > n. + + + + + + + +Randall, et al. Standards Track [Page 12] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + + The sender performs the following operations: + + 1. Generate a random integer z between 0 and n-1 (see note), and + convert z to a byte string Z of length nLen, most significant byte + first: + + z = RandomInteger (0, n-1) + + Z = IntegerToString (z, nLen) + + 2. Encrypt the random integer z using the recipient's public key + (n,e), and convert the resulting integer c to a ciphertext C, a + byte string of length nLen: + + c = z^e mod n + + C = IntegerToString (c, nLen) + + 3. Derive a key-encrypting key KEK of length kekLen bytes from the + byte string Z using the underlying key derivation function: + + KEK = KDF (Z, kekLen) + + 4. Wrap the keying data K with the key-encrypting key KEK using the + underlying key-wrapping scheme to obtain wrapped keying data WK: + + WK = Wrap (KEK, K) + + 5. Concatenate the ciphertext C and the wrapped keying data WK to + obtain the encrypted keying data EK: + + EK = C || WK + + 6. Output the encrypted keying data EK. + + NOTE: The random integer z MUST be generated independently at random + for different encryption operations, whether for the same or + different recipients. + +A.3. Recipient's Operations + + Let (n,d) be the recipient's RSA private key (see [PKCS1]; other + private key formats are allowed), and let EK be the encrypted keying + data. + + Let nLen denote the length in bytes of the modulus n. + + + + + +Randall, et al. Standards Track [Page 13] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + + The recipient performs the following operations: + + 1. Separate the encrypted keying data EK into a ciphertext C of + length nLen bytes and wrapped keying data WK: + + C || WK = EK + + If the length of the encrypted keying data is less than nLen + bytes, output "decryption error", and stop. + + 2. Convert the ciphertext C to an integer c, most significant byte + first. Decrypt the integer c using the recipient's private key + (n,d) to recover an integer z (see note): + + c = StringToInteger (C) + + z = c^d mod n + + If the integer c is not between 0 and n-1, output "decryption + error", and stop. + + 3. Convert the integer z to a byte string Z of length nLen, most + significant byte first (see note): + + Z = IntegerToString (z, nLen) + + 4. Derive a key-encrypting key KEK of length kekLen bytes from the + byte string Z using the underlying key derivation function (see + note): + + KEK = KDF (Z, kekLen) + + 5. Unwrap the wrapped keying data WK with the key-encrypting key KEK + using the underlying key-wrapping scheme to recover the keying + data K: + + K = Unwrap (KEK, WK) + + If the unwrapping operation outputs an error, output "decryption + error", and stop. + + 6. Output the keying data K. + + NOTE: Implementations SHOULD NOT reveal information about the + integer z and the string Z, nor about the calculation of the + exponentiation in Step 2, the conversion in Step 3, or the key + derivation in Step 4, whether by timing or other "side channels". + The observable behavior of the implementation SHOULD be the same at + + + +Randall, et al. Standards Track [Page 14] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + + these steps for all ciphertexts C that are in range. (For example, + IntegerToString conversion should take the same amount of time + regardless of the actual value of the integer z.) The integer z, the + string Z, and other intermediate results MUST be securely deleted + when they are no longer needed. + +Appendix B. ASN.1 Syntax + + The ASN.1 syntax for identifying the RSA-KEM Key Transport Algorithm + is an extension of the syntax for the "generic hybrid cipher" in + ANS X9.44 [ANS-X9.44]. The syntax for the scheme is given in + Appendix B.1. The syntax for selected underlying components + including those mentioned above is given in Appendix B.2. + + The following object identifier prefixes are used in the definitions + below: + + is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) } + + nistAlgorithm OID ::= { + joint-iso-itu-t(2) country(16) us(840) organization(1) + gov(101) csor(3) nistAlgorithm(4) + } + + pkcs-1 OID ::= { + iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) + } + + x9-44 OID ::= { iso(1) identified-organization(3) tc68(133) + country(16) x9(840) x9Standards(9) x9-44(44) } + + x9-44-components OID ::= { x9-44 components(1) } + + NullParms is a more descriptive synonym for NULL when an algorithm + identifier has null parameters: + + NullParms ::= NULL + + The material in this Appendix is based on ANS X9.44. + + + + + + + + + + + + +Randall, et al. Standards Track [Page 15] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + +B.1. RSA-KEM Key Transport Algorithm + + The object identifier for the RSA-KEM Key Transport Algorithm is + id-rsa-kem, which is defined in this document as: + + id-rsa-kem OID ::= { + iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) + pkcs-9(9) smime(16) alg(3) 14 + } + + When id-rsa-kem is used in an AlgorithmIdentifier, the parameters + MUST employ the GenericHybridParameters syntax. The parameters MUST + be absent when used in the SubjectPublicKeyInfo field. The syntax + for GenericHybridParameters is as follows: + + GenericHybridParameters ::= { + kem KeyEncapsulationMechanism, + dem DataEncapsulationMechanism + } + + The fields of type GenericHybridParameters have the following + meanings: + + o kem identifies the underlying key encapsulation mechanism, + which in this case is also denoted as RSA-KEM. + + The object identifier for RSA-KEM (as a key encapsulation + mechanism) is id-kem-rsa as: + + id-kem-rsa OID ::= { + is18033-2 key-encapsulation-mechanism(2) rsa(4) + } + + The associated parameters for id-kem-rsa have type + RsaKemParameters: + + RsaKemParameters ::= { + keyDerivationFunction KeyDerivationFunction, + keyLength KeyLength + } + + + + + + + + + + + +Randall, et al. Standards Track [Page 16] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + + The fields of type RsaKemParameters have the following + meanings: + + * keyDerivationFunction identifies the underlying key + derivation function. For alignment with ANS X9.44, it MUST + be KDF2 or KDF3. However, other key derivation functions + MAY be used with CMS. Please see Appendix B.2.1 for the + syntax for KDF2 and KDF3. + + KeyDerivationFunction ::= + AlgorithmIdentifier {{KDFAlgorithms}} + + KDFAlgorithms ALGORITHM ::= { + kdf2 | kdf3, + ... -- implementations may define other methods + } + + * keyLength is the length in bytes of the key-encrypting key, + which depends on the underlying symmetric key-wrapping + scheme. + + KeyLength ::= INTEGER (1..MAX) + + o dem identifies the underlying data encapsulation mechanism. + For alignment with ANS X9.44, it MUST be an X9-approved + symmetric key-wrapping scheme. However, other symmetric key- + wrapping schemes MAY be used with CMS. Please see Appendix + B.2.2 for the syntax for the AES, Triple-DES, and Camellia Key + Wraps. + + DataEncapsulationMechanism ::= + AlgorithmIdentifier {{DEMAlgorithms}} + + DEMAlgorithms ALGORITHM ::= { + X9-SymmetricKeyWrappingSchemes, + Camellia-KeyWrappingSchemes, + ... -- implementations may define other methods + } + + X9-SymmetricKeyWrappingSchemes ALGORITHM ::= { + aes128-Wrap | aes192-Wrap | aes256-Wrap | tdes-Wrap, + ... -- allows for future expansion + } + + Camellia-KeyWrappingSchemes ALGORITHM ::= { + Camellia128-Wrap | Camellia192-Wrap | Camellia256-Wrap + } + + + + +Randall, et al. Standards Track [Page 17] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + +B.2. Selected Underlying Components + +B.2.1. Key Derivation Functions + + The object identifier for KDF2 (see [ANS-X9.44]) is: + + id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) } + + The associated parameters identify the underlying hash function. For + alignment with ANS X9.44, the hash function MUST be an ASC + X9-approved hash function. However, other hash functions MAY be used + with CMS. + + kdf2 ALGORITHM ::= { OID id-kdf-kdf2 PARMS KDF2-HashFunction } + + KDF2-HashFunction ::= AlgorithmIdentifier {{KDF2-HashFunctions}} + + KDF2-HashFunctions ALGORITHM ::= { + X9-HashFunctions, + ... -- implementations may define other methods + } + + X9-HashFunctions ALGORITHM ::= { + sha1 | sha224 | sha256 | sha384 | sha512, + ... -- allows for future expansion + } + + The object identifier for SHA-1 is: + + id-sha1 OID ::= { + iso(1) identified-organization(3) oiw(14) secsig(3) + algorithms(2) sha1(26) + } + + The object identifiers for SHA-224, SHA-256, SHA-384, and SHA-512 are + + id-sha224 OID ::= { nistAlgorithm hashAlgs(2) sha224(4) } + id-sha256 OID ::= { nistAlgorithm hashAlgs(2) sha256(1) } + id-sha384 OID ::= { nistAlgorithm hashAlgs(2) sha384(2) } + id-sha512 OID ::= { nistAlgorithm hashAlgs(2) sha512(3) } + + There has been some confusion over whether the various SHA object + identifiers have a NULL parameter, or no associated parameters. As + also discussed in [PKCS1], implementations SHOULD generate algorithm + identifiers without parameters and MUST accept algorithm identifiers + either without parameters, or with NULL parameters. + + + + + +Randall, et al. Standards Track [Page 18] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + + sha1 ALGORITHM ::= { OID id-sha1 } -- NULLParms MUST be + sha224 ALGORITHM ::= { OID id-sha224 } -- accepted for these + sha256 ALGORITHM ::= { OID id-sha256 } -- OIDs + sha384 ALGORITHM ::= { OID id-sha384 } -- "" + sha512 ALGORITHM ::= { OID id-sha512 } -- "" + + The object identifier for KDF3 (see [ANS-X9.44]) is: + + id-kdf-kdf3 OID ::= { x9-44-components kdf3(2) } + + The associated parameters identify the underlying hash function. For + alignment with the draft ANS X9.44, the hash function MUST be an ASC + X9-approved hash function. However, other hash functions MAY be used + with CMS. + + kdf3 ALGORITHM ::= { OID id-kdf-kdf3 PARMS KDF3-HashFunction } + + KDF3-HashFunction ::= AlgorithmIdentifier { KDF3-HashFunctions } + + KDF3-HashFunctions ALGORITHM ::= { + X9-HashFunctions, + ... -- implementations may define other methods + } + +B.2.2. Symmetric Key-Wrapping Schemes + + The object identifiers for the AES Key Wrap depend on the size of the + key-encrypting key. There are three object identifiers (see + [AES-WRAP]): + + id-aes128-Wrap OID ::= { nistAlgorithm aes(1) aes128-Wrap(5) } + id-aes192-Wrap OID ::= { nistAlgorithm aes(1) aes192-Wrap(25) } + id-aes256-Wrap OID ::= { nistAlgorithm aes(1) aes256-Wrap(45) } + + These object identifiers have no associated parameters. + + aes128-Wrap ALGORITHM ::= { OID id-aes128-Wrap } + aes192-Wrap ALGORITHM ::= { OID id-aes192-Wrap } + aes256-Wrap ALGORITHM ::= { OID id-aes256-Wrap } + + The object identifier for the Triple-DES Key Wrap (see + [3DES-WRAP]) is: + + id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { + iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) + smime(16) alg(3) 6 + } + + + + +Randall, et al. Standards Track [Page 19] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + + This object identifier has a NULL parameter. + + tdes-Wrap ALGORITHM ::= + { OID id-alg-CMS3DESwrap PARMS NullParms } + + NOTE: ASC X9 has not yet incorporated AES Key Wrap with Padding + [AES-WRAP-PAD] into ANS X9.44. When ASC X9.44 adds AES Key Wrap with + Padding, this document will also be updated. + + The object identifiers for the Camellia Key Wrap depend on the size + of the key-encrypting key. There are three object identifiers: + + id-camellia128-Wrap OBJECT IDENTIFIER ::= + { iso(1) member-body(2) 392 200011 61 security(1) + algorithm(1) key-wrap-algorithm(3) + camellia128-wrap(2) } + + id-camellia192-Wrap OBJECT IDENTIFIER ::= + { iso(1) member-body(2) 392 200011 61 security(1) + algorithm(1) key-wrap-algorithm(3) + camellia192-wrap(3) } + + id-camellia256-Wrap OBJECT IDENTIFIER ::= + { iso(1) member-body(2) 392 200011 61 security(1) + algorithm(1) key-wrap-algorithm(3) + camellia256-wrap(4) } + + These object identifiers have no associated parameters. + + camellia128-Wrap ALGORITHM ::= { OID id-camellia128-Wrap } + camellia192-Wrap ALGORITHM ::= { OID id-camellia192-Wrap } + camellia256-Wrap ALGORITHM ::= { OID id-camellia256-Wrap } + +B.3. ASN.1 Module + + CMS-RSA-KEM + { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) + pkcs-9(9) smime(16) modules(0) cms-rsa-kem(21) } + + DEFINITIONS ::= + + BEGIN + + -- EXPORTS ALL + + -- IMPORTS None + + -- Useful types and definitions + + + +Randall, et al. Standards Track [Page 20] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + + OID ::= OBJECT IDENTIFIER -- alias + + -- Unless otherwise stated, if an object identifier has associated + -- parameters (i.e., the PARMS element is specified), the + -- parameters field shall be included in algorithm identifier + -- values. The parameters field shall be omitted if and only if + -- the object identifier does not have associated parameters + -- (i.e., the PARMS element is omitted), unless otherwise stated. + + ALGORITHM ::= CLASS { + &id OBJECT IDENTIFIER UNIQUE, + &Type OPTIONAL + } + WITH SYNTAX { OID &id [PARMS &Type] } + + AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE { + algorithm ALGORITHM.&id( {IOSet} ), + parameters ALGORITHM.&Type( {IOSet}{@algorithm} ) OPTIONAL + } + + NullParms ::= NULL + + -- ISO/IEC 18033-2 arc + + is18033-2 OID ::= { iso(1) standard(0) is18033(18033) part2(2) } + + -- NIST algorithm arc + + nistAlgorithm OID ::= { + joint-iso-itu-t(2) country(16) us(840) organization(1) + gov(101) csor(3) nistAlgorithm(4) + } + + -- PKCS #1 arc + + pkcs-1 OID ::= { + iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) + } + + -- RSA-KEM Key Transport Algorithm + + id-rsa-kem OID ::= { + iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) + pkcs-9(9) smime(16) alg(3) 14 + } + + + + + + +Randall, et al. Standards Track [Page 21] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + + GenericHybridParameters ::= SEQUENCE { + kem KeyEncapsulationMechanism, + dem DataEncapsulationMechanism + } + + KeyEncapsulationMechanism ::= AlgorithmIdentifier {{KEMAlgorithms}} + + KEMAlgorithms ALGORITHM ::= { kem-rsa, ... } + + kem-rsa ALGORITHM ::= { OID id-kem-rsa PARMS RsaKemParameters } + + id-kem-rsa OID ::= { + is18033-2 key-encapsulation-mechanism(2) rsa(4) + } + + RsaKemParameters ::= SEQUENCE { + keyDerivationFunction KeyDerivationFunction, + keyLength KeyLength + } + + KeyDerivationFunction ::= AlgorithmIdentifier {{KDFAlgorithms}} + + KDFAlgorithms ALGORITHM ::= { + kdf2 | kdf3, + ... -- implementations may define other methods + } + + KeyLength ::= INTEGER (1..MAX) + + DataEncapsulationMechanism ::= AlgorithmIdentifier {{DEMAlgorithms}} + + DEMAlgorithms ALGORITHM ::= { + X9-SymmetricKeyWrappingSchemes | + Camellia-KeyWrappingSchemes, + ... -- implementations may define other methods + } + + X9-SymmetricKeyWrappingSchemes ALGORITHM ::= { + aes128-Wrap | aes192-Wrap | aes256-Wrap | tdes-Wrap, + ... -- allows for future expansion + } + + X9-SymmetricKeyWrappingScheme ::= + AlgorithmIdentifier {{ X9-SymmetricKeyWrappingSchemes }} + + + + + + + +Randall, et al. Standards Track [Page 22] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + + Camellia-KeyWrappingSchemes ALGORITHM ::= { + camellia128-Wrap | camellia192-Wrap | camellia256-Wrap, + ... -- allows for future expansion + } + + Camellia-KeyWrappingScheme ::= + AlgorithmIdentifier {{ Camellia-KeyWrappingSchemes }} + + -- Key Derivation Functions + + id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) } + + -- Base arc + + x9-44 OID ::= { + iso(1) identified-organization(3) tc68(133) country(16) x9(840) + x9Standards(9) x9-44(44) + } + + x9-44-components OID ::= { x9-44 components(1) } + + kdf2 ALGORITHM ::= { OID id-kdf-kdf2 PARMS KDF2-HashFunction } + + KDF2-HashFunction ::= AlgorithmIdentifier {{ KDF2-HashFunctions }} + + KDF2-HashFunctions ALGORITHM ::= { + X9-HashFunctions, + ... -- implementations may define other methods + } + + id-kdf-kdf3 OID ::= { x9-44-components kdf3(2) } + + kdf3 ALGORITHM ::= { OID id-kdf-kdf3 PARMS KDF3-HashFunction } + + KDF3-HashFunction ::= AlgorithmIdentifier {{ KDF3-HashFunctions }} + + KDF3-HashFunctions ALGORITHM ::= { + X9-HashFunctions, + ... -- implementations may define other methods + } + + -- Hash Functions + + X9-HashFunctions ALGORITHM ::= { + sha1 | sha224 | sha256 | sha384 | sha512, + ... -- allows for future expansion + } + + + + +Randall, et al. Standards Track [Page 23] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + + id-sha1 OID ::= { + iso(1) identified-organization(3) oiw(14) secsig(3) + algorithms(2) sha1(26) + } + + id-sha224 OID ::= { nistAlgorithm hashAlgs(2) sha224(4) } + + id-sha256 OID ::= { nistAlgorithm hashAlgs(2) sha256(1) } + + id-sha384 OID ::= { nistAlgorithm hashAlgs(2) sha384(2) } + + id-sha512 OID ::= { nistAlgorithm hashAlgs(2) sha512(3) } + + sha1 ALGORITHM ::= { OID id-sha1 } -- NullParms MUST be + + sha224 ALGORITHM ::= { OID id-sha224 } -- accepted for these + + sha256 ALGORITHM ::= { OID id-sha256 } -- OIDs + + sha384 ALGORITHM ::= { OID id-sha384 } -- "" + + sha512 ALGORITHM ::= { OID id-sha512 } -- "" + + -- Symmetric Key-Wrapping Schemes + + id-aes128-Wrap OID ::= { nistAlgorithm aes(1) aes128-Wrap(5) } + + id-aes192-Wrap OID ::= { nistAlgorithm aes(1) aes192-Wrap(25) } + + id-aes256-Wrap OID ::= { nistAlgorithm aes(1) aes256-Wrap(45) } + + aes128-Wrap ALGORITHM ::= { OID id-aes128-Wrap } + + aes192-Wrap ALGORITHM ::= { OID id-aes192-Wrap } + + aes256-Wrap ALGORITHM ::= { OID id-aes256-Wrap } + + id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { + iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) + smime(16) alg(3) 6 + } + + tdes-Wrap ALGORITHM ::= { OID id-alg-CMS3DESwrap PARMS NullParms } + + id-camellia128-Wrap OBJECT IDENTIFIER ::= + { iso(1) member-body(2) 392 200011 61 security(1) + algorithm(1) key-wrap-algorithm(3) + camellia128-wrap(2) } + + + +Randall, et al. Standards Track [Page 24] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + + id-camellia192-Wrap OBJECT IDENTIFIER ::= + { iso(1) member-body(2) 392 200011 61 security(1) + algorithm(1) key-wrap-algorithm(3) + camellia192-wrap(3) } + + id-camellia256-Wrap OBJECT IDENTIFIER ::= + { iso(1) member-body(2) 392 200011 61 security(1) + algorithm(1) key-wrap-algorithm(3) + camellia256-wrap(4) } + + camellia128-Wrap ALGORITHM ::= { OID id-camellia128-Wrap } + + camellia192-Wrap ALGORITHM ::= { OID id-camellia192-Wrap } + + camellia256-Wrap ALGORITHM ::= { OID id-camellia256-Wrap } + + END + +B.4. Examples + + As an example, if the key derivation function is KDF3 based on + SHA-256 and the symmetric key-wrapping scheme is the AES Key Wrap + with a 128-bit KEK, the AlgorithmIdentifier for the RSA-KEM Key + Transport Algorithm will have the following value: + + SEQUENCE { + id-rsa-kem, -- RSA-KEM cipher + SEQUENCE { -- GenericHybridParameters + SEQUENCE { -- key encapsulation mechanism + id-kem-rsa, -- RSA-KEM + SEQUENCE { -- RsaKemParameters + SEQUENCE { -- key derivation function + id-kdf-kdf3, -- KDF3 + SEQUENCE { -- KDF3-HashFunction + id-sha256 -- SHA-256; no parameters (preferred) + }, + 16 -- KEK length in bytes + }, + SEQUENCE { -- data encapsulation mechanism + id-aes128-Wrap -- AES-128 Wrap; no parameters + } + } + } + + + + + + + + +Randall, et al. Standards Track [Page 25] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + + This AlgorithmIdentifier value has the following DER encoding: + + 30 47 + 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e -- id-rsa-kem + 30 38 + 30 29 + 06 07 28 81 8c 71 02 02 04 -- id-kem-rsa + 30 1e + 30 19 + 06 0a 2b 81 05 10 86 48 09 2c 01 02 -- id-kdf-kdf3 + 30 0b + 06 09 60 86 48 01 65 03 04 02 01 -- id-sha256 + 02 01 10 -- 16 bytes + 30 0b + 06 09 60 86 48 01 65 03 04 01 05 -- id-aes128-Wrap + + The DER encodings for other typical sets of underlying components are + as follows: + + o KDF3 based on SHA-384, AES Key Wrap with a 192-bit KEK + + 30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30 + 38 30 29 06 07 28 81 8c 71 02 02 04 30 1e 30 19 + 06 0a 2b 81 05 10 86 48 09 2c 01 02 30 0b 06 09 + 60 86 48 01 65 03 04 02 02 02 01 18 30 0b 06 09 + 60 86 48 01 65 03 04 01 19 + + o KDF3 based on SHA-512, AES Key Wrap with a 256-bit KEK + + 30 47 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30 + 38 30 29 06 07 28 81 8c 71 02 02 04 30 1e 30 19 + 06 0a 2b 81 05 10 86 48 09 2c 01 02 30 0b 06 09 + 60 86 48 01 65 03 04 02 03 02 01 20 30 0b 06 09 + 60 86 48 01 65 03 04 01 2d + + o KDF2 based on SHA-1, Triple-DES Key Wrap with a 128-bit KEK (two- + key Triple-DES) + + 30 45 06 0b 2a 86 48 86 f7 0d 01 09 10 03 0e 30 + 36 30 25 06 07 28 81 8c 71 02 02 04 30 1a 30 15 + 06 0a 2b 81 05 10 86 48 09 2c 01 01 30 07 06 05 + 2b 0e 03 02 1a 02 01 10 30 0d 06 0b 2a 86 48 86 + f7 0d 01 09 10 03 06 + + + + + + + + +Randall, et al. Standards Track [Page 26] + +RFC 5990 Use of RSA-KEM in CMS September 2010 + + +Authors' Addresses + + James Randall + Randall Consulting + 55 Sandpiper Drive + Dover, NH 03820 + USA + + EMail: jdrandall@comcast.net + + + Burt Kaliski + EMC + 176 South Street + Hopkinton, MA 01748 + USA + + EMail: burt.kaliski@emc.com + + + John Brainard + RSA, The Security Division of EMC + 174 Middlesex Turnpike + Bedford, MA 01730 + USA + + EMail: jbrainard@rsa.com + + + Sean Turner + IECA, Inc. + 3057 Nutley Street, Suite 106 + Fairfax, VA 22031 + USA + + EMail: turners@ieca.com + + + + + + + + + + + + + + + +Randall, et al. Standards Track [Page 27] + -- cgit v1.2.3