Password-based Encryption for CMS
RFC 3211
|
Document |
Type |
|
RFC - Proposed Standard
(December 2001; No errata)
|
|
Author |
|
Peter Gutmann
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 3211 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group P. Gutmann
Request for Comments: 3211 University of Auckland
Category: Standards Track December 2001
Password-based Encryption for CMS
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document provides a method of encrypting data using user-
supplied passwords and, by extension, any form of variable-length
keying material which is not necessarily an algorithm-specific
fixed-format key. The Cryptographic Message Syntax data format does
not currently contain any provisions for password-based data
encryption.
1. Introduction
This document describes a password-based content encryption mechanism
for CMS. This is implemented as a new RecipientInfo type and is an
extension to the RecipientInfo types currently defined in RFC 2630.
The format of the messages are described in ASN.1 [ASN1].
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119.
Gutmann Standards Track [Page 1]
RFC 3211 Password-based Encryption for CMS December 2001
1.1 Password-based Content Encryption
CMS currently defined three recipient information types for public-
key key wrapping (KeyTransRecipientInfo), conventional key wrapping
(KEKRecipientInfo), and key agreement (KeyAgreeRecipientInfo). The
recipient information described here adds a fourth type,
PasswordRecipientInfo, which provides for password-based key
wrapping.
1.2 RecipientInfo Types
The new recipient information type is an extension to the
RecipientInfo type defined in section 6.2 of CMS, extending the types
to:
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo -- New RecipientInfo type
}
Although the recipient information generation process is described in
terms of a password-based operation (since this will be its most
common use), the transformation employed is a general-purpose key
derivation one which allows any type of keying material to be
converted into a key specific to a particular content-encryption
algorithm. Since the most common use for password-based encryption
is to encrypt files which are stored locally (rather than being
transmitted across a network), the term "recipient" is somewhat
misleading, but is used here because the other key transport
mechanisms have always been described in similar terms.
1.2.1 PasswordRecipientInfo Type
Recipient information using a user-supplied password or previously
agreed-upon key is represented in the type PasswordRecipientInfo.
Each instance of PasswordRecipientInfo will transfer the content-
encryption key (CEK) to one or more recipients who have the
previously agreed-upon password or key-encryption key (KEK).
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
keyDerivationAlgorithm
[0] KeyDerivationAlgorithmIdentifier OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
Gutmann Standards Track [Page 2]
RFC 3211 Password-based Encryption for CMS December 2001
The fields of type PasswordRecipientInfo have the following meanings:
version is the syntax version number. It MUST be 0. Details of
the CMSVersion type are discussed in CMS [RFC2630], section
10.2.5.
keyDerivationAlgorithm identifies the key-derivation algorithm,
and any associated parameters, used to derive the KEK from the
user-supplied password. If this field is absent, the KEK is
supplied from an external source, for example a crypto token such
as a smart card.
keyEncryptionAlgorithm identifies the key-encryption algorithm,
and any associated parameters, used to encrypt the CEK with the
KEK.
encryptedKey is the result of encrypting the content-encryption
key with the KEK.
1.2.2 Rationale
Password-based key wrapping is a two-stage process, a first stage in
which a user-supplied password is converted into a KEK if required,
and a second stage in which the KEK is used to encrypt a CEK. These
Show full document text