draft-ietf-smime-password-04.txt   draft-ietf-smime-password-05.txt 
Internet Draft Editor: Peter Gutmann Internet Draft Editor: Peter Gutmann
draft-ietf-smime-password-04.txt University of Auckland draft-ietf-smime-password-05.txt University of Auckland
July 17, 2001 August 26, 2001
Expires January 2002 Expires February 2002
Password-based Encryption for CMS Password-based Encryption for CMS
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
skipping to change at line 29 skipping to change at line 29
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright (C) The Internet Society July 2001. All Rights Reserved.
Abstract
The Cryptographic Message Syntax data format doesn't currently contain
any provisions for password-based data encryption. This document
provides a method of encrypting data using user-supplied passwords and,
by extension, any form of variable-length keying material which isn't
necessarily an algorithm-specific fixed-format key.
1. Introduction 1. Introduction
This document describes a password-based content encryption mechanism This document describes a password-based content encryption mechanism
for S/MIME. This is implemented as a new RecipientInfo type and is an for CMS. This is implemented as a new RecipientInfo type and is an
extension to the RecipientInfo types currently defined in RFC 2640 extension to the RecipientInfo types currently defined in RFC 2630
[RFC2640]. [RFC2630].
The format of the messages are described in ASN.1 [ASN1]. The format of the messages are described in ASN.1 [ASN1].
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119]. interpreted as described in [RFC2119].
1.1 Password-based Content Encryption 1.1 Password-based Content Encryption
CMS currently defined three recipient information types for public- key CMS currently defined three recipient information types for public- key
skipping to change at line 227 skipping to change at line 217
bytes of the CEK. bytes of the CEK.
3. The CEK. 3. The CEK.
4. Enough random padding data to make the CEK data block a multiple 4. Enough random padding data to make the CEK data block a multiple
of the KEK block length and at least two KEK cipher blocks long of the KEK block length and at least two KEK cipher blocks long
(the fact that 32 bits of count+check value are used means that (the fact that 32 bits of count+check value are used means that
even with a 40-bit CEK, the resulting data size will always be at even with a 40-bit CEK, the resulting data size will always be at
least two (64-bit) cipher blocks long). The padding data does not least two (64-bit) cipher blocks long). The padding data does not
have to be cryptographically strong, although unpredictability have to be cryptographically strong, although unpredictability
helps. helps. Note that PKCS #5 padding is not used, since the length of
the data is already known.
The formatted CEK block then looks as follows: The formatted CEK block then looks as follows:
CEK byte count || check value || CEK || padding (if required) CEK byte count || check value || CEK || padding (if required)
Key wrapping: Key wrapping:
1. Encrypt the padded key using the KEK. 1. Encrypt the padded key using the KEK.
2. Without resetting the IV (that is, using the last ciphertext block 2. Without resetting the IV (that is, using the last ciphertext block
skipping to change at line 478 skipping to change at line 469
71 04 40: OCTET STRING 71 04 40: OCTET STRING
: C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55 : C0 3C 51 4A BD B9 E2 C5 AA C0 38 57 2B 5E 24 55
: 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9 : 38 76 B3 77 AA FB 82 EC A5 A9 D7 3F 8A B1 43 D9
: EC 74 E6 CA D7 DB 26 0C : EC 74 E6 CA D7 DB 26 0C
: } : }
4. Security Considerations 4. Security Considerations
The security of this recipient information type rests on the security The security of this recipient information type rests on the security
of the underlying mechanisms employed, for which further information of the underlying mechanisms employed, for which further information
can be found in RFC 2640 and PKCS5v2. More importantly, however, when can be found in RFC 2630 and PKCS5v2. More importantly, however, when
used with a password the security of this information type rests on the used with a password the security of this information type rests on the
entropy of the user-selected password, which is typically quite low. entropy of the user-selected password, which is typically quite low.
Pass phrases (as opposed to simple passwords) are STRONGLY RECOMMENDED, Pass phrases (as opposed to simple passwords) are STRONGLY RECOMMENDED,
although it should be recognized that even with pass phrases it will be although it should be recognized that even with pass phrases it will be
difficult to use this recipient information type to derive a KEK with difficult to use this recipient information type to derive a KEK with
sufficient entropy to properly protect a 128-bit (or higher) CEK. sufficient entropy to properly protect a 128-bit (or higher) CEK.
5. IANA Considerations 5. IANA Considerations
The PasswordRecipientInfo key encryption algorithms are identified by The PasswordRecipientInfo key encryption algorithms are identified by
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/