[要約] RFC 7508は、S/MIMEを使用してヘッダーフィールドを安全に保護するためのガイドラインです。このRFCの目的は、電子メールのヘッダーフィールドのセキュリティを向上させることです。
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'.
このドキュメントでは、RFC 5322で定義されたメッセージヘッダーフィールドを保護するためにS / MIMEプロトコルを拡張する方法について説明します。このテクノロジーは、データの整合性、否認防止、機密性などのセキュリティサービスを提供します。この拡張機能は「セキュアヘッダー」と呼ばれます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
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 Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
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は、ヘッダーフィールドを保護するための代替ソリューションを提供します。「S / MIMEセキュリティサービスをヘッダーフィールドに適用するために、送信クライアントは完全なMIMEメッセージをmessage / rfc822ラッパーでラップしてもよい（MAY）」。ただし、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 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.
他のいくつかのセキュリティ仕様はS / MIME機能を補足しますが、このドキュメントのターゲット要件セットに対処できません。そのような他のセキュリティ仕様には、DomainKeys Identified Mail（DKIM）[RFC6376]、STARTTLS [RFC3207]、IMAPを使用したTLS [RFC2595]、および「保護ヘッダー」[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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The terms Message User Agent (MUA), Message Submission Agent (MSA), and Message Transfer Agent (MTA) are defined in the email architecture document [RFC5598].
メッセージユーザーエージェント（MUA）、メッセージ送信エージェント（MSA）、およびメッセージ転送エージェント（MTA）という用語は、電子メールアーキテクチャドキュメント[RFC5598]で定義されています。
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.
エンドツーエンドのインターネットメール交換は、メッセージの発信者と受信者の間で実行されます。
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:
セキュアヘッダーテクノロジーは、メッセージヘッダーに対する機密性サービスを提供するために必要なヘッダーフィールドステータスを使用します。次の3つの用語は、フィールドのステータスを説明するために使用されます。
- 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]での使用法を考慮して、このドキュメント全体で使用されています。この用語には多くの手荷物が伴うこと、およびその適切な意味と使用法については意見の相違があることが認識されています。ただし、このドキュメントのコンテキストでは、この用語は、準拠する実装が提供できる可能性のあるセキュリティサービスの1つのセットを指すにすぎません。このドキュメントでは、否認防止に関する規範的な要件は指定されていません。
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]とインターネットメッセージフォーマット（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.
[...]送信クライアントは、これらのヘッダーフィールドにS / MIMEセキュリティサービスを適用するために、完全なMIMEメッセージをmessage / rfc822ラッパーでラップしてもよい（MAY）。この「内部」ヘッダーと保護されていない「外部」ヘッダーをどのように提示するかは、受信側のクライアントが決定します。
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.
受信側のエージェントは、メールメッセージのFromまたはSenderヘッダーのアドレスが、メールアドレスが証明書に存在する場合、署名者の証明書に存在する場合、インターネットメールアドレスと一致することを確認する必要があります。
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.
STARTTLSおよびIMAP付き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:
「Protected Headers」[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で定義されている署名済み属性フィールドに基づいています。詳細は以下の通りです。保護されるメッセージヘッダーフィールドは、SignerInfoオブジェクトの署名済み属性構造にカプセル化された構造（SecureHeaderFields構造）に統合されます。署名の単一のSignedAttributeにエンコードされたHeaderFieldsの値は1つだけです。例については、付録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
+----------------------+ +----------------------+
+-----+ +-----+ +-----+ +-----+
| 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 }
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) }
HeaderFields ::= SEQUENCE SIZE (1..MAX) OF HeaderField
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
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) }
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.
この仕様では、IMFで指定されているように、整形式のヘッダーを処理するためにMUAセキュリティ機能が必要です。長いヘッダーフィールドと折りたたまれたヘッダーフィールドが含まれていることに注意してください。
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に従って、ここでは2つの正規化アルゴリズムが検討されています。 「シンプルな」アルゴリズムでは変更を許可しませんが、「リラックス」アルゴリズムではスペースの置換や行の再フォーマットなどのわずかな変更を受け入れます。このドキュメントの範囲を考えると、正規化メカニズムはヘッダーフィールドのみを含みます。
Implementations SHOULD use the "relaxed" algorithm to promote interoperability with non-conforming SMTP products.
実装では、「リラックス」アルゴリズムを使用して、非準拠のSMTP製品との相互運用性を促進する必要があります（SHOULD）。
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 (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".
ヘッダーフィールドのステータスは、メッセージヘッダーの機密性サービスを提供するために必要です。この仕様では、ヘッダーフィールドの機密性はDCAによって提供されます。この点については、セクション4で説明します。DCAは、メッセージの暗号化プロセスとメッセージの復号化プロセスを実行します。これらのプロセスについては、セクション4.6.1および4.6.2で詳しく説明しています。ヘッダーフィールドのステータスは署名に埋め込まれていますが、署名プロセス（生成および検証）では無視されます。ヘッダーフィールドのステータスのデフォルトは「重複」です。ヘッダーフィールドが機密情報である場合、ヘッダーフィールドのステータスは「削除済み」または「変更済み」でなければなりません。
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は、CMSで説明されているように、SecureHeaderFields構造を署名済み属性に埋め込む必要があります。 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]仕様で説明されているように、複数の署名が使用される場合、SecureHeaderFields構造は各SignerInfosオブジェクトで同じでなければなりません。
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）署名に含まれる各フィールドについて、メッセージで一致するヘッダーを見つけます。一致するヘッダーがない場合、検証プロセスは欠落しているヘッダー名を指定してユーザーに警告する必要があります。署名に無効のタグが付けられています。セクション4.6に従って暗号化されたヘッダーフィールド（つまり、「削除済み」または「変更済み」のステータス）は、MUAによって署名検証プロセスが実行されたときに、DCAによってすでに復元されていることに注意してください。
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に示すように、署名付きメッセージ（SignedDataを含むapplication / pkcs7-mime、またはmultipart / signed）で構成する必要があります。
- A SecureHeaderFields structure MUST be included in the signedAttrs field of the SignerInfo object of the signature.
- SecureHeaderFields構造は、署名のSignerInfoオブジェクトのsignedAttrsフィールドに含まれている必要があります。
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]で指定された必須のヘッダーフィールドは保持されなければなりません（MUST）。
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.
- SecureHeaderFields構造は、署名のSignerInfoオブジェクトに含まれている必要があります。
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.
セキュアヘッダーメカニズムは、Enhanced Security Services（ESS）[RFC2634]で説明されているように、トリプルラッピングと共に使用される場合があります。この場合、SecureHeaderFields構造体が内部署名、外部署名、またはその両方に存在する場合があります。最後のケースでは、2つのSecureHeaderFields構造が異なる場合があります。機密性のニーズを満たすために、内部署名のヘッダーフィールドのカプセル化を検討できます。それどころか、外部署名カプセル化は、配信の目的で役立つ場合があります。送信者のMUAと受信者のMUAには、トリプルラップのセキュリティポリシーが必要です。このセキュリティポリシーは、2つの部分で構成される必要があります。1つは内部署名用で、もう1つは外部署名用です。
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.
場合によっては、ゲートウェイは新しい署名を生成するか、signedInfoブロックを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間で実装されます。暗号化プロセスでは、Secure Headers拡張を使用した署名付きメッセージが必要です。必要に応じて、暗号化プロセスはDCAによって実装されます。
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.
この仕様では、メッセージヘッダーフィールドのエンドツーエンドの機密性は扱いません。 MUAによって送受信されるメッセージは、プレーンテキストとして送信できます。傍受を回避するために、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 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.
ヘッダーフィールドの機密性メカニズムを有効にするには、機密性をサポートするすべてのDCAがセキュアヘッダー処理をサポートする必要があります。そうしないと、暗号化の際にヘッダーが不明瞭になったり、復号化の際にヘッダーが復元されなかったりするリスクがあります。前者の場合、ヘッダーフィールドの機密性が損なわれます。後者の場合、ヘッダーの整合性が損なわれているように見えます。
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は、「SMI Security for S / MIME Module Identifier（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は、値55、id-aa-secureHeaderFieldsIdentifierを「S / MIME属性のSMIセキュリティ（1.2.840.113549.1.9.16.2）」レジストリに登録しています。この値は、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。、「Enhanced Security Services for 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。、「Cryptographic Message Syntax（CMS）Multiple Signer Clarification」、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。、編、「インターネットメッセージ形式」、RFC 5322、2008年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。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、2009年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。、and M. Kucherawy、Ed。、 "DomainKeys Identified Mail（DKIM）Signatures"、STD 76、RFC 6376、September 2011、<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、Recommendation X.208：Abstract Syntax Notation One（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のヘッダー保護」、draft-liao-smimeheaderprotect-05、Work in Progress、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。、「Using TLS with IMAP、POP3 and ACAP」、RFC 2595、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 3183、2001年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。、「Secure SMTP over Transport Layer Securityの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 3501、2003年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。、「Simple Mail Transfer Protocol」、RFC 5321、2008年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。、「Internet Mail Architecture」、RFC 5598、2009年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、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Certificate Handling」、RFC 5750、2010年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、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、2010年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:
注：ここに含まれるASN.1モジュールは、既存のS / MIME仕様との整合を目的として、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) }
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 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) }
SecureHeaderFields ::= SET {
canonAlgorithm Algorithm,
secHeaderFields HeaderFields }
Algorithm ::= ENUMERATED {
canonAlgorithmSimple(0),
canonAlgorithmRelaxed(1) }
HeaderFields ::= SEQUENCE SIZE (1..MAX) OF HeaderField
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
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) }
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.
次の例では、ヘッダーフィールドの件名、x-ximf-primary-precedence、および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
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
: }
: }
: }
: }
: }
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.
著者は、文書のレビューおよび/または改善のための提案を親切に提供してくれたジムシャード、アレクセイメルニコフ、ダミアンロケ、ティボーカッサン、ウィリアムオッタウェイ、ショーンターナーに感謝します。いつものように、すべてのエラーと省略は作者の責任です。
Authors' Addresses
著者のアドレス
Laurent CAILLEUX DGA MI BP 7 35998 RENNES CEDEX 9 France
Laurent CAILLEUX DGA MI BP 7 35998 RENNES CEDEX 9フランス
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 Nutley Street、Suite 106 Fairfax、VA 22031アメリカ合衆国
EMail: bonatti252@ieca.com