📄 rfc2630.txt
字号:
Network Working Group R. Housley
Request for Comments: 2630 SPYRUS
Category: Standards Track June 1999
Cryptographic Message Syntax
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 (1999). All Rights Reserved.
Abstract
This document describes the Cryptographic Message Syntax. This
syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary messages.
The Cryptographic Message Syntax is derived from PKCS #7 version 1.5
as specified in RFC 2315 [PKCS#7]. Wherever possible, backward
compatibility is preserved; however, changes were necessary to
accommodate attribute certificate transfer and key agreement
techniques for key management.
Housley Standards Track [Page 1]
RFC 2630 Cryptographic Message Syntax June 1999
Table of Contents
1 Introduction ................................................. 4
2 General Overview ............................................. 4
3 General Syntax ............................................... 5
4 Data Content Type ............................................ 5
5 Signed-data Content Type ..................................... 6
5.1 SignedData Type ......................................... 7
5.2 EncapsulatedContentInfo Type ............................ 8
5.3 SignerInfo Type ......................................... 9
5.4 Message Digest Calculation Process ...................... 11
5.5 Message Signature Generation Process .................... 12
5.6 Message Signature Verification Process .................. 12
6 Enveloped-data Content Type .................................. 12
6.1 EnvelopedData Type ...................................... 14
6.2 RecipientInfo Type ...................................... 15
6.2.1 KeyTransRecipientInfo Type ....................... 16
6.2.2 KeyAgreeRecipientInfo Type ....................... 17
6.2.3 KEKRecipientInfo Type ............................ 19
6.3 Content-encryption Process .............................. 20
6.4 Key-encryption Process .................................. 20
7 Digested-data Content Type ................................... 21
8 Encrypted-data Content Type .................................. 22
9 Authenticated-data Content Type .............................. 23
9.1 AuthenticatedData Type .................................. 23
9.2 MAC Generation .......................................... 25
9.3 MAC Verification ........................................ 26
10 Useful Types ................................................. 27
10.1 Algorithm Identifier Types ............................. 27
10.1.1 DigestAlgorithmIdentifier ...................... 27
10.1.2 SignatureAlgorithmIdentifier ................... 27
10.1.3 KeyEncryptionAlgorithmIdentifier ............... 28
10.1.4 ContentEncryptionAlgorithmIdentifier ........... 28
10.1.5 MessageAuthenticationCodeAlgorithm ............. 28
10.2 Other Useful Types ..................................... 28
10.2.1 CertificateRevocationLists ..................... 28
10.2.2 CertificateChoices ............................. 29
10.2.3 CertificateSet ................................. 29
10.2.4 IssuerAndSerialNumber .......................... 30
10.2.5 CMSVersion ..................................... 30
10.2.6 UserKeyingMaterial ............................. 30
10.2.7 OtherKeyAttribute .............................. 30
Housley Standards Track [Page 2]
RFC 2630 Cryptographic Message Syntax June 1999
11 Useful Attributes ............................................ 31
11.1 Content Type ........................................... 31
11.2 Message Digest ......................................... 32
11.3 Signing Time ........................................... 32
11.4 Countersignature ....................................... 34
12 Supported Algorithms ......................................... 35
12.1 Digest Algorithms ...................................... 35
12.1.1 SHA-1 .......................................... 35
12.1.2 MD5 ............................................ 35
12.2 Signature Algorithms ................................... 36
12.2.1 DSA ............................................ 36
12.2.2 RSA ............................................ 36
12.3 Key Management Algorithms .............................. 36
12.3.1 Key Agreement Algorithms ....................... 36
12.3.1.1 X9.42 Ephemeral-Static Diffie-Hellman. 37
12.3.2 Key Transport Algorithms ....................... 38
12.3.2.1 RSA .................................. 39
12.3.3 Symmetric Key-Encryption Key Algorithms ........ 39
12.3.3.1 Triple-DES Key Wrap .................. 40
12.3.3.2 RC2 Key Wrap ......................... 41
12.4 Content Encryption Algorithms ........................... 41
12.4.1 Triple-DES CBC .................................. 42
12.4.2 RC2 CBC ......................................... 42
12.5 Message Authentication Code Algorithms .................. 42
12.5.1 HMAC with SHA-1 ................................. 43
12.6 Triple-DES and RC2 Key Wrap Algorithms .................. 43
12.6.1 Key Checksum .................................... 44
12.6.2 Triple-DES Key Wrap ............................. 44
12.6.3 Triple-DES Key Unwrap ........................... 44
12.6.4 RC2 Key Wrap .................................... 45
12.6.5 RC2 Key Unwrap .................................. 46
Appendix A: ASN.1 Module ........................................ 47
References ....................................................... 55
Security Considerations .......................................... 56
Acknowledgments .................................................. 58
Author's Address ................................................. 59
Full Copyright Statement ......................................... 60
Housley Standards Track [Page 3]
RFC 2630 Cryptographic Message Syntax June 1999
1 Introduction
This document describes the Cryptographic Message Syntax. This
syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary messages.
The Cryptographic Message Syntax describes an encapsulation syntax
for data protection. It supports digital signatures, message
authentication codes, and encryption. The syntax allows multiple
encapsulation, so one encapsulation envelope can be nested inside
another. Likewise, one party can digitally sign some previously
encapsulated data. It also allows arbitrary attributes, such as
signing time, to be signed along with the message content, and
provides for other attributes such as countersignatures to be
associated with a signature.
The Cryptographic Message Syntax can support a variety of
architectures for certificate-based key management, such as the one
defined by the PKIX working group.
The Cryptographic Message Syntax values are generated using ASN.1
[X.208-88], using BER-encoding [X.209-88]. Values are typically
represented as octet strings. While many systems are capable of
transmitting arbitrary octet strings reliably, it is well known that
many electronic-mail systems are not. This document does not address
mechanisms for encoding octet strings for reliable transmission in
such environments.
2 General Overview
The Cryptographic Message Syntax (CMS) is general enough to support
many different content types. This document defines one protection
content, ContentInfo. ContentInfo encapsulates a single identified
content type, and the identified type may provide further
encapsulation. This document defines six content types: data,
signed-data, enveloped-data, digested-data, encrypted-data, and
authenticated-data. Additional content types can be defined outside
this document.
An implementation that conforms to this specification must implement
the protection content, ContentInfo, and must implement the data,
signed-data, and enveloped-data content types. The other content
types may be implemented if desired.
As a general design philosophy, each content type permits single pass
processing using indefinite-length Basic Encoding Rules (BER)
encoding. Single-pass operation is especially helpful if content is
large, stored on tapes, or is "piped" from another process. Single-
Housley Standards Track [Page 4]
RFC 2630 Cryptographic Message Syntax June 1999
pass operation has one significant drawback: it is difficult to
perform encode operations using the Distinguished Encoding Rules
(DER) [X.509-88] encoding in a single pass since the lengths of the
various components may not be known in advance. However, signed
attributes within the signed-data content type and authenticated
attributes within the authenticated-data content type require DER
encoding. Signed attributes and authenticated attributes must be
transmitted in DER form to ensure that recipients can verify a
content that contains one or more unrecognized attributes. Signed
attributes and authenticated attributes are the only CMS data types
that require DER encoding.
3 General Syntax
The Cryptographic Message Syntax (CMS) associates a content type
identifier with a content. The syntax shall have ASN.1 type
ContentInfo:
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER
The fields of ContentInfo have the following meanings:
contentType indicates the type of the associated content. It is
an object identifier; it is a unique string of integers assigned
by an authority that defines the content type.
content is the associated content. The type of content can be
determined uniquely by contentType. Content types for data,
signed-data, enveloped-data, digested-data, encrypted-data, and
authenticated-data are defined in this document. If additional
content types are defined in other documents, the ASN.1 type
defined should not be a CHOICE type.
4 Data Content Type
The following object identifier identifies the data content type:
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }
The data content type is intended to refer to arbitrary octet
strings, such as ASCII text files; the interpretation is left to the
application. Such strings need not have any internal structure
Housley Standards Track [Page 5]
RFC 2630 Cryptographic Message Syntax June 1999
(although they could have their own ASN.1 definition or other
structure).
The data content type is generally encapsulated in the signed-data,
enveloped-data, digested-data, encrypted-data, or authenticated-data
content type.
5 Signed-data Content Type
The signed-data content type consists of a content of any type and
zero or more signature values. Any number of signers in parallel can
sign any type of content.
The typical application of the signed-data content type represents
one signer's digital signature on content of the data content type.
Another typical application disseminates certificates and certificate
revocation lists (CRLs).
The process by which signed-data is constructed involves the
following steps:
1. For each signer, a message digest, or hash value, is computed
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -