互联网标准协议：RFC2630-加密消息语法

下载需积分: 9 | PDF格式 | 72KB | 更新于2024-07-09 | 123 浏览量 | 举报

"rfc2630.pdf" 本文档RFC2630是关于电子签名的国际规范，详细定义了密码消息语法（Cryptographic Message Syntax），旨在为互联网社区提供一个标准轨道协议，并鼓励进行讨论和改进建议。RFC文档的发布遵循互联网官方协议标准（STD1）的最新版规定，且不限制该文档的分发。该文档的版权归互联网协会所有。 RFC2630的核心内容是对任意消息进行数字签名、摘要、认证或加密的一种语法，它源自PKCS#7版本1.5，如在RFC2315中所定义。为了保持向后兼容性，尽可能地保留了原有特性，但同时也进行了必要的修改，以支持属性证书传递和密钥协商技术，用于更有效的密钥管理。文档结构包括： 1. 引言：这部分概述了RFC2630的主要目标和背景，解释了为何需要这种密码消息语法以及它与PKCS#7的关系。 2. 术语：定义了文档中使用的专业术语和概念，确保读者对文档的理解一致性。 3. 消息语法：详细描述了消息的结构和组成，包括如何表示签名、加密和认证信息。 4. 数字签名：解释了如何使用公钥基础设施（PKI）中的私钥对消息进行签名，以验证消息的完整性和来源。 5. 摘要：介绍了消息摘要的计算方法，如使用SHA-1或MD5等算法，用于检测数据的任何改动。 6. 加密：说明了如何使用公钥加密技术保护消息的机密性，确保只有拥有相应私钥的接收者才能解密。 7. 密钥管理：探讨了密钥的生成、交换和撤销策略，以及如何使用属性证书来增强密钥管理的安全性。 8. 安全考虑：讨论了可能的安全风险和防范措施，确保系统的安全性和可靠性。 9. 实现注意事项：提供了实现密码消息语法时应考虑的技术细节和潜在问题。 10. IANA考虑：阐述了与Internet Assigned Numbers Authority（IANA）相关的注册和分配事宜。 11. 参考文献：列出相关标准、规范和其他参考材料。 12. 作者的地址：列出文档作者的联系信息。 13. 全文结束。 RFC2630的制定是为了促进不同系统之间的互操作性，确保电子签名的有效性和安全性，适用于电子邮件、文件传输、合同签署等场景，对于构建可靠的电子商务和电子政务平台至关重要。通过遵循这一标准，开发者可以创建符合国际规范的电子签名解决方案，提高数据的保护水平和信任度。

RFC 2630 Cryptographic Message Syntax June 1999

the SignerIdentifier is subjectKeyIdentifier, then the version

shall be 3.

sid specifies the signer’s certificate (and thereby the signer’s

public key). The signer’s public key is needed by the recipient

to verify the signature. SignerIdentifier provides two

alternatives for specifying the signer’s public key. The

issuerAndSerialNumber alternative identifies the signer’s

certificate by the issuer’s distinguished name and the certificate

serial number; the subjectKeyIdentifier identifies the signer’s

certificate by the X.509 subjectKeyIdentifier extension value.

digestAlgorithm identifies the message digest algorithm, and any

associated parameters, used by the signer. The message digest is

computed on either the content being signed or the content

together with the signed attributes using the process described in

section 5.4. The message digest algorithm should be among those

listed in the digestAlgorithms field of the associated SignerData.

signedAttributes is a collection of attributes that are signed.

The field is optional, but it must be present if the content type

of the EncapsulatedContentInfo value being signed is not id-data.

Each SignedAttribute in the SET must be DER encoded. Useful

attribute types, such as signing time, are defined in Section 11.

If the field is present, it must contain, at a minimum, the

following two attributes:

A content-type attribute having as its value the content type

of the EncapsulatedContentInfo value being signed. Section

11.1 defines the content-type attribute. The content-type

attribute is not required when used as part of a

countersignature unsigned attribute as defined in section 11.4.

A message-digest attribute, having as its value the message

digest of the content. Section 11.2 defines the message-digest

attribute.

signatureAlgorithm identifies the signature algorithm, and any

associated parameters, used by the signer to generate the digital

signature.

signature is the result of digital signature generation, using the

message digest and the signer’s private key.

unsignedAttributes is a collection of attributes that are not

signed. The field is optional. Useful attribute types, such as

countersignatures, are defined in Section 11.

Housley Standards Track [Page 10]

RFC 2630 Cryptographic Message Syntax June 1999

The fields of type SignedAttribute and UnsignedAttribute have the

following meanings:

attrType indicates the type of attribute. It is an object

identifier.

attrValues is a set of values that comprise the attribute. The

type of each value in the set can be determined uniquely by

attrType.

5.4 Message Digest Calculation Process

The message digest calculation process computes a message digest on

either the content being signed or the content together with the

signed attributes. In either case, the initial input to the message

digest calculation process is the "value" of the encapsulated content

being signed. Specifically, the initial input is the

encapContentInfo eContent OCTET STRING to which the signing process

is applied. Only the octets comprising the value of the eContent

OCTET STRING are input to the message digest algorithm, not the tag

or the length octets.

The result of the message digest calculation process depends on

whether the signedAttributes field is present. When the field is

absent, the result is just the message digest of the content as

described above. When the field is present, however, the result is

the message digest of the complete DER encoding of the

SignedAttributes value contained in the signedAttributes field.

Since the SignedAttributes value, when present, must contain the

content type and the content message digest attributes, those values

are indirectly included in the result. The content type attribute is

not required when used as part of a countersignature unsigned

attribute as defined in section 11.4. A separate encoding of the

signedAttributes field is performed for message digest calculation.

The IMPLICIT [0] tag in the signedAttributes field is not used for

the DER encoding, rather an EXPLICIT SET OF tag is used. That is,

the DER encoding of the SET OF tag, rather than of the IMPLICIT [0]

tag, is to be included in the message digest calculation along with

the length and content octets of the SignedAttributes value.

When the signedAttributes field is absent, then only the octets

comprising the value of the signedData encapContentInfo eContent

OCTET STRING (e.g., the contents of a file) are input to the message

digest calculation. This has the advantage that the length of the

content being signed need not be known in advance of the signature

generation process.

Housley Standards Track [Page 11]

RFC 2630 Cryptographic Message Syntax June 1999

Although the encapContentInfo eContent OCTET STRING tag and length

octets are not included in the message digest calculation, they are

still protected by other means. The length octets are protected by

the nature of the message digest algorithm since it is

computationally infeasible to find any two distinct messages of any

length that have the same message digest.

5.5 Message Signature Generation Process

The input to the signature generation process includes the result of

the message digest calculation process and the signer’s private key.

The details of the signature generation depend on the signature

algorithm employed. The object identifier, along with any

parameters, that specifies the signature algorithm employed by the

signer is carried in the signatureAlgorithm field. The signature

value generated by the signer is encoded as an OCTET STRING and

carried in the signature field.

5.6 Message Signature Verification Process

The input to the signature verification process includes the result

of the message digest calculation process and the signer’s public

key. The recipient may obtain the correct public key for the signer

by any means, but the preferred method is from a certificate obtained

from the SignedData certificates field. The selection and validation

of the signer’s public key may be based on certification path

validation (see [PROFILE]) as well as other external context, but is

beyond the scope of this document. The details of the signature

verification depend on the signature algorithm employed.

The recipient may not rely on any message digest values computed by

the originator. If the signedData signerInfo includes

signedAttributes, then the content message digest must be calculated

as described in section 5.4. For the signature to be valid, the

message digest value calculated by the recipient must be the same as

the value of the messageDigest attribute included in the

signedAttributes of the signedData signerInfo.

6 Enveloped-data Content Type

The enveloped-data content type consists of an encrypted content of

any type and encrypted content-encryption keys for one or more

recipients. The combination of the encrypted content and one

encrypted content-encryption key for a recipient is a "digital

envelope" for that recipient. Any type of content can be enveloped

for an arbitrary number of recipients using any of the three key

management techniques for each recipient.

Housley Standards Track [Page 12]

剩余59页未读，继续阅读

brokenzyc

粉丝: 0

互联网标准协议：RFC2630-加密消息语法

网络工程师必备：RFC标准文档全集8000套

安全超文本传输协议(SHTTP)详解

HTTP协议详解：RFC2616标准PDF版

RFC3501.rar_RFC3501_rfc 3501_rfc35_rfc3501 pdf_rfc3501.pdf

rfc6550.pdf

rfc2616.pdf

rfc5416.pdf

rfc7049.pdf

rfc3549.pdf

rfc3315.pdf

最新资源