Francois:
Thanks for catching the long stangins omission. Please make sure that I got
all of the places (see below).
Russ
Russ,
I had not noticed this one before but throughout Sections 12.3 various
things (e.g. key agreement algorithm identifiers, key transport algorithm
identifiers, key wrap algorithm identifiers, etc.) are referred as being
located or used from the "EnvelopedData RecipientInfo...", however they
could also be located or used from the "AuthenticatedData RecipientInfo..."
Francois Rousseau
AEPOS Technologies
= = = = = = = = = = =
12.3 Key Management Algorithms
CMS accommodates three general key management techniques: key agreement, key
transport, and previously distributed symmetric key-encryption keys.
12.3.1 Key Agreement Algorithms
CMS implementations must include key agreement using X9.42 Ephemeral-Static
Diffie-Hellman.
Any symmetric encryption algorithm that a CMS implementation includes as a
content-encryption algorithm must also be included as a key-encryption
algorithm. CMS implementations must include key agreement of Triple-DES
pairwise key-encryption keys and Triple-DES wrapping of Triple-DES
content-encryption keys. CMS implementations should include key agreement of
RC2 pairwise key-encryption keys and RC2 wrapping of RC2 content-encryption
keys. The key wrap algorithm for Triple-DES and RC2 is described in section
12.3.3.
A CMS implementation may support mixed key-encryption and content-encryption
algorithms. For example, a 128-bit RC2 content-encryption key may be wrapped
with 168-bit Triple-DES key-encryption key. Similarly, a 40-bit RC2
content-encryption key may be wrapped with 128-bit RC2 key-encryption key.
For key agreement of RC2 key-encryption keys, 128 bits must be generated as
input to the key expansion process used to compute the RC2 effective key [RC2].
Key agreement algorithm identifiers are located in the EnvelopedData
RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm
fields.
Key wrap algorithm identifiers are located in the KeyWrapAlgorithm parameters
within the EnvelopedData RecipientInfo KeyAgreeRecipientInfo
keyEncryptionAlgorithm and AuthenticatedData RecipientInfo
KeyAgreeRecipientInfo keyEncryptionAlgorithm fields.
Wrapped content-encryption keys are located in the EnvelopedData RecipientInfo
KeyAgreeRecipientInfo recipientEncryptedKeys encryptedKey and AuthenticatedData
RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys encryptedKey fields.
12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman
Ephemeral-Static Diffie-Hellman key agreement is defined in RFC TBD1
[DH-X9.42]. When using Ephemeral-Static Diffie-Hellman, the EnvelopedData
RecipientInfo KeyAgreeRecipientInfo and AuthenticatedData RecipientInfo
KeyAgreeRecipientInfo fields are used as follows:
version must be 3.
originator must be the originatorKey alternative. The originatorKey algorithm
fields must contain the dh-public-number object identifier with absent
parameters. The originatorKey publicKey field must contain the sender's
ephemeral public key. The dh-public-number object identifier is:
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 }
ukm may be absent. When present, the ukm is used to ensure that a different
key-encryption key is generated when the ephemeral private key might be used
more than once.
keyEncryptionAlgorithm must be the id-alg-ESDH algorithm identifier. The
algorithm identifier parameter field for id-alg-ESDH is KeyWrapAlgorihtm, and
this parameter must be present. The KeyWrapAlgorithm denotes the symmetric
encryption algorithm used to encrypt the content-encryption key with the
pairwise key-encryption key generated using the Ephemeral-Static Diffie-Hellman
key agreement algorithm. Triple-DES and RC2 key wrap algorithms are discussed
in section 12.3.3. The id-alg-ESDH algorithm
identifier and parameter syntax is:
id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }
KeyWrapAlgorithm ::= AlgorithmIdentifier
recipientEncryptedKeys contains an identifier and an encrypted key for each
recipient. The RecipientEncryptedKey KeyAgreeRecipientIdentifier must contain
either the issuerAndSerialNumber identifying the recipient's certificate or the
RecipientKeyIdentifier containing the subject key identifier from the
recipient's certificate. In both cases, the recipient's certificate contains
the recipient's static public key. RecipientEncryptedKey EncryptedKey must
contain the content-encryption key encrypted with the Ephemeral-Static
Diffie-Hellman generated pairwise key-encryption key using the algorithm
specified by the KeyWrapAlgortihm.
12.3.2 Key Transport Algorithms
CMS implementations should include key transport using RSA. RSA
implementations must include key transport of Triple-DES content-encryption
keys. RSA implementations should include key transport of RC2
content-encryption keys.
Key transport algorithm identifiers are located in the EnvelopedData
RecipientInfo KeyTransRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfo KeyTransRecipientInfo keyEncryptionAlgorithm
fields.
Key transport encrypted content-encryption keys are located in the
EnvelopedData RecipientInfo KeyTransRecipientInfo EncryptedKey and
AuthenticatedData RecipientInfo KeyTransRecipientInfo EncryptedKey fields.
12.3.2.1 RSA
The RSA key transport algorithm is the RSA encryption scheme defined in RFC
2313 [PKCS#1], block type is 02, where the message to be encrypted is the
content-encryption key. The algorithm identifier for RSA is:
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
The AlgorithmIdentifier parameters field must be present, and the parameters
field must contain NULL.
When using a Triple-DES content-encryption key, adjust the parity bits for each
DES key comprising the Triple-DES key prior to RSA encryption.
The use of RSA encryption, as defined in RFC 2313 [PKCS#1], to provide
confidentiality has a known vulnerability concerns. The vulnerability is
primarily relevant to usage in interactive applications rather than to
store-and-forward environments. Further information and proposed
countermeasures are discussed in the Security Considerations section of this
document.
Note that the same encryption scheme is also defined in RFC 2437 [NEWPKCS#1].
Within RFC 2437, this scheme is called RSAES-PKCS1-v1_5.
12.3.3 Symmetric Key-Encryption Key Algorithms
CMS implementations may include symmetric key-encryption key management. Such
CMS implementations must include Triple-DES key-encryption keys wrapping
Triple-DES content-encryption keys, and such CMS implementations should include
RC2 key-encryption keys wrapping RC2 content-encryption keys. A CMS
implementation may support mixed key-encryption and content-encryption
algorithms. For example, a 40-bit RC2 content-encryption key may be wrapped
with 168-bit Triple-DES key-encryption key or with a 128-bit RC2 key-encryption
key.
Key wrap algorithm identifiers are located in the EnvelopedData RecipientInfo
KEKRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfo
KEKRecipientInfo keyEncryptionAlgorithm fields.
Wrapped content-encryption keys are located in the EnvelopedData RecipientInfo
KEKRecipientInfo encryptedKey and AuthenticatedData RecipientInfo
KEKRecipientInfo encryptedKey fields.
The output of a key agreement algorithm is a key-encryption key, and this
key-encryption key is used to encrypt the content-encryption key. In
conjunction with key agreement algorithms, CMS implementations must include
encryption of content-encryption keys with the pairwise key-encryption key
generated using a key agreement algorithm. To support key agreement, key wrap
algorithm identifiers are located in the KeyWrapAlgorithm parameter of the
EnvelopedData RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfo KeyAgreeRecipientInfo keyEncryptionAlgorithm
fields, and wrapped content-encryption keys are located in the EnvelopedData
RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys encryptedKey and
AuthenticatedData RecipientInfo KeyAgreeRecipientInfo recipientEncryptedKeys
encryptedKey fields.
12.3.3.1 Triple-DES Key Wrap
Triple-DES key encryption has the algorithm identifier:
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }
The AlgorithmIdentifier parameter field must be NULL.
The key wrap algorithm used to encrypt a Triple-DES content-encryption key with
a Triple-DES key-encryption key is specified in section 12.6.
Out-of-band distribution of the Triple-DES key-encryption key used to encrypt
the Triple-DES content-encryption key is beyond of the scope of this document.
12.3.3.2 RC2 Key Wrap
RC2 key encryption has the algorithm identifier:
id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }
The AlgorithmIdentifier parameter field must be RC2wrapParameter:
RC2wrapParameter ::= RC2ParameterVersion
RC2ParameterVersion ::= INTEGER
The RC2 effective-key-bits (key size) greater than 32 and less than 256 is
encoded in the RC2ParameterVersion. For the effective-key-bits of 40, 64, and
128, the rc2ParameterVersion values are 160, 120, and 58 respectively. These
values are not simply the RC2 key length. Note that the value 160 must be
encoded as two octets (00 A0), because the one octet (A0) encoding represents a
negative number.
The key wrap algorithm used to encrypt a RC2 content-encryption key with a RC2
key-encryption key is specified in section 12.6.
Out-of-band distribution of the RC2 key-encryption key used to encrypt the RC2
content-encryption key is beyond of the scope of this document.