One document matched: draft-ietf-smime-aes-alg-00.txt
S/MIME Working Group J. Schaad
Internet Draft Soaring Hawk Consulting
Document: draft-ietf-smime-aes-alg-00.txt November 2000
Expires: May 31, 20001
Use of the Advanced Encryption Algorithm in CMS
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
Comments or suggestions for improvement may be made on the "ietf-
smime" mailing list, or directly to the author.
1. Abstract
This document specifies how to incorporate the Advanced Encryption
Standard (AES) candidate algorithm [AES] into the S/MIME
Cryptographic Message Syntax (CMS) as an additional algorithm for
symmetric encryption. The relevant OIDs and processing steps are
provided so that the AES algorithms may be included in the CMS
specification [CMS] for symmetric content and key encryption.
2. 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 [2].
3. Overview
S/MIME (Secure/Multipurpose Internet Mail Extensions) [SMIME3] is a
set of specifications for the secure transport of MIME objects. In
Schaad 1
Use of the AES Algorithm in CMS November 2000
the current (S/MIME v3) specifications the mandatory-to-implement
symmetric algorithm for content encryption and key encryption is
triple-DES (3DES). The algorithm is considered to be both more
secure and faster than 3DES.
AES is an iterated block cipher with a variable block length and a
variable key length. In the base algorithm, the block length and the
key length can be independently specified to 128, 192 or 256 bits.
AES has fixed the block length to be 128-bits.
4. AES Algorithm
AES is a symmetric block cipher with a block size of 128 bits and a
key size of 128, 198 or 256-bits. AES is free of intellectual
property issues. Compliant implementations MUST support key sizes of
128 and 256 bits. Compliant implementation MAY support a key size of
196 bits. Compliant implementations MUST support a block size of 128-
bits.
4.1 Content Encryption
AES is added to the set of symmetric content encryption algorithms in
CMS. The AES content-encryption algorithm in Cipher Block Chaining
(CBC) mode for the three different key sizes are identified by the
OID:
id-aes128-CBC OBJECT IDENTIFIER ::= { aes 2 }
id-aes192-CBC OBJECT IDENTIFIER ::= { aes 22 }
id-aes256-CBC OBJECT IDENTIFIER ::= { aes 42 }
The AlgorithmIdentifier parameters field MUST be present, and the
parameters field MUST contain a AES-IV associated with this OID
contains the initialization vector IV:
AES-IV ::= OCTET STRING (SIZE(16))
4.2 Key Wrap
NOTE: This section is subject to change when the key wrap algorithm
(see section 5) is selected.
AES key wrap has the algorithm identifier:
id-xxxxx-AESWrap ::= {TBD}
The algorithm identifier parameter field MUST be present, and the
parameter field MUST contain a AESCBCWrap object:
AESCBCWrap ::= NULL
The key wrap algorithm used to encrypt an AES content-encryption key
with a AES key-encryption key is specified in section 2.
Schaad 2
Use of the AES Algorithm in CMS November 2000
Out-of-band distribution of the AES key-encryption key used to
encrypt the AES content-encryption key is beyond of the scope of this
document.
The key encryption key used with the wrapping algorithm MUST be 256-
bits.
4.3 S/MIME Capability Attribute
An S/MIME client SHOULD announce the set of cryptographic functions
it supports by using the S/MIME capabilities attribute. This
attribute provides a partial list of OIDs of cryptographic functions
and MUST be signed by the client. The algorithm OIDs SHOULD be
logically separated in functional categories and MUST be ordered with
respect to their preference. If an S/MIME client is required to
support symmetric encryption with AES, the capabilities attribute
MUST contain the AES OID specified above in the category of symmetric
algorithms. The parameter associated with this OID MUST is
AESSMimeCapability.
AESSMimeCapabilty ::= SEQUENCE
KeySize INTEGER
}
The encodings for the mandatory key sizes are:
Key Size Capability
128 30 XX 06 XX YY YY YY 30 04 02 02 00 80
196 30 XX 06 XX YY YY YY 30 04 02 02 00 C0
256 30 XX 06 XX YY YY YY 30 04 02 02 01 00
When a sending agent creates an encrypted message, it has to decide
which type of encryption algorithm to use. In general the decision
process involves information obtained from the capabilities lists
included in messages received from the recipient, as well as other
information such as private agreements, user preferences, legal
restrictions, and so on. If users require AES for symmetric
encryption, the S/MIME clients on both the sending and receiving side
MUST support it, and it MUST be set in the user preferences.
5. AES Key Wrap Algorithm
NOTE: Although no key wrap algorithms have been announced by NIST, a
request has been submitted that they designate a key wrap algorithm
as part of the AES standard. In the event that this is done, this
entire section is to be replaced with the NIST designated algorithm.
Should NIST decide not to provide a key wrap algorithm, it is
expected we will develop one based on the current CMS key wrap
algorithm.
6. Key Management for AES
Schaad 3
Use of the AES Algorithm in CMS November 2000
CMS accommodates three general key management techniques: key
transport, key agreement, and previously distributed symmetric key-
encryption keys.
6.1 Key Transport for AES
Key Transport using RSA-OEAP MUST be implemented to comply with this
document.
Key transport algorithm identifiers are located in the EnvelopedData
RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfos KeyTransRecipientInfo
keyEncryptionAlgorithm fields.
Key transport encrypted content-encryption keys are located in the
EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey
field. Key transport encrypted message-authentication keys are
located in the AuthenticatedData RecipientInfos KeyTransRecipientInfo
encryptedKey field.
6.2 Key Agreement for AES
Implementations MAY include key agreement using X9.42 Ephemeral-
Static Diffie-Hellman. If ESDH is implemented, AES-KeyWrap MUST be
implemented.
A CMS implementation may support mixed key-encryption and content-
encryption algorithms. For example, a 128-bit AES content-encryption
key may be wrapped with 168-bit Triple DES key-encryption key.
Similarly, a 128-bit AES content-encryption key may be wrapped with
256-bit AES key-encryption key.
Key agreement algorithm identifiers are located in the EnvelopedData
RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
keyEncryptionAlgorithm fields.
Key wrap algorithm identifiers are located in the KeyWrapAlgorithm
parameters within the EnvelopedData RecipientInfos
KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData
RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields.
Wrapped content-encryption keys are located in the EnvelopedData
RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys
encryptedKey field. Wrapped message-authentication keys are located
in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
RecipientEncryptedKeys encryptedKey field.
Diffie-Hellman Key Wrap Key Derivation
Generation of the an AES key used in doing AES-KeyWrap is done using
the method in [DH] with the following modifications:
Schaad 4
Use of the AES Algorithm in CMS November 2000
The Hash function H will be [SHA-256] rather than SHA-1.
NOTE: 2 examples to be provided at this location.
6.3 Symmetric Key-Encryption Key Algorithms with AES
CMS implementations MAY include symmetric key-encryption key
management. Implementations compliant with this document MUST
include AES-256 key-encryption keys wrapping AES content-encryption
keys. A CMS implementation may support mixed key-encryption and
content-encryption algorithms. For example, a 128-bit AES content-
encryption key may be wrapped with 168-bit Triple-DES key-encryption
key or with a 256-bit AES key-encryption key.
Key wrap algorithm identifiers are located in the EnvelopedData
RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfos KEKRecipientInfo
keyEncryptionAlgorithm fields.
Wrapped content-encryption keys are located in the EnvelopedData
RecipientInfos KEKRecipientInfo encryptedKey field. Wrapped message-
authentication keys are located in the AuthenticatedData
RecipientInfos KEKRecipientInfo encryptedKey field.
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
RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
keyEncryptionAlgorithm fields. Wrapped content-encryption keys are
located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo
RecipientEncryptedKeys encryptedKey field, wrapped message-
authentication keys are located in the AuthenticatedData
RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys
encryptedKey field.
7. Security Considerations
To be supplied
Note on mix of OEAP and v1.5 RSA encryption from RFC 2437
8. Open Issues
- Key wrap algorithm is undetermined.
- Mandatory key sizes for Key Wrap
- Mandatory key sizes for AES algorithm
- Supplying any patent and licensing statements.
Schaad 5
Use of the AES Algorithm in CMS November 2000
- References to each algorithm that would be acceptable to the RFC
editor.
References
[DH] E. Rescorla, ôDiffie-Hellman Key Agreement Methodö, RFC 2631,
June 1999.
[IPR] See the "IETF Page of Intellectual Property Rights Notices",
http://www.ietf.cnri.reston.va.us/ipr.html
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", Internet Request for Comments RFC 2119, March 1997.
[CMS] R. Housley, "Cryptographic Message Syntax", Internet Request for
Comments RFC 2630, June 1999.
[RSA-OEAP] R. Housley, ôUse of the RSAES-OEAP Key Transport Algorithm in
CMSö, draft-ietf-smime-cms-rsaes-oeap.txt, June 2000.
[SMIME3] B. Ramsdell, "S/MIME Version 3 Certificate Handling", Internet
Request for Comments RFC 2632, June 1999.
B. Ramsdell, "S/MIME Version 3 Message Specification",
Internet Request for Comments RFC 2633, June 1999.
11. Author's Addresses
Jim Schaad
Soaring Hawk Consulting
Email: jimsch@exmsft.com
Schaad 6
| PAFTECH AB 2003-2026 | 2026-04-23 20:19:47 |