Independent Submission L. Cailleux
Request for Comments: 7508 DGA MI
Category: Experimental C. Bonatti
ISSN: 2070-1721 IECA
April 2015
Independent Submission L. Cailleux
Request for Comments: 7508 DGA MI
Category: Experimental C. Bonatti
ISSN: 2070-1721 IECA
April 2015
Securing Header Fields with S/MIME
使用S/MIME保护头字段
Abstract
摘要
This document describes how the S/MIME protocol can be extended in order to secure message header fields defined in RFC 5322. This technology provides security services such as data integrity, non-repudiation, and confidentiality. This extension is referred to as 'Secure Headers'.
本文档描述了如何扩展S/MIME协议以保护RFC 5322中定义的消息头字段。该技术提供数据完整性、不可否认性和保密性等安全服务。此扩展名称为“安全标头”。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7508.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7508.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology and Conventions Used in This Document ...............3
3. Context .........................................................4
4. Mechanisms to Secure Message Header Fields ......................6
4.1. ASN.1 Syntax of Secure Header Fields .......................7
4.2. Secure Header Fields Length and Format .....................8
4.3. Canonicalization Algorithm .................................8
4.4. Header Field Statuses ......................................8
4.5. Signature Process ..........................................9
4.5.1. Signature Generation Process ........................9
4.5.2. Signature Verification Process .....................10
4.6. Encryption and Decryption Processes .......................11
4.6.1. Encryption Process .................................11
4.6.2. Decryption Process .................................12
5. Case of Triple Wrapping ........................................13
6. Security Gateways ..............................................13
7. Security Considerations ........................................13
8. IANA Considerations ............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
Appendix A. Formal Syntax of Secure Header ........................16
Appendix B. Example of Secure Header Fields .......................18
Acknowledgements ..................................................19
Authors' Addresses ................................................19
1. Introduction ....................................................2
2. Terminology and Conventions Used in This Document ...............3
3. Context .........................................................4
4. Mechanisms to Secure Message Header Fields ......................6
4.1. ASN.1 Syntax of Secure Header Fields .......................7
4.2. Secure Header Fields Length and Format .....................8
4.3. Canonicalization Algorithm .................................8
4.4. Header Field Statuses ......................................8
4.5. Signature Process ..........................................9
4.5.1. Signature Generation Process ........................9
4.5.2. Signature Verification Process .....................10
4.6. Encryption and Decryption Processes .......................11
4.6.1. Encryption Process .................................11
4.6.2. Decryption Process .................................12
5. Case of Triple Wrapping ........................................13
6. Security Gateways ..............................................13
7. Security Considerations ........................................13
8. IANA Considerations ............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
Appendix A. Formal Syntax of Secure Header ........................16
Appendix B. Example of Secure Header Fields .......................18
Acknowledgements ..................................................19
Authors' Addresses ................................................19
The S/MIME [RFC5751] standard defines a data encapsulation format for the achievement of end-to-end security services such as integrity, authentication, non-repudiation, and confidentiality. By default, S/MIME secures message body parts, at the exclusion of the message header fields.
S/MIME[RFC5751]标准定义了一种数据封装格式，用于实现端到端安全服务，如完整性、身份验证、不可否认性和机密性。默认情况下，S/MIME保护消息正文部分，不包括消息头字段。
S/MIME provides an alternative solution to secure header fields: "the sending client MAY wrap a full MIME message in a message/rfc822 wrapper in order to apply S/MIME security services to header fields". However, the S/MIME solution doesn't provide any guidance regarding what subset of message header fields to secure, procedures for clients to reconcile the "inner" and "outer" headers, or procedures for client interpretation or display of any failures.
S/MIME提供了另一种保护头字段的解决方案：“发送客户端可以将完整的MIME消息包装在消息/rfc822包装器中，以便将S/MIME安全服务应用于头字段”。但是，S/MIME解决方案没有提供任何有关要保护的消息头字段子集、客户端协调“内部”和“外部”头的过程、客户端解释或显示任何故障的过程的指导。
Several other security specifications supplement S/MIME features but fail to address the target requirement set of this document. Such other security specifications include DomainKeys Identified Mail (DKIM) [RFC6376], STARTTLS [RFC3207], TLS with IMAP [RFC2595], and an
其他几个安全规范补充了S/MIME特性，但未能满足本文档的目标需求集。此类其他安全规范包括域密钥标识邮件（DKIM）[RFC6376]、STARTTLS[RFC3207]、带有IMAP的TLS[RFC2595]和
Internet-Draft referred to as "Protected Headers" [PRHDRS]. An explanation of what these services accomplish and why they do not solve this problem can be found in subsequent sections.
互联网草案称为“受保护的标题”[PRHDRS]。关于这些服务完成了什么以及为什么它们不能解决这个问题的解释可以在后面的章节中找到。
The goal of this document is to define end-to-end secure header field mechanisms compliant with S/MIME standard. This technique is based on the signed attribute fields of a Cryptographic Message Syntax (CMS) [RFC5652] signature.
本文档的目标是定义符合S/MIME标准的端到端安全头字段机制。该技术基于加密消息语法（CMS）[RFC5652]签名的签名属性字段。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The terms Message User Agent (MUA), Message Submission Agent (MSA), and Message Transfer Agent (MTA) are defined in the email architecture document [RFC5598].
电子邮件体系结构文档[RFC5598]中定义了邮件用户代理（MUA）、邮件提交代理（MSA）和邮件传输代理（MTA）这三个术语。
The term Domain Confidentiality Authority (DCA) is defined in the S/MIME Domain Security specification [RFC3183].
术语域保密机构（DCA）在S/MIME域安全规范[RFC3183]中定义。
End-to-end Internet Mail exchanges are performed between message originators and recipients.
在邮件发起人和收件人之间执行端到端的Internet邮件交换。
The term message header fields is described in [RFC5322]. A header field is composed of a name and a value.
[RFC5322]中描述了术语消息头字段。标题字段由名称和值组成。
Secure Headers technology uses header field statuses required to provide a confidentiality service toward message headers. The following three terms are used to describe the field statuses:
安全标头技术使用所需的标头字段状态为消息标头提供保密服务。以下三个术语用于描述字段状态：
- duplicated (the default status). When this status is present or if no status is specified, the signature process embeds the header field value in the digital signature, but the value is also present in the message header fields.
- 重复（默认状态）。当此状态存在或未指定状态时，签名过程将在数字签名中嵌入标头字段值，但该值也存在于消息标头字段中。
- deleted. When this status is present, the signature process embeds the header field value in the digital signature, and the encryption process deletes this field from the message to preserve its confidentiality.
- 删除。当此状态存在时，签名过程将头字段值嵌入数字签名中，加密过程从消息中删除此字段以保持其机密性。
- modified. When this status is present, the signature process embeds the header field value in the digital signature, and the encryption process modifies the value of the header field in the message. This preserves confidentiality and informs a receiver's
- 被改进的。当此状态存在时，签名过程将头字段值嵌入数字签名中，加密过程修改消息中头字段的值。这可以保护机密性并通知接收者
noncompliant MUA that secure headers are being used. New values for each field might be configured by the sender (i.e., "This header is secured; use a compliant client.").
正在使用安全标头的不符合MUA。每个字段的新值可能由发送方配置（即，“此标头是安全的；使用兼容的客户端”）。
The term non-repudiation is used throughout this document in deference to the usage in the S/MIME Message Specification [RFC5751]. It is recognized that this term carries with it much baggage, and that there is some disagreement as to its proper meaning and usage. However, in the context of this document, the term merely refers to one set of possible security services that a conforming implementation might be able to provide. This document specifies no normative requirements for non-repudiation.
根据S/MIME消息规范[RFC5751]中的用法，本文档中使用了术语不可否认性。人们认识到，这一术语带有许多包袱，对其正确含义和用法存在一些分歧。然而，在本文件的上下文中，该术语仅指一致性实现可能提供的一组可能的安全服务。本文件未规定不可抵赖性的规范性要求。
Over the Internet, email use has grown and today represents a fundamental service. Meanwhile, continually increasing threat levels are motivating the implementation of security services.
在互联网上，电子邮件的使用量不断增长，如今已成为一项基本服务。与此同时，不断增加的威胁水平正在推动安全服务的实施。
Historically, SMTP [RFC5321] and the Internet Message Format (IMF) [RFC5322] don't provide, by default, security services. The S/MIME standard [RFC5751] was published in order to address these needs. S/MIME defines a data encapsulation format for the provision of end-to-end security services such as integrity, authentication, non-repudiation, and confidentiality. By default, S/MIME secures message body parts, at the exclusion of the message header fields. In order to protect message header fields (for instance, the "Subject", "To", "From", or customized fields), several solutions exist.
历史上，SMTP[RFC5321]和Internet消息格式（IMF）[RFC5322]默认情况下不提供安全服务。为了满足这些需求，发布了S/MIME标准[RFC5751]。S/MIME定义了一种数据封装格式，用于提供端到端安全服务，如完整性、身份验证、不可否认性和机密性。默认情况下，S/MIME保护消息正文部分，不包括消息头字段。为了保护消息头字段（例如，“主题”、“收件人”、“发件人”或自定义字段），存在几种解决方案。
In Section 3.1 of [RFC5751], S/MIME defines an encapsulation mechanism:
在[RFC5751]的第3.1节中，S/MIME定义了一种封装机制：
[...] the sending client MAY wrap a full MIME message in a message/rfc822 wrapper in order to apply S/MIME security services to these header fields. It is up to the receiving client to decide how to present this "inner" header along with the unprotected "outer" header.
[…]发送客户端可以将完整的MIME消息包装在message/rfc822包装器中，以便将S/MIME安全服务应用于这些头字段。由接收客户端决定如何显示此“内部”标头和未受保护的“外部”标头。
However, some use cases are not addressed, especially in the case of message encryption. What happens when header fields are encrypted? How does the receiving client display these header fields? How can a subset of header fields be secured? S/MIME doesn't address these issues.
但是，有些用例没有得到解决，特别是在消息加密的情况下。头字段加密时会发生什么情况？接收客户端如何显示这些标题字段？如何保护标题字段的子集？S/MIME不能解决这些问题。
Some partial header protection is provided by the S/MIME Certificate Handling specification [RFC5750]:
S/MIME证书处理规范[RFC5750]提供了一些部分头保护：
Receiving agents MUST check that the address in the From or Sender header of a mail message matches an Internet mail address, if present, in the signer's certificate, if mail addresses are present in the certificate.
接收代理必须检查邮件消息的发件人或发件人标头中的地址是否与签名者证书中的Internet邮件地址（如果存在）匹配（如果证书中存在邮件地址）。
In some cases, this may provide assurance of the integrity of the From or Sender header values. However, the solution in RFC 5750 only provides a matching mechanism between email addresses and provides no protection to other header fields.
在某些情况下，这可以保证From或Sender头值的完整性。但是，RFC 5750中的解决方案仅提供电子邮件地址之间的匹配机制，而不提供对其他标头字段的保护。
Other security specifications (introduced below) exist such as DKIM, STARTTLS and TLS with IMAP, but they meet other needs (signing domain, secure channels, etc.).
存在其他安全规范（下文介绍），如DKIM、STARTTLS和带有IMAP的TLS，但它们满足其他需求（签名域、安全通道等）。
STARTTLS and TLS with IMAP provide secure channels between components of the email system (MUA, MSA, MTA, etc.), but end-to-end integrity cannot be guaranteed.
带有IMAP的STARTTLS和TLS提供电子邮件系统组件（MUA、MSA、MTA等）之间的安全通道，但无法保证端到端的完整性。
DKIM defines a domain-level authentication framework for email. While this permits integrity and origination checks on message header fields and the message body, it does this for a domain actor (usually the SMTP service or equivalent) and not for the entity that is sending, and thus signing, the message. (Extensions to DKIM might be able to solve this issue by authenticating the sender and making a statement of this fact as part of the signed message headers.) DKIM is also deficient for our purposes, as it does not provide a confidentially service.
DKIM为电子邮件定义了域级身份验证框架。虽然这允许对邮件头字段和邮件正文进行完整性和原始信息检查，但它是为域参与者（通常是SMTP服务或等效服务）而不是为发送邮件并进行签名的实体执行的。（对DKIM的扩展可能能够通过验证发送方并在签名消息头中声明这一事实来解决此问题。）DKIM对于我们来说也是有缺陷的，因为它不提供保密服务。
An Internet-Draft referred to as "Protected Headers" [PRHDRS] has been proposed. Mechanisms described in that document are the following:
已经提出了一份称为“受保护的头文件”[PRHDRS]的互联网草案。该文件中描述的机制如下：
[...] a digest value is computed over the canonicalized version of some selected header fields. This technique resembles header protection in [RFC4871]. Then the digest value is included in a signed attribute field of a CMS signature.
[…]在某些选定标题字段的规范化版本上计算摘要值。这种技术类似于[RFC4871]中的头保护。然后，摘要值包含在CMS签名的签名属性字段中。
(Note that RFC 4871 has been obsoleted by RFC 6376.)
（请注意，RFC 4871已被RFC 6376淘汰。）
That specification doesn't address all conceivable requirements as noted below. If the protected header field has been altered, the original value cannot be determined by the recipient. In addition, the encryption service cannot provide confidentiality for fields that must remain present in the message header during transport.
该规范并未解决所有可能的要求，如下所述。如果已更改受保护的标头字段，则收件人无法确定原始值。此外，加密服务无法为传输期间必须保留在消息头中的字段提供机密性。
This document proposes a technology for securing message header fields. It's referred to as "Secure Headers". It is based on S/MIME and CMS standards. It provides security services such as data integrity, confidentiality, and non-repudiation of the sender. Secure Headers is backward compatible with other S/MIME clients. S/MIME clients who have not implemented Secure Headers technology need merely ignore specific signed attributes fields in a CMS signature (which is the default behavior).
本文档提出了一种保护消息头字段的技术。它被称为“安全头”。它基于S/MIME和CMS标准。它提供安全服务，如数据完整性、机密性和发送方的不可否认性。安全标头与其他S/MIME客户端向后兼容。未实现安全头技术的S/MIME客户端只需忽略CMS签名中的特定签名属性字段（这是默认行为）。
Secure Headers technology involves the description of a security policy. This policy MUST describe a secure message profile and list the header fields to secure. How this security policy is agreed upon or communicated is beyond the scope of this document.
安全标头技术涉及安全策略的描述。此策略必须描述安全消息配置文件，并列出要保护的头字段。本安全政策的约定或传达方式超出了本文件的范围。
Secure headers are based on the signed attributes field as defined in CMS. The details are as follows. The message header fields to be secured are integrated in a structure (SecureHeaderFields structure) that is encapsulated in the signed attributes structure of the SignerInfo object. There is only one value of HeaderFields encoded into a single SignedAttribute in a signature. See Appendix A for an example. For each header field present in the secure signature, a status can be set. Then, as described in Section 5.4 of CMS [RFC5652], the message digest calculation process computes a message digest on the content together with the signed attributes. Details of the signature generation process are in Section 4.5.1 of this document.
安全标头基于CMS中定义的签名属性字段。详情如下。要保护的消息头字段集成在一个结构（SecureHeaderFields结构）中，该结构封装在SignerInfo对象的signed attributes结构中。签名中只有一个HeaderFields值编码到单个SignedAttribute中。有关示例，请参见附录A。对于安全签名中存在的每个标头字段，可以设置状态。然后，如CMS[RFC5652]第5.4节所述，消息摘要计算过程计算内容上的消息摘要以及签名属性。签名生成过程的详细信息见本文件第4.5.1节。
Verification of secure header fields is based on the signature verification process described in CMS. At the end of this process, a comparison between the secure header fields and the corresponding message header fields is performed. If they match, the signature is valid. Otherwise, the signature is invalid. Details of the signature verification process are in Section 4.5.2 of this document.
安全标头字段的验证基于CMS中描述的签名验证过程。在该过程结束时，将执行安全标头字段与相应消息标头字段之间的比较。如果它们匹配，则签名有效。否则，签名无效。签名验证过程的详细信息见本文件第4.5.2节。
Non-conforming S/MIME clients will ignore the signed attribute containing the SecureHeaderFields structure, and only perform the verification process described in CMS. This guarantees backward compatibility.
不符合要求的S/MIME客户端将忽略包含SecureHeaderFields结构的已签名属性，并且只执行CMS中描述的验证过程。这保证了向后兼容性。
Secure headers provide security services such as data integrity, non-repudiation, and confidentiality.
安全标头提供数据完整性、不可否认性和机密性等安全服务。
For different reasons (e.g., usability, limits of IMAP [RFC3501]), encryption and decryption processes are performed by a third party. The third party that performs these processes is referred to in the Domain Security specification as a Domain Confidentiality Authority (DCA). Details of the encryption and decryption processes are in Sections 4.6.1 and 4.6.2 of this document.
出于不同的原因（例如，可用性、IMAP[RFC3501]的限制），加密和解密过程由第三方执行。执行这些过程的第三方在域安全规范中称为域保密机构（DCA）。加密和解密过程的详细信息见本文件第4.6.1节和第4.6.2节。
The architecture of Secure Headers is presented below. The MUA performs the signature generation process (C) and signature verification process (F). The DCA performs the message encryption process (D) and message decryption process (E). The encryption and decryption processes are optional.
下面介绍了安全头的体系结构。MUA执行签名生成过程（C）和签名验证过程（F）。DCA执行消息加密过程（D）和消息解密过程（E）。加密和解密过程是可选的。
A Domain B Domain
+----------------------+ +----------------------+
A Domain B Domain
+----------------------+ +----------------------+
+-----+ +-----+ +-----+ +-----+
| MUA | -------> | DCA | ----------> | DCA |--------> | MUA |
| C | | D | | E | | F |
+-----+ +-----+ +-----+ +-----+
SignedMsg EncryptedMsg SignedMsg
+-----+ +-----+ +-----+ +-----+
| MUA | -------> | DCA | ----------> | DCA |--------> | MUA |
| C | | D | | E | | F |
+-----+ +-----+ +-----+ +-----+
SignedMsg EncryptedMsg SignedMsg
Figure 1: Architecture of Secure Headers
图1：安全头的体系结构
The ASN.1 syntax [ASN1-88] of the SecureHeaderFields structure is as follows:
SecureHeaderFields结构的ASN.1语法[ASN1-88]如下所示：
SecureHeaderFields ::= SET {
canonAlgorithm Algorithm,
secHeaderFields HeaderFields }
SecureHeaderFields ::= SET {
canonAlgorithm Algorithm,
secHeaderFields HeaderFields }
id-aa-secureHeaderFieldsIdentifier OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-aa(2) secureHeaderFieldsIdentifier(55) }
id-aa-secureHeaderFieldsIdentifier OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-aa(2) secureHeaderFieldsIdentifier(55) }
Algorithm ::= ENUMERATED {
canonAlgorithmSimple(0),
canonAlgorithmRelaxed(1) }
Algorithm ::= ENUMERATED {
canonAlgorithmSimple(0),
canonAlgorithmRelaxed(1) }
HeaderFields ::= SEQUENCE SIZE (1..MAX) OF HeaderField
HeaderFields ::= SEQUENCE SIZE (1..MAX) OF HeaderField
HeaderField ::= SEQUENCE {
field-Name HeaderFieldName,
field-Value HeaderFieldValue,
field-Status HeaderFieldStatus DEFAULT duplicated }
HeaderField ::= SEQUENCE {
field-Name HeaderFieldName,
field-Value HeaderFieldValue,
field-Status HeaderFieldStatus DEFAULT duplicated }
HeaderFieldName ::= VisibleString (FROM (ALL EXCEPT (":")))
-- This description matches the description of
-- field name in Sections 2.2 and 3.6.8 of RFC 5322
HeaderFieldName ::= VisibleString (FROM (ALL EXCEPT (":")))
-- This description matches the description of
-- field name in Sections 2.2 and 3.6.8 of RFC 5322
HeaderFieldValue ::= UTF8String
-- This description matches the description of
-- field body in Section 2.2 of RFC 5322 as
-- extended by Section 3.1 of RFC 6532.
HeaderFieldValue ::= UTF8String
-- This description matches the description of
-- field body in Section 2.2 of RFC 5322 as
-- extended by Section 3.1 of RFC 6532.
HeaderFieldStatus ::= INTEGER {
duplicated(0), deleted(1), modified(2) }
HeaderFieldStatus ::= INTEGER {
duplicated(0), deleted(1), modified(2) }
This specification requires MUA security capabilities in order to process well-formed headers, as specified in IMF. Notice that it includes long header fields and folded header fields.
本规范要求MUA安全功能，以便处理格式良好的报头，如IMF中所述。请注意，它包括长标题字段和折叠标题字段。
During a message transfer through a messaging system, some components might modify headers (i.e., adding or deleting space, changing or lowercase or uppercase). This might lead to a comparison mismatch of header fields. This emphasizes the need of a conversion process in order to transform data to their canonical form. This process is named the canonicalization process.
在通过消息传递系统传输消息的过程中，某些组件可能会修改消息头（即，添加或删除空格、更改大小写或大写）。这可能会导致标题字段的比较不匹配。这强调了转换过程的需要，以便将数据转换为其规范形式。这个过程被称为规范化过程。
Two canonicalization algorithms are considered here, according to Section 3.4 of the DKIM specification [RFC6376]. The "simple" algorithm doesn't allow any modification, whereas the "relaxed" algorithm accepts slight modifications like space replacement or line reformatting. Given the scope of this document, canonicalization mechanisms only involve header fields.
根据DKIM规范[RFC6376]第3.4节，这里考虑两种规范化算法。“简单”算法不允许任何修改，而“松弛”算法接受轻微修改，如空间替换或行重新格式化。鉴于本文档的范围，规范化机制只涉及头字段。
Implementations SHOULD use the "relaxed" algorithm to promote interoperability with non-conforming SMTP products.
实施应使用“宽松”算法来促进与不合格SMTP产品的互操作性。
Header field statuses are necessary to provide a confidentiality service for message headers. In this specification, the confidentiality of header fields is provided by the DCA. This point is described in Section 4. The DCA performs the message encryption process and message decryption process; these processes are described in detail in Sections 4.6.1 and 4.6.2. Although header field statuses are embedded in the signature, the signature processes
标头字段状态是为消息标头提供保密服务所必需的。在本规范中，头字段的机密性由DCA提供。这一点在第4节中描述。DCA执行消息加密处理和消息解密处理；第4.6.1节和第4.6.2节详细描述了这些过程。虽然签名中嵌入了标题字段状态，但签名过程
(generation and verification) ignore them. The header field status defaults to "duplicated". If the header field is confidential, the header field status MUST be either "deleted" or "modified".
（生成和验证）忽略它们。标题字段状态默认为“重复”。如果标题字段为机密字段，则标题字段状态必须为“已删除”或“已修改”。
During the signature generation process, the sender's MUA MUST embed the SecureHeaderFields structure in the signed attributes, as described in CMS. The SecureHeaderFields structure MUST include a canonicalization algorithm.
在签名生成过程中，发送方的MUA必须将SecureHeaderFields结构嵌入签名属性中，如CMS中所述。SecureHeaderFields结构必须包括规范化算法。
The sender's MUA MUST have a list of header fields to secure, statuses, and a canonicalization algorithm, as defined by the security policy.
发送方的MUA必须具有要保护的标题字段列表、状态和规范化算法，如安全策略所定义。
Header fields (names and values) embedded in signed attributes MUST be the same as those included in the initial message.
嵌入在签名属性中的头字段（名称和值）必须与初始消息中包含的头字段相同。
If different headers share the same name, all instances MUST be included in the SecureHeaderFields structure.
如果不同的头共享相同的名称，则所有实例都必须包含在SecureHeaderFields结构中。
If multiple signatures are used, as explained in the CMS and Multiple Signer [RFC4853] specifications, the SecureHeaderFields structure MUST be the same in each SignerInfos object.
如CMS和多签名者[RFC4853]规范所述，如果使用多个签名，则每个SignerInfos对象中的SecureHeaderFields结构必须相同。
If a header field is present and its value is empty, HeaderFieldValue MUST have a zero-length field-Value.
如果存在标头字段且其值为空，则HeaderFieldValue必须具有零长度字段值。
Considering secure header mechanisms, the signature generation process MUST perform the following steps:
考虑到安全标头机制，签名生成过程必须执行以下步骤：
1) Select the relevant header fields to secure. This subset of headers is defined according the security policy.
1) 选择要保护的相关标题字段。此标头子集是根据安全策略定义的。
2) Apply the canonicalization algorithm for each selected header field.
2) 为每个选定的标题字段应用规范化算法。
3) Complete the following fields in the SecureHeaderFields structure according to the initial message: HeaderFieldName, HeaderFieldValue, and HeaderFieldStatus.
3) 根据初始消息填写SecureHeaderFields结构中的以下字段：HeaderFieldName、HeaderFieldValue和HeaderFieldStatus。
4) Complete the algorithm field according to the canonicalization algorithm configured.
4) 根据配置的规范化算法填写算法字段。
5) Embed the SecureHeaderFields structure in the signed attributes of the SignerInfos object.
5) 将SecureHeaderFields结构嵌入SignerInfos对象的已签名属性中。
6) Compute the signature generation process as described in Section 5.5 of CMS [RFC5652].
6) 计算CMS[RFC5652]第5.5节中所述的签名生成过程。
During the signature verification process, the receiver's MUA compares header fields embedded in the SecureHeaderFields structure with those present in the message. For this purpose, it uses the canonicalization algorithm identified in the signed attributes. If a mismatch appears during the comparison process, the receiver's MUA MUST invalidate the signature. The MUA MUST display information on the validity of each header field. It MUST also display the values embedded in the signature.
在签名验证过程中，接收方的MUA将SecureHeaderFields结构中嵌入的头字段与消息中存在的头字段进行比较。为此，它使用签名属性中标识的规范化算法。如果在比较过程中出现不匹配，则接收器的MUA必须使签名无效。MUA必须显示每个标题字段的有效性信息。它还必须显示嵌入在签名中的值。
The receiver's MUA MUST know the list of mandatory header fields in order to verify their presence in the message. If a header field defined in a message is in the secure header list, it MUST be included in the SecureHeaderFields structure. Otherwise, the receiver's MUA MUST warn the user that a non-secure header is present.
接收方的MUA必须知道强制标头字段的列表，以便验证其在消息中的存在。如果消息中定义的标头字段位于安全标头列表中，则必须将其包含在SecureHeaderFields结构中。否则，接收方的MUA必须警告用户存在不安全的报头。
Considering secure header mechanisms, the signature verification process MUST perform the following steps:
考虑到安全标头机制，签名验证过程必须执行以下步骤：
1) Execute the signature verification process as described Section 5.6 of CMS [RFC5652]. If the signature appears to be invalid, the process ends. Otherwise, the process continues.
1) 执行CMS[RFC5652]第5.6节所述的签名验证过程。如果签名无效，则过程结束。否则，该过程将继续。
2) Read the type of canonicalization algorithm specified in the SecureHeaderFields structure.
2) 读取SecureHeaderFields结构中指定的规范化算法类型。
3) For each field present in the signature, find the matching header in the message. If there is no matching header, the verification process MUST warn the user, specifying the missing header name. The signature is tagged as invalid. Note that any header fields encrypted as per Section 4.6 (i.e., status of "deleted" or "modified") have been are already restored by the DCA when the signature verification process is performed by the MUA.
3) 对于签名中的每个字段，在消息中查找匹配的标头。如果没有匹配的头，验证过程必须警告用户，指定缺少的头名称。签名被标记为无效。请注意，当MUA执行签名验证过程时，DCA已恢复根据第4.6节加密的任何标题字段（即“已删除”或“已修改”状态）。
4) Compute the canonicalization algorithm for each header field value in the message. If the "simple" algorithm is used, the steps described in Section 3.4.1 of DKIM [RFC6376] are performed. If the relaxed algorithm is used, the steps described in Section 3.4.2 of DKIM [RFC6376] are performed.
4) 计算消息中每个标头字段值的规范化算法。如果使用“简单”算法，则执行DKIM[RFC6376]第3.4.1节中描述的步骤。如果使用松弛算法，则执行DKIM[RFC6376]第3.4.2节中描述的步骤。
5) For each field, compare the value stored in the SecureHeaderFields structure with the value returned by the canonicalization algorithm. If the values don't match, the verification process MUST warn the user. This warning MUST mention mismatching fields. The signature is tagged as invalid. If all the comparisons succeed, the verification process MUST also notify the user (i.e., using an appropriate icon).
5) 对于每个字段，将存储在SecureHeaderFields结构中的值与规范化算法返回的值进行比较。如果值不匹配，验证过程必须警告用户。此警告必须提及不匹配的字段。签名被标记为无效。如果所有比较都成功，验证过程还必须通知用户（即使用适当的图标）。
6) Verify that no secure header has been added to the message header, given the initial fields. If an extra header field has been added, the verification process MUST warn the user. This warning MUST mention extra fields. The signature is tagged as invalid. This step is only performed if the sender and the recipient share the same security policy.
6) 确认在给定初始字段的情况下，没有向消息头添加任何安全头。如果添加了额外的标题字段，则验证过程必须警告用户。此警告必须提及额外字段。签名被标记为无效。仅当发件人和收件人共享相同的安全策略时，才执行此步骤。
7) Verify that each mandatory header in the security policy and present in the message is also embedded in the SecureHeaderFields structure. If such headers are missing, the verification process MUST warn the user and indicate the names of the missing headers.
7) 验证安全策略中以及消息中存在的每个必填标头是否也嵌入到SecureHeaderFields结构中。如果缺少此类头，验证过程必须警告用户并指明缺少头的名称。
The MUA MUST display the properties of each secure header field (name, value, and status) and the canonicalization algorithm used.
MUA必须显示每个安全头字段（名称、值和状态）的属性以及使用的规范化算法。
Encryption and decryption operations are not performed by MUAs. This is mainly justified by limitations of existing email delivery protocols, for example, IMAP. The solution developed here relies on concepts explained in Section 4 of the Domain Security specification [RFC3183]. A fundamental component of the architecture is the Domain Confidentiality Authority (DCA). Its purpose is to encrypt and decrypt messages instead of that being performed by senders and receivers (respectively).
MUA不执行加密和解密操作。这主要是因为现有电子邮件传递协议（例如IMAP）的局限性。这里开发的解决方案依赖于域安全规范[RFC3183]第4节中解释的概念。该体系结构的一个基本组件是域保密机构（DCA）。它的目的是加密和解密消息，而不是由发送方和接收方（分别）执行。
All the computations presented in this section MUST be performed only if the following conditions are verified:
只有在验证以下条件时，才能执行本节中的所有计算：
- The content to be encrypted MUST consist of a signed message (application/pkcs7-mime with SignedData, or multipart/signed) as shown in Section 3.4 of the S/MIME specification [RFC5751].
- 如S/mime规范[RFC5751]第3.4节所示，要加密的内容必须包含签名消息（带签名数据的应用程序/pkcs7 mime，或多部分/签名）。
- A SecureHeaderFields structure MUST be included in the signedAttrs field of the SignerInfo object of the signature.
- 签名的SignerInfo对象的signedAttrs字段中必须包含SecureHeaderFields结构。
All the mechanisms described below MUST start at the beginning of the encryption process, as explained in CMS. They are performed by the sender's DCA. For extraction of the field status, the following steps MUST be performed for each field included in the SecureHeaderFields structure:
下面描述的所有机制必须在加密过程开始时启动，如CMS中所述。它们由发送方的DCA执行。要提取字段状态，必须对SecureHeaderFields结构中包含的每个字段执行以下步骤：
1. If the status is "duplicated", the field is left at its existing value.
1. 如果状态为“复制”，则该字段保留其现有值。
2. If the status is "deleted", the header field (name and value) is removed from the message. Mandatory header fields specified in [RFC5322] MUST be kept.
2. 如果状态为“已删除”，则从消息中删除标题字段（名称和值）。必须保留[RFC5322]中指定的必填标头字段。
3. If the status is "modified", the header value is replaced by a new value, as configured in the DCA.
3. 如果状态为“修改”，则标题值将替换为DCA中配置的新值。
All the computations presented in this section MUST be performed only if the following conditions are verified:
只有在验证以下条件时，才能执行本节中的所有计算：
- The decrypted content MUST consist of a signature object or a multipart object, where one part is a detached signature, as shown in Section 3.4 of the S/MIME specification [RFC5751].
- 解密内容必须由签名对象或多部分对象组成，其中一部分是分离的签名，如S/MIME规范[RFC5751]第3.4节所示。
- A SecureHeaderFields structure MUST be included in the SignerInfo object of the signature.
- 签名的SignerInfo对象中必须包含SecureHeaderFields结构。
All the mechanisms described below MUST start at the end of the decryption process, as explained in CMS. They are executed by the receiver's DCA. The following steps MUST be performed for each field included in the SecureHeaderFields structure:
下面描述的所有机制必须在解密过程结束时启动，如CMS中所述。它们由接收方的DCA执行。必须对SecureHeaderFields结构中包含的每个字段执行以下步骤：
1. If the status is "duplicated", the field is left at its existing value.
1. 如果状态为“复制”，则该字段保留其现有值。
2. If the status is "deleted", the DCA MUST write a header field (name and value) in the message. This header MUST be compliant with the information embedded in the signature.
2. 如果状态为“已删除”，DCA必须在消息中写入标题字段（名称和值）。此标题必须与签名中嵌入的信息一致。
3. If the status is "modified", the DCA MUST rewrite a header field in the message. This header MUST be compliant with the SecureHeaderFields structure.
3. 如果状态为“已修改”，DCA必须重写消息中的标题字段。此标头必须符合SecureHeaderFields结构。
Secure Headers mechanisms MAY be used with triple wrapping, as described in Enhanced Security Services (ESS) [RFC2634]. In this case, a SecureHeaderFields structure MAY be present in the inner signature, the outer signature, or both. In the last case, the two SecureHeaderFields structures MAY differ. One MAY consider the encapsulation of a header field in the inner signature in order to satisfy confidentiality needs. On the contrary, an outer signature encapsulation MAY help for delivery purposes. The sender's MUA and receiver's MUA must have a security policy for triple wrapping. This security policy MUST be composed of two parts -- one for the inner signature and the other for the outer signature.
如增强安全服务（ESS）[RFC2634]中所述，安全头机制可与三重包装一起使用。在这种情况下，SecureHeaderFields结构可能存在于内部签名、外部签名或两者中。在最后一种情况下，两个SecureHeaderFields结构可能不同。可以考虑在内部签名中封装报头字段，以满足机密性需求。相反，外部签名封装可能有助于交付目的。发送方的MUA和接收方的MUA必须具有三重包装的安全策略。此安全策略必须由两部分组成——一部分用于内部签名，另一部分用于外部签名。
Some security gateways sign or verify messages that pass through them. Compliant gateways MUST apply the process described in Section 4.5.
一些安全网关对通过它们的消息进行签名或验证。符合要求的网关必须采用第4.5节所述的流程。
For noncompliant gateways, the presence of a SecureHeaderFields structure does not change their behavior.
对于不兼容的网关，SecureHeaderFields结构的存在不会改变它们的行为。
In some case, gateways MUST generate a new signature or insert signerInfos into the signedData block. The format of signatures generated by gateways is outside the scope of this document.
在某些情况下，网关必须生成新签名或将signerInfos插入signedData块。网关生成的签名格式不在本文档范围内。
This specification describes an extension of the S/MIME standard. It provides message header integrity, non-repudiation, and confidentiality. The signature and encryption processes are complementary. However, according to the security policy, only the signature mechanism is applicable. In this case, the signature process is implemented between MUAs. The encryption process requires signed messages with the Secure Headers extension. If required, the encryption process is implemented by DCAs.
本规范描述了S/MIME标准的扩展。它提供消息头完整性、不可否认性和机密性。签名和加密过程是互补的。然而，根据安全策略，只有签名机制才适用。在这种情况下，签名过程在MUA之间实现。加密过程需要具有安全标头扩展名的签名消息。如果需要，加密过程由DCAs实现。
This specification doesn't address end-to-end confidentiality for message header fields. Messages sent and received by MUAs could be transmitted as plaintext. In order to avoid interception, the use of TLS is recommended between MUAs and DCAs (uplink and downlink). Another solution might be the use of S/MIME between MUAs and DCAs in the same domain.
此规范不解决消息头字段的端到端机密性问题。MUAs发送和接收的消息可以以明文形式传输。为了避免拦截，建议在MUA和DCA（上行链路和下行链路）之间使用TLS。另一种解决方案可能是在同一域中的MUA和DCA之间使用S/MIME。
For the header field confidentiality mechanism to be effective, all DCAs supporting confidentiality must support Secure Headers processing. Otherwise, there is a risk that headers are not obscured
为了使标头字段机密性机制有效，所有支持机密性的DCA必须支持安全的标头处理。否则，可能会出现标题未被遮挡的风险
upon encryption or not restored upon decryption. In the former case, confidentiality of the header fields is compromised. In the latter case, the integrity of the headers will appear to be compromised.
加密或解密时不恢复。在前一种情况下，报头字段的机密性受到损害。在后一种情况下，报头的完整性将受到损害。
IANA has registered value 65, mod-sMimeSecureHeadersV1, in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry.
IANA在“S/MIME模块标识符的SMI安全性（1.2.840.113549.1.9.16.0）”注册表中注册了值65，mod-sMimeSecureHeadersV1。
IANA has also registered value 55, id-aa-secureHeaderFieldsIdentifier, in the "SMI Security for S/MIME Attributes (1.2.840.113549.1.9.16.2)" registry. This value will be used to identify an authenticated attribute carried within a CMS wrapper [RFC5652]. This attribute OID appears in Section 4.1 and again in the reference definition in Appendix A.
IANA还在“S/MIME属性的SMI安全性（1.2.840.113549.1.9.16.2）”注册表中注册了值55，id aa SecureHeaderFieldIdentifier。此值将用于标识CMS包装器[RFC5652]中携带的经过身份验证的属性。该属性OID出现在第4.1节和附录A的参考定义中。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999, <http://www.rfc-editor.org/info/rfc2634>.
[RFC2634]Hoffman，P.，Ed.，“S/MIME的增强安全服务”，RFC 2634，1999年6月<http://www.rfc-editor.org/info/rfc2634>.
[RFC4853] Housley, R., "Cryptographic Message Syntax (CMS) Multiple Signer Clarification", RFC 4853, April 2007, <http://www.rfc-editor.org/info/rfc4853>.
[RFC4853]Housley，R.，“加密消息语法（CMS）多签名者澄清”，RFC 4853，2007年4月<http://www.rfc-editor.org/info/rfc4853>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[RFC5322]Resnick，P.，Ed.，“互联网信息格式”，RFC5222008年10月<http://www.rfc-editor.org/info/rfc5322>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009, <http://www.rfc-editor.org/info/rfc5652>.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月<http://www.rfc-editor.org/info/rfc5652>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, September 2011, <http://www.rfc-editor.org/info/rfc6376>.
[RFC6376]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，STD 76，RFC 63762011年9月<http://www.rfc-editor.org/info/rfc6376>.
[ASN1-88] CCITT, Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988.
[ASN1-88]CCITT，建议X.208：抽象语法符号1规范（ASN.1），1988年。
[PRHDRS] Liao, L. and J. Schwenk, "Header Protection for S/MIME", draft-liao-smimeheaderprotect-05, Work in Progress, June 2009.
[PRHDRS]Liao，L.和J.Schwenk，“S/MIME的头保护”，草稿-Liao-smimeheaderprotect-05，正在进行的工作，2009年6月。
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999, <http://www.rfc-editor.org/info/rfc2595>.
[RFC2595]Newman，C.，“将TLS与IMAP、POP3和ACAP一起使用”，RFC2595，1999年6月<http://www.rfc-editor.org/info/rfc2595>.
[RFC3183] Dean, T. and W. Ottaway, "Domain Security Services using S/MIME", RFC 3183, October 2001, <http://www.rfc-editor.org/info/rfc3183>.
[RFC3183]Dean，T.和W.Ottaway，“使用S/MIME的域安全服务”，RFC 31832001年10月<http://www.rfc-editor.org/info/rfc3183>.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002, <http://www.rfc-editor.org/info/rfc3207>.
[RFC3207]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC 3207，2002年2月<http://www.rfc-editor.org/info/rfc3207>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003, <http://www.rfc-editor.org/info/rfc3501>.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月<http://www.rfc-editor.org/info/rfc3501>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月<http://www.rfc-editor.org/info/rfc5321>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009, <http://www.rfc-editor.org/info/rfc5598>.
[RFC5598]Crocker，D.，“互联网邮件体系结构”，RFC 55982009年7月<http://www.rfc-editor.org/info/rfc5598>.
[RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling", RFC 5750, January 2010, <http://www.rfc-editor.org/info/rfc5750>.
[RFC5750]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2证书处理”，RFC 57502010年1月<http://www.rfc-editor.org/info/rfc5750>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010, <http://www.rfc-editor.org/info/rfc5751>.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月<http://www.rfc-editor.org/info/rfc5751>.
Note: The ASN.1 module contained herein uses the 1988 version of ASN.1 notation [ASN1-88] for the purposes of alignment with the existing S/MIME specifications. The SecureHeaderFields structure is defined as follows:
注：为了与现有S/MIME规范保持一致，本文包含的ASN.1模块使用了1988年版本的ASN.1符号[ASN1-88]。SecureHeaderFields结构定义如下：
mod-SMimeSecureHeadersV1
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) secure-headers-v1(65) }
mod-SMimeSecureHeadersV1
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) secure-headers-v1(65) }
DEFINITIONS IMPLICIT TAGS ::=
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
开始
IMPORTS
进口
id-aa
FROM SecureMimeMessageV3dot1
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0)
msg-v3dot1(21) };
id-aa
FROM SecureMimeMessageV3dot1
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0)
msg-v3dot1(21) };
-- id-aa is the arc with all new authenticated and
-- unauthenticated attributes produced by the S/MIME
-- Working Group
-- id-aa is the arc with all new authenticated and
-- unauthenticated attributes produced by the S/MIME
-- Working Group
id-aa-secureHeaderFieldsIdentifier OBJECT IDENTIFIER ::= {
id-aa secure-headers(55) }
id-aa-secureHeaderFieldsIdentifier OBJECT IDENTIFIER ::= {
id-aa secure-headers(55) }
SecureHeaderFields ::= SET {
canonAlgorithm Algorithm,
secHeaderFields HeaderFields }
SecureHeaderFields ::= SET {
canonAlgorithm Algorithm,
secHeaderFields HeaderFields }
Algorithm ::= ENUMERATED {
canonAlgorithmSimple(0),
canonAlgorithmRelaxed(1) }
Algorithm ::= ENUMERATED {
canonAlgorithmSimple(0),
canonAlgorithmRelaxed(1) }
HeaderFields ::= SEQUENCE SIZE (1..MAX) OF HeaderField
HeaderFields ::= SEQUENCE SIZE (1..MAX) OF HeaderField
HeaderField ::= SEQUENCE {
field-Name HeaderFieldName,
field-Value HeaderFieldValue,
field-Status HeaderFieldStatus DEFAULT duplicated }
HeaderField ::= SEQUENCE {
field-Name HeaderFieldName,
field-Value HeaderFieldValue,
field-Status HeaderFieldStatus DEFAULT duplicated }
HeaderFieldName ::= VisibleString (FROM (ALL EXCEPT (":")))
-- This description matches with the description of
-- field name in the Sections 2.2 and 3.6.8 of RFC 5322
HeaderFieldName ::= VisibleString (FROM (ALL EXCEPT (":")))
-- This description matches with the description of
-- field name in the Sections 2.2 and 3.6.8 of RFC 5322
HeaderFieldValue ::= UTF8String
-- This description matches with the description of
-- field body in the Section 2.2 of RFC 5322 as
-- extended by Section 3.1 of RFC 6532.
HeaderFieldValue ::= UTF8String
-- This description matches with the description of
-- field body in the Section 2.2 of RFC 5322 as
-- extended by Section 3.1 of RFC 6532.
HeaderFieldStatus ::= INTEGER {
duplicated(0), deleted(1), modified(2) }
HeaderFieldStatus ::= INTEGER {
duplicated(0), deleted(1), modified(2) }
END
终止
In the following example, the header fields subject, x-ximf-primary-precedence, and x-ximf-correspondance-type are secured and integrated in a SecureHeaderFields structure. This example should produce a valid signature.
在下面的示例中，标题字段subject、x-ximf-primary-preference和x-ximf-correspondance-type是安全的，并集成在SecureHeaderFields结构中。此示例应生成有效的签名。
Extract from the message header fields:
从消息头字段中提取：
From: John Doe <jdoe@example.com>
To: Mary Smith <mary@example.com>
subject: This is a test of Ext.
x-ximf-primary-precedence: priority
x-ximf-correspondance-type: official
From: John Doe <jdoe@example.com>
To: Mary Smith <mary@example.com>
subject: This is a test of Ext.
x-ximf-primary-precedence: priority
x-ximf-correspondance-type: official
The SecureHeaderFields structure extracted from the signature:
从签名中提取的SecureHeaderFields结构：
2286 150: SEQUENCE {
2289 11: OBJECT IDENTIFIER '1 2 840 113549 1 9 16 2 80'
2302 134: SET {
2305 131: SET {
2308 4: ENUMERATED 1
2314 123: SEQUENCE {
2316 40: SEQUENCE {
2318 25: VisibleString 'x-ximf-primary-precedence'
2345 8: UTF8String 'priority'
2355 1: INTEGER 0
: }
2358 41: SEQUENCE {
2360 26: VisibleString 'x-ximf-correspondance-type'
2388 8: UTF8String 'official'
2398 1: INTEGER 0
: }
2401 36: SEQUENCE {
2403 7: VisibleString 'subject'
2412 22: UTF8String 'This is a test of Ext.'
2436 1: INTEGER 0
: }
: }
: }
: }
: }
2286 150: SEQUENCE {
2289 11: OBJECT IDENTIFIER '1 2 840 113549 1 9 16 2 80'
2302 134: SET {
2305 131: SET {
2308 4: ENUMERATED 1
2314 123: SEQUENCE {
2316 40: SEQUENCE {
2318 25: VisibleString 'x-ximf-primary-precedence'
2345 8: UTF8String 'priority'
2355 1: INTEGER 0
: }
2358 41: SEQUENCE {
2360 26: VisibleString 'x-ximf-correspondance-type'
2388 8: UTF8String 'official'
2398 1: INTEGER 0
: }
2401 36: SEQUENCE {
2403 7: VisibleString 'subject'
2412 22: UTF8String 'This is a test of Ext.'
2436 1: INTEGER 0
: }
: }
: }
: }
: }
The example is displayed as an output of Peter Gutmann's "dumpasn1" program.
该示例显示为Peter Gutmann的“dumpasn1”程序的输出。
OID used in this example is nonofficial.
本例中使用的OID是非官方的。
Acknowledgements
致谢
The authors would like to thank Jim Schaad, Alexey Melnikov, Damien Roque, Thibault Cassan, William Ottaway, and Sean Turner who kindly provided reviews of the document and/or suggestions for improvement. As always, all errors and omissions are the responsibility of the authors.
作者要感谢Jim Schaad、Alexey Melnikov、Damien Roque、Thibault Cassan、William Ottaway和Sean Turner，他们友好地提供了文件审查和/或改进建议。一如既往，所有错误和遗漏均由作者负责。
Authors' Addresses
作者地址
Laurent CAILLEUX DGA MI BP 7 35998 RENNES CEDEX 9 France
劳伦特·凯勒英国石油公司DGA 7 35998雷恩塞德斯9法国
EMail: laurent.cailleux@intradef.gouv.fr
EMail: laurent.cailleux@intradef.gouv.fr
Chris Bonatti IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 United States
Chris Bonatti IECA，Inc.美国弗吉尼亚州费尔法克斯市努特利街3057号106室，邮编22031
EMail: bonatti252@ieca.com
EMail: bonatti252@ieca.com