draft-ietf-smime-cms-auth-enveloped-02.txt   draft-ietf-smime-cms-auth-enveloped-03.txt 
S/MIME Working Group R. Housley S/MIME Working Group R. Housley
Internet-Draft Vigil Security Internet-Draft Vigil Security
Updates: 3852 (if approved) February 2007
Cryptographic Message Syntax (CMS) Cryptographic Message Syntax (CMS)
Authenticated-Enveloped-Data Content Type Authenticated-Enveloped-Data Content Type
<draft-ietf-smime-cms-auth-enveloped-02.txt> <draft-ietf-smime-cms-auth-enveloped-03.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 4, line 26 skipping to change at page 4, line 29
authenticated attributes, then unauthenticated attributes, and the authenticated attributes, then unauthenticated attributes, and the
authenticated and encrypted content are collected together to form authenticated and encrypted content are collected together to form
an AuthEnvelopedData value as defined in Section 2.1. an AuthEnvelopedData value as defined in Section 2.1.
A recipient opens the digital envelope by decrypting one of the A recipient opens the digital envelope by decrypting one of the
encrypted content-authenticated-encryption keys, and then using the encrypted content-authenticated-encryption keys, and then using the
recovered key to decrypt and verify the integrity of the recovered key to decrypt and verify the integrity of the
authenticated and encrypted content as well as verifying the authenticated and encrypted content as well as verifying the
integrity of the authenticated attributes. integrity of the authenticated attributes.
The recipient MUST verify the integrity of the received content
before releasing any information, especially the plaintext of the
content. If the integrity verification fails, the receiver MUST
destroy all of the plaintext of the content.
This section is divided into three parts. The first part describes This section is divided into three parts. The first part describes
the AuthEnvelopedData content type, the second part describes the the AuthEnvelopedData content type, the second part describes the
authentication and encryption process, and third part describes the authentication and encryption process, and third part describes the
key encryption process. key encryption process.
2.1 AuthEnvelopedData Type 2.1 AuthEnvelopedData Type
The following object identifier identifies the authenticated- The following object identifier identifies the authenticated-
enveloped-data content type: enveloped-data content type:
skipping to change at page 5, line 19 skipping to change at page 5, line 41
originator. It is present only if required by the key originator. It is present only if required by the key
management algorithm. It may contain certificates and CRLs, management algorithm. It may contain certificates and CRLs,
and the OriginatorInfo type is defined in Section 6.1 of [CMS]. and the OriginatorInfo type is defined in Section 6.1 of [CMS].
recipientInfos is a collection of per-recipient information. recipientInfos is a collection of per-recipient information.
There MUST be at least one element in the collection. The There MUST be at least one element in the collection. The
RecipientInfo type is defined in Section 6.2 of [CMS]. RecipientInfo type is defined in Section 6.2 of [CMS].
authAttrs optionally contains the authenticated attributes. The authAttrs optionally contains the authenticated attributes. The
CMS authenticated-data content type uses the same type to carry CMS authenticated-data content type uses the same type to carry
authenticated attributes. The AuthAttributes type is defined authenticated attributes. The authAttrs MUST be present if the
in Section 9.1 of [CMS]; however, in this case, there is no content type carried in EncryptedContentInfo is not id-data.
requirement to include the message-digest attribute. Useful AuthAttributes MUST be DER encoded, even if the rest of the
AuthEnvelopedData structure is BER encoded. The AuthAttributes
type is defined in Section 9.1 of [CMS]; however, in this case,
the message-digest attribute SHOULD NOT be included. Useful
attribute types are defined in Section 11 of [CMS]. attribute types are defined in Section 11 of [CMS].
Note: Similar to AuthenticatedData, the DER encoded
AuthAttributes are carried in the AuthEnvelopedData structure
and used in the computation of the MAC. This is different than
SignedData, where slightly different encodings of the signed
attributes are used in the SigendData structure and the
computation of the digest value.
authEncryptedContentInfo is the authenticated and encrypted authEncryptedContentInfo is the authenticated and encrypted
content. The CMS enveloped-data content type uses the same content. The CMS enveloped-data content type uses the same
type to carry the encrypted content. The EncryptedContentInfo type to carry the encrypted content. The EncryptedContentInfo
type is defined in Section 6.1 of [CMS]. type is defined in Section 6.1 of [CMS].
mac is the integrity check value (ICV) or message authentication mac is the integrity check value (ICV) or message authentication
code (MAC) that is generated by the authenticated encryption code (MAC) that is generated by the authenticated encryption
algorithm. The CMS authenticated-data content type uses the algorithm. The CMS authenticated-data content type uses the
same type to carry a MAC. In this case, the MAC covers the same type to carry a MAC. In this case, the MAC covers the
authenticated attributes and the content directly, and a digest authenticated attributes and the content directly, and a digest
skipping to change at page 7, line 8 skipping to change at page 7, line 39
counter mode are at least as strong as those for CBC mode when using counter mode are at least as strong as those for CBC mode when using
the same block cipher. the same block cipher.
Unfortunately, it is easy to misuse counter mode. If counter block Unfortunately, it is easy to misuse counter mode. If counter block
values are ever used for more that one encryption operation with the values are ever used for more that one encryption operation with the
same key, then the same key stream will be used to encrypt both same key, then the same key stream will be used to encrypt both
plaintexts, and the confidentiality guarantees are voided. plaintexts, and the confidentiality guarantees are voided.
Fortunately, the CMS authenticated-enveloped-data content type Fortunately, the CMS authenticated-enveloped-data content type
provides all of the tools needed to avoid misuse of counter mode. provides all of the tools needed to avoid misuse of counter mode.
When using key transport or key agreement, a fresh key should be All of the existing key management techniques permit a fresh content-
generated for each content. However, when using symmetric key- encryption key to be generated for each content. In addition,
encryption keys or passwords, one cannot assume that a fresh key is existing authenticated encryption algorithms that make use of counter
generated. Therefore, authenticated encryption algorithms that make mode support the use of an unpredictable nonce value in the counter
use of counter mode must support the use of an unpredictable nonce block. This unpredictable nonce value (sometimes called a "salt")
value in the counter block, and this unpredictable nonce value should be carried in an algorithm identifier parameter.
(sometimes called a "salt") must be carried as an algorithm
identifier parameter.
There are fairly generic precomputation attacks against all block There are fairly generic precomputation attacks against all block
cipher modes that allow a meet-in-the-middle attack against the key. cipher modes that allow a meet-in-the-middle attack against the key.
These attacks require the creation and searching of huge tables of These attacks require the creation and searching of huge tables of
ciphertext associated with known plaintext and known keys. Assuming ciphertext associated with known plaintext and known keys. Assuming
that the memory and processor resources are available for a that the memory and processor resources are available for a
precomputation attack, then the theoretical strength of any block precomputation attack, then the theoretical strength of any block
cipher mode is limited to 2^(n/2) bits, where n is the number of bits cipher mode is limited to 2^(n/2) bits, where n is the number of bits
in the key. The use of long keys is the best countermeasure to in the key. The use of long keys is the best countermeasure to
precomputation attacks. Use of an unpredictable nonce value in the precomputation attacks. Use of an unpredictable nonce value in the
skipping to change at page 7, line 40 skipping to change at page 8, line 21
encryption keys, padding, and unpredictable nonce values. Also, the encryption keys, padding, and unpredictable nonce values. Also, the
generation of public/private key pairs relies on a random numbers. generation of public/private key pairs relies on a random numbers.
The use of inadequate pseudo-random number generators (PRNGs) to The use of inadequate pseudo-random number generators (PRNGs) to
generate cryptographic keys can result in little or no security. An generate cryptographic keys can result in little or no security. An
attacker may find it much easier to reproduce the PRNG environment attacker may find it much easier to reproduce the PRNG environment
that produced the keys, searching the resulting small set of that produced the keys, searching the resulting small set of
possibilities, rather than brute force searching the whole key space. possibilities, rather than brute force searching the whole key space.
The generation of quality random numbers is difficult. RFC 4086 The generation of quality random numbers is difficult. RFC 4086
[RANDOM] offers important guidance in this area. [RANDOM] offers important guidance in this area.
4 ASN.1 Module If the message-digest attribute is included in the AuthAttributes,
then attribute value will contain the unencrypted one-way hash value
of the plaintext of the content. Disclosure of this hash value
enables content tracking, and it can be used to determine if the
plaintext matches one or more candidate contents. For these reasons,
the AuthAttributes SHOULD NOT contain the message-digest attribute.
4. IANA Considerations
None.
{{{ RFC Editor: Please remove this section prior to publication. }}}
5. ASN.1 Module
CMS-AuthEnvelopedData-2007 CMS-AuthEnvelopedData-2007
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) cms-authEnvelopedData(31) } pkcs-9(9) smime(16) modules(0) cms-authEnvelopedData(31) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All -- EXPORTS All
-- The types and values defined in this module are exported for use -- The types and values defined in this module are exported for use
skipping to change at page 8, line 32 skipping to change at page 10, line 5
version CMSVersion, version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos, recipientInfos RecipientInfos,
authAttrs [1] IMPLICIT AuthAttributes OPTIONAL, authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
authEncryptedContentInfo EncryptedContentInfo, authEncryptedContentInfo EncryptedContentInfo,
mac MessageAuthenticationCode, mac MessageAuthenticationCode,
unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL } unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }
END -- of CMS-AuthEnvelopedData-2007 END -- of CMS-AuthEnvelopedData-2007
5. Normative References 6. References
6.1. Normative References
[CMS] Housley, R., "Cryptographic Message Syntax", [CMS] Housley, R., "Cryptographic Message Syntax",
RFC 3852, July 2004. RFC 3852, July 2004.
[STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate [STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract [X.208-88] CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988. Syntax Notation One (ASN.1). 1988.
[X.209-88] CCITT. Recommendation X.209: Specification of Basic [X.209-88] CCITT. Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1). Encoding Rules for Abstract Syntax Notation One (ASN.1).
1988. 1988.
[X.509-88] CCITT. Recommendation X.509: The Directory - [X.509-88] CCITT. Recommendation X.509: The Directory -
Authentication Framework. 1988. Authentication Framework. 1988.
6. Informative References 6.2. Informative References
[AEALGS] Housley, R., "Using AES-CCM and AES-GCM Authenticated [AEALGS] Housley, R., "Using AES-CCM and AES-GCM Authenticated
Encryption in the Cryptographic Message Syntax (CMS)", Encryption in the Cryptographic Message Syntax (CMS)",
work in progress. draft-ietf-smime-cms-aes-ccm-and-gcm. work in progress. draft-ietf-smime-cms-aes-ccm-and-gcm.
[BDJR] Bellare, M., Desai, A., Jokipii, E., and P. Rogaway, [BDJR] Bellare, M., Desai, A., Jokipii, E., and P. Rogaway,
"A Concrete Security Treatment of Symmetric Encryption: "A Concrete Security Treatment of Symmetric Encryption:
Analysis of the DES Modes of Operation", Proceedings Analysis of the DES Modes of Operation", Proceedings
38th Annual Symposium on Foundations of Computer 38th Annual Symposium on Foundations of Computer
Science, 1997. Science, 1997.
 End of changes. 9 change blocks. 
17 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/