[要約] RFC 7444は、インターネットメールでのセキュリティラベルに関する規格であり、メールのセキュリティを向上させるために開発されました。このRFCの目的は、メールの送信者がメッセージのセキュリティレベルを明示的に指定できるようにすることです。
Independent Submission K. Zeilenga
Request for Comments: 7444 A. Melnikov
Category: Informational Isode Limited
ISSN: 2070-1721 February 2015
Security Labels in Internet Email
インターネットメールのセキュリティラベル
Abstract
概要
This document describes a header field, SIO-Label, for use in Internet email to convey the sensitivity of the message. This header field may carry a textual representation (a display marking) and/or a structural representation (a security label) of the sensitivity of the message. This document also describes a header field, SIO-Label-History, for recording changes in the message's label.
このドキュメントでは、インターネットメールでメッセージの機密性を伝えるために使用するヘッダーフィールドSIO-Labelについて説明します。このヘッダーフィールドは、メッセージの機密性のテキスト表現（ディスプレイマーキング）および/または構造表現（セキュリティラベル）を持つことができます。このドキュメントでは、メッセージのラベルの変更を記録するためのヘッダーフィールドSIO-Label-Historyについても説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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/rfc7444.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7444で入手できます。
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
1.1. Relationship to Inline Sensitivity Markings ................3
1.2. Relationship to Preexisting Security Label Header Fields ...4
1.3. Relationship to Enhanced Security Services for S/MIME ......4
2. Conventions Used in This Document ...............................5
3. Overview ........................................................5
4. The SIO-Label Header Field ......................................6
5. The SIO-Label-History Header Field ..............................9
6. IANA Considerations ............................................12
7. Security Considerations ........................................12
8. References .....................................................14
8.1. Normative References ......................................14
8.2. Informative References ....................................15
Acknowledgements ..................................................16
Authors' Addresses ................................................16
A security label, sometimes referred to as a confidentiality label, is a structured representation of the sensitivity of a piece of information. A security label can be used in conjunction with a clearance, a structured representation of what sensitive information a person (or other entity) is authorized to access, and a security policy to control access to each piece of information. For instance, an email message could have an "EXAMPLE CONFIDENTIAL" label that requires the sender and the receiver to have a clearance granting access to information labeled "EXAMPLE CONFIDENTIAL". X.841 [X.841] provides a discussion of security labels, clearances, and security policy.
機密ラベルと呼ばれることもあるセキュリティラベルは、情報の機密性の構造化された表現です。セキュリティラベルは、認可上限、個人（または他のエンティティ）がアクセスを許可されている機密情報の構造化された表現、および各情報へのアクセスを制御するセキュリティポリシーと共に使用できます。たとえば、電子メールメッセージに「EXAMPLE CONFIDENTIAL」というラベルを付けることができます。このラベルでは、送信者と受信者に「EXAMPLE CONFIDENTIAL」というラベルの付いた情報へのアクセスを許可する許可が必要です。 X.841 [X.841]では、セキュリティラベル、認可上限、およびセキュリティポリシーについて説明しています。
A display marking is a textual representation of the sensitivity of a piece of information. For instance, "EXAMPLE CONFIDENTIAL" is a textual representation of the sensitivity. A security policy can be used to generate display markings from security labels. Display markings are generally expected to be prominently displayed whenever the content is displayed.
表示マークは、情報の機密性をテキストで表したものです。たとえば、「EXAMPLE CONFIDENTIAL」は機密性のテキスト表現です。セキュリティポリシーを使用して、セキュリティラベルから表示マーキングを生成できます。表示マーキングは、通常、コンテンツが表示されるときはいつでも目立つように表示されると予想されます。
Sensitivity-based authorization is used in networks that operate under a set of information classification rules, such as in government and military agency networks. The standardized formats for security labels, clearances, security policy, and associated authorization models are generalized and can be used in non-government deployments where appropriate.
感度ベースの承認は、政府や軍事機関のネットワークなど、一連の情報分類ルールの下で動作するネットワークで使用されます。セキュリティラベル、認可上限、セキュリティポリシー、および関連する承認モデルの標準化された形式は一般化されており、必要に応じて非政府機関の展開で使用できます。
Security labels may also be used for purposes other than authorization. In particular, they may be used simply to convey the sensitivity of a piece information. The security label could be used, for instance, to organize content in a content store.
セキュリティラベルは、承認以外の目的にも使用できます。特に、ピース情報の機密性を伝えるためだけに使用できます。セキュリティラベルは、たとえば、コンテンツストアのコンテンツを整理するために使用できます。
This document describes a protocol for conveying the sensitivity of a electronic mail message [RFC5322] as a whole. In particular, this document describes a header field, SIO-Label, that carries a security label, a display marking, and display colors. This document also describes a header field, SIO-Label-History, that records changes in the message's security label.
このドキュメントは、全体として電子メールメッセージ[RFC5322]の機密性を伝達するためのプロトコルについて説明します。特に、このドキュメントでは、セキュリティラベル、表示マーキング、および表示色を運ぶヘッダーフィールドSIO-Labelについて説明します。このドキュメントでは、メッセージのセキュリティラベルの変更を記録するヘッダーフィールドSIO-Label-Historyについても説明します。
This protocol is based in part upon "XEP-0258: Security Labels in XMPP" [XEP258].
このプロトコルは、「XEP-0258：XMPPのセキュリティラベル」[XEP258]に一部基づいています。
In environments requiring messages to be marked with an indication of their sensitivity, it is common to place a textual representation of the sensitivity, a display marking, within the body to the message and/or in the Subject header field. For instance, the authors often receives messages of the form:
メッセージに機密性を示すマークを付ける必要がある環境では、メッセージの本文内や件名ヘッダーフィールドに、機密性のテキスト表現、表示マークを配置するのが一般的です。たとえば、作者はしばしば次の形式のメッセージを受け取ります。
To: author <author@example.com>;
From: Some One <someone@example.net>;
Subject: the subject (UNCLASSIFIED)
UNCLASSIFIED
未分類
Text of the message.
メッセージのテキスト。
UNCLASSIFIED
未分類
Typically, when placed in the body of the message, the marking is inserted into the content such that it appears as the first line(s) of text in the body of the message. This is known as a FLOT (First Line(s) of Text) marking. The marking may or may not be surrounded by other text indicating that the marking denotes the sensitivity of the message. A FLOT may also be accompanied by a LLOT (Last Line(s) of Text) marking. The message above contains a two-line FLOT and a two-line LLOT (in both cases, a line providing the marking and an empty line between the marking and the original content appear).
通常、メッセージの本文に配置されると、マーキングはコンテンツに挿入され、メッセージの本文のテキストの最初の行として表示されます。これはFLOT（テキストの最初の行）マーキングと呼ばれます。マーキングは、マーキングがメッセージの機密性を示すことを示す他のテキストで囲まれている場合と囲まれていない場合があります。 FLOTにはLLOT（Last Line（s）of Text）マーキングも伴う場合があります。上記のメッセージには、2行のFLOTと2行のLLOTが含まれています（どちらの場合も、マーキングを提供する行と、マーキングと元のコンテンツの間に空の行が表示されます）。
Typically, when placed in the Subject of the message, the marking is inserted before or after the contents of the original Subject field; it is surrounded by parentheses or the like and/or separated from the content by white space.
通常、メッセージの件名に配置すると、元の件名フィールドの内容の前または後にマーキングが挿入されます。括弧などで囲まれるか、コンテンツと空白で区切られます。
The particular syntax and semantics of inline sensitivity markings are generally a local matter. This hinders interoperability within an organization wanting to take actions based upon these markings and hinders interoperability between cooperating organizations wanting to usefully share sensitivity information
インラインの機密マークの特定の構文とセマンティクスは、一般にローカルな問題です。これは、これらのマーキングに基づいてアクションを実行したい組織内の相互運用性を妨げ、機密情報を有効に共有したい協力組織間の相互運用性を妨げます。
The authors expect that such markings will continue to be widely used, especially in the absence of ubiquitous support for a standardized header field indicating the sensitivity of the message.
著者は、特にメッセージの機密性を示す標準化されたヘッダーフィールドに対するユビキタスサポートがない場合は、このようなマーキングが引き続き広く使用されることを期待しています。
The authors hope that through the use of a formally specified header field, interoperability within organizations and between organizations can be improved.
著者は、正式に指定されたヘッダーフィールドを使用することにより、組織内および組織間の相互運用性が改善されることを期待しています。
A number of non-standard header fields, such as the X-X411 field, are used to carry a representation of the sensitivity of the message, whether a structured representation or textual representation.
X-X411フィールドなどのいくつかの非標準ヘッダーフィールドは、構造化表現かテキスト表現かに関係なく、メッセージの機密性の表現を運ぶために使用されます。
The authors hope that the use of preexisting (non-standard) header fields will be replaced, over time, with the use of the header field described in this document.
著者は、既存の（非標準の）ヘッダーフィールドの使用が、時間の経過とともに、このドキュメントで説明されているヘッダーフィールドの使用に置き換えられることを期待しています。
Enhanced Security Services for S/MIME (ESS) [RFC2634] provides, amongst other services, signature services "for content integrity, non-repudiation with the proof of origin, and [securely] binding attributes (such as a security label) to the original content".
S / MIME（ESS）[RFC2634]の拡張セキュリティサービスは、他のサービスの中でも、「コンテンツの整合性、発行元の証明による否認防止、および（安全な）バインディング属性（セキュリティラベルなど）のための署名サービスを提供します。オリジナルコンテンツ」。
While it may be possible to utilize the protocol described in this document concurrently with ESS, this protocol should generally be viewed as an alternative to ESS.
このドキュメントで説明されているプロトコルをESSと同時に使用することもできますが、このプロトコルは一般にESSの代替と見なすべきです。
It is noted that in ESS, the security label applies to MIME [RFC2045] content, where in this protocol, the label applies to the message as a whole.
ESSでは、セキュリティラベルはMIME [RFC2045]コンテンツに適用され、このプロトコルでは、ラベルはメッセージ全体に適用されることに注意してください。
It is also noted that in ESS, security labels are securely bound to the MIME content through the use of digital signatures. This protocol does not provide message-signing services and hence does not provide secure binding the label to the message, content integrity, or non-repudiation of the proof of origin.
ESSでは、セキュリティラベルがデジタル署名を使用してMIMEコンテンツに安全にバインドされていることにも注意してください。このプロトコルはメッセージ署名サービスを提供しないため、メッセージへのラベルの安全なバインド、コンテンツの整合性、または発信元の証明の否認防止を提供しません。
This protocol is designed for situations/environments where message signing is not necessary to provide sufficient security.
このプロトコルは、十分なセキュリティを提供するためにメッセージの署名が不要な状況/環境向けに設計されています。
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 formal syntax specifications in this document use the Augmented Backus-Naur Form (ABNF) as described in [RFC5234].
このドキュメントの正式な構文仕様では、[RFC5234]で説明されているようにAugmented Backus-Naur Form（ABNF）を使用しています。
The term "base64 encoding" is used to refer to the "Base 64 encoding" defined in Section 4 of [RFC4648]. The term "BER encoding" is used to refer to encoding per the Basic Encoding Rules (BER) as defined in [X.690].
「base64エンコーディング」という用語は、[RFC4648]のセクション4で定義されている「Base 64エンコーディング」を指すために使用されます。 「BERエンコーディング」という用語は、[X.690]で定義されているBasic Encoding Rules（BER）に基づくエンコーディングを指します。
A Mail User Agent (MUA) originating a message can, if so configured, offer the user a menu of sensitivities to choose from and, upon selection, insert the display marking, foreground and background colors, and security label parameters associated with that selection into the SIO-Label header field of the message.
メッセージを発信するメールユーザーエージェント（MUA）は、そのように構成されている場合、ユーザーに選択する感度のメニューを提供し、選択時に、その選択に関連付けられた表示マーキング、前景色と背景色、およびセキュリティラベルパラメーターをに挿入できます。メッセージのSIO-Labelヘッダーフィールド。
Mail Submission Agents (MSAs), Mail Transfer Agents (MTAs), and Mail Delivery Agents (MDAs) can then, if so configured, use the provided sensitivity information (or lack thereof) in determining whether to accept, forward, or otherwise act on the message as submitted. These agents, hereafter referred to as Service Agents (SAs), can, if so configured, modify the sensitivity information of the message, such as replacing the security label and/or display marking with equivalent representations of the sensitivity of the message. SAs that add, modify, or delete the SIO-Label header field SHOULD add an SIO-Label-History header.
メール送信エージェント（MSA）、メール転送エージェント（MTA）、およびメール配信エージェント（MDA）は、そのように構成されている場合、提供された機密情報（またはその欠如）を使用して、受け入れるか、転送するか、またはその他の方法で処理するかを決定できます。送信されたメッセージ。これらのエージェント（以降、サービスエージェント（SA）と呼びます）は、そのように構成されている場合、メッセージの機密情報を変更できます。たとえば、セキュリティラベルや表示マーキングをメッセージの機密性の同等の表現に置き換えるなどです。 SIO-Labelヘッダーフィールドを追加、変更、または削除するSAは、SIO-Label-Historyヘッダーを追加する必要があります（SHOULD）。
Receiving MUAs that implement this extension SHALL, when displaying the message, also prominently display the marking, if any, conveyed in the SIO-Label header field or, if policy-aware and configured to display locally generated markings, a marking generated by the conveyed label and the governing policy. It is also desirable to display this marking in listings of messages. In the case the conveyed marking is displayed, the marking SHOULD be displayed using the foreground and background colors conveyed in the header field. In the case the marking was generated from a conveyed label and the governing policy, the marking SHOULD be displayed using the foreground and background colors conveyed by the governing policy.
この拡張を実装するMUAを受信すると、メッセージを表示するときに、SIO-Labelヘッダーフィールドで伝達されるマーキングがあれば目立つように表示するか、ポリシー対応でローカルで生成されたマーキングを表示するように構成されている場合は、伝達によって生成されるマーキングを目立つように表示する必要がありますラベルと管理ポリシー。メッセージのリストにこのマークを表示することも望ましいです。伝達されたマーキングが表示される場合、マーキングはヘッダーフィールドで伝達された前景色と背景色を使用して表示する必要があります（SHOULD）。マーキングが伝達されたラベルと管理ポリシーから生成された場合、マーキングは、管理ポリシーによって伝えられた前景色と背景色を使用して表示する必要があります（SHOULD）。
While MUAs are not expected to make authorization decisions based upon values of the SIO-Label header field, MUAs can otherwise use the provided sensitivity information (or lack thereof) in determining how to act on the message. For instance, the MUA may organize messages in its store of messages based upon the content of this header field.
MUAはSIO-Labelヘッダーフィールドの値に基づいて承認を決定することは期待されていませんが、MUAは提供された機密情報（またはその欠如）を使用して、メッセージの処理方法を決定できます。たとえば、MUAは、このヘッダーフィールドの内容に基づいて、メッセージストアにメッセージを編成できます。
The header field name is "SIO-Label", and its content is a set of key/value pairs, each referred to as a parameter.
ヘッダーフィールド名は「SIO-Label」で、その内容はキー/値ペアのセットであり、それぞれパラメーターと呼ばれます。
Formal header field syntax:
正式なヘッダーフィールドの構文：
sio-label = "SIO-Label:" [FWS] sio-label-parm-seq [FWS] CRLF
sio-label = "SIO-Label：" [FWS] sio-label-parm-seq [FWS] CRLF
sio-label-parm-seq = sio-label-parm [ [FWS] ";" [FWS] sio-label-parm-seq ]
sio-label-parm-seq = sio-label-parm [[FWS] ";" [FWS] sio-label-parm-seq]
sio-label-parm = parameter
where the parameter production is defined in [RFC2231], the FWS production is defined in [RFC5322], and the CRLF production is defined in [RFC5234]. It is noted that the productions defined in [RFC2231] rely on the ABNF in [RFC0822], which implicitly allows for white space in certain cases. In particular, white space is implicitly allowed in the parameter production immediately before and after the "=". It is also noted that [RFC2231] allows for quoted-string values (for parameter production) of substantial length, for string characters outside of US-ASCII, or for other such cases. Implementors should consult the referenced specifications for details.
ここで、パラメーターの生成は[RFC2231]で定義され、FWSの生成は[RFC5322]で定義され、CRLFの生成は[RFC5234]で定義されます。 [RFC2231]で定義されているプロダクションは、[RFC0822]のABNFに依存しているため、特定の場合に暗黙的に空白が許可されることに注意してください。特に、「=」の直前と直後のパラメーター生成では空白が暗黙的に許可されます。また、[RFC2231]は、US-ASCII以外の文字列文字、または他のそのような場合に、かなりの長さの引用符付き文字列値（パラメーター生成用）を許可することにも注意してください。詳細については、実装者は参照されている仕様を参照してください。
The "marking" parameter is a display string for use by implementations that are unable or unwilling to utilize the governing security policy to generate display markings. The "marking" parameter SHOULD generally be provided in SIO-Label header fields. It ought only be absent where an SA relies on other SAs to generate the marking.
「マーキング」パラメータは、管理セキュリティポリシーを利用して表示マーキングを生成できない、または使用したくない実装が使用する表示文字列です。 「マーキング」パラメータは通常、SIO-Labelヘッダーフィールドに指定する必要があります（SHOULD）。 SAが他のSAに依存してマーキングを生成する場合にのみ存在する必要があります。
The "fgcolor" and "bgcolor" parameters are tokens restricted to color production representing the foreground and background colors, respectively, for use in colorizing the display marking string. Their values are RGB colors in hexadecimal format (e.g., "#ff0000"), or one of the Cascading Style Sheets (CSS) color names (e.g., "red") given in named-color type below (the 16 HTML4 colors + "orange") [CSS3-Color]. The default foreground color is black. The default
「fgcolor」および「bgcolor」パラメータは、表示のマーキング文字列の色付けに使用するために、それぞれ前景色と背景色を表すカラー生成に制限されたトークンです。それらの値は、16進数形式のRGBカラー（たとえば、「＃ff0000」）、または以下の名前付きカラータイプで指定されたカスケードスタイルシート（CSS）のカラー名（たとえば、「red」）（16 HTML4カラー+ "オレンジ」）[CSS3-Color]。デフォルトの前景色は黒です。デフォルト
background is white. The "fgcolor" and "bgcolor" parameters SHALL be absent if the "marking" parameter is absent. The HEXDIG production below is defined in [RFC5234].
背景は白です。 「マーキング」パラメーターが存在しない場合、「fgcolor」および「bgcolor」パラメーターは存在しないものとします（SHALL）。以下のHEXDIGプロダクションは[RFC5234]で定義されています。
Formal color syntax:
正式な色の構文：
color = hex-color / named-color
hex-color = "#" 6HEXDIG ; Hex-encoded RGB
named-color = "aqua" / "black" / "blue" / "fuschia" / "gray" / "green" / "lime" / "maroon" / "navy" / "olive" / "purple" / "red" / "silver" / "teal" / "white" / "yellow" / "orange" ; named colors
named-color = "aqua" / "black" / "blue" / "fuschia" / "gray" / "green" / "lime" / "maroon" / "navy" / "olive" / "purple" / "red "/"シルバー "/"ティール "/"ホワイト "/"イエロー "/"オレンジ ";名前付きの色
The "type" parameter is a quoted string containing the string ":ess", the string ":x411", the string ":xml", or a URI [RFC3986] denoting the type and encoding of the "label" parameter. The "label" parameter value is a quoted string. The "type" parameter SHALL be present if the "label" parameter is present. The "label" parameter SHALL be present if the "type" parameter is present. When sensitivity-based authorization is performed, the absence of the "type" and "label" parameters indicates that the message is handled under default handling rules (e.g., as if no SIO-Label was present).
"type"パラメータは、文字列 "：ess"、文字列 "：x411"、文字列 "：xml"、または "label"パラメータのタイプとエンコーディングを示すURI [RFC3986]を含む引用符付きの文字列です。 「label」パラメータ値は引用符付きの文字列です。 「ラベル」パラメータが存在する場合、「タイプ」パラメータが存在する必要があります。 「type」パラメータが存在する場合、「label」パラメータが存在する必要があります。機密性ベースの承認が実行される場合、「type」および「label」パラメーターがないことは、メッセージがデフォルトの処理規則（たとえば、SIO-Labelが存在しないかのように）で処理されることを示します。
The string ":ess" indicates that the "label" parameter value is the base64 encoding of the BER encoding of an ESS security label [RFC2634].
文字列「：ess」は、「label」パラメータ値がESSセキュリティラベル[RFC2634]のBERエンコーディングのbase64エンコーディングであることを示します。
ESS Label Example:
ESSラベルの例：
SIO-Label: marking="EXAMPLE CONFIDENTIAL";
fgcolor=black; bgcolor=red;
type=":ess"; label="MQYGASkCAQM="
The string ":x411" indicates that the "label" parameter value is the base64 encoding of the BER encoding of an X.411 security label [X.411].
文字列「：x411」は、「label」パラメータ値がX.411セキュリティラベル[X.411]のBERエンコーディングのbase64エンコーディングであることを示します。
X.411 Label Example:
X.411ラベルの例：
SIO-Label: marking="EXAMPLE CONFIDENTIAL";
fgcolor=black; bgcolor=red;
type=":x411"; label="MQYGASkCAQM="
The string ":xml" indicates that the "label" parameter value is the base64 encoding of a security label represented using [XML]. The XML prolog SHOULD be absent unless specifically required (such as when the character encoding is not UTF-8). The particular flavor of security label representation is indicated by the root element name and its name space.
文字列「：xml」は、「label」パラメータ値が[XML]を使用して表されるセキュリティラベルのbase64エンコーディングであることを示しています。特に必要でない限り（文字エンコードがUTF-8でない場合など）、XMLプロローグは存在しない必要があります（SHOULD）。セキュリティラベル表現の特定の種類は、ルート要素名とその名前空間によって示されます。
XML Label Example:
XMLラベルの例：
SIO-Label: marking="EXAMPLE CONFIDENTIAL";
fgcolor=black; bgcolor=red;
type=":xml";
label*0="PFNlY0xhYmVsIHhtbG5zPSJodHRwOi8vZXhhbX";
label*1="BsZS5jb20vc2VjLWxhYmVsLzAiPjxQb2xpY3lJ";
label*2="ZGVudGlmaWVyIFVSST0idXJuOm9pZDoxLjEiLz";
label*3="48Q2xhc3NpZmljYXRpb24+MzwvQ2xhc3NpZmlj";
label*4="YXRpb24+PC9TZWNMYWJlbD4=";
where the XML label, with new lines and white space added for readability, is:
XMLラベルは、読みやすくするために改行と空白が追加されています。
<SecLabel xmlns="http://example.com/sec-label/0">
<PolicyIdentifier URI="urn:oid:1.1"/>
<Classification>3</Classification>
</SecLabel>
The ":ess" and ":x411" formats SHOULD be used to represent ESS or X.411 security labels, respectively, instead of any direct XML representation of these formats.
"：ess"および "：x411"形式は、これらの形式の直接のXML表現の代わりに、それぞれESSまたはX.411セキュリティラベルを表すために使用する必要があります（SHOULD）。
The header field SHALL minimally contain a "marking" parameter or contain both the "type" and "label" parameters.
ヘッダーフィールドには、最低限「マーキング」パラメータが含まれるか、「タイプ」パラメータと「ラベル」パラメータの両方が含まれる必要があります。
This header field may be extended to include additional parameters by future document formally updating (or replacing) this document. Implementations SHOULD ignore additional parameters they do not recognize. This recommendation is not a mandate so as to allow agents to process a message with an SIO-Label header field with unrecognized parameters differently than a message with an SIO-Label header field without the unrecognized parameters.
このヘッダーフィールドは、将来のドキュメントがこのドキュメントを正式に更新（または置換）することにより、追加のパラメーターを含めるように拡張できます。実装は、認識しない追加のパラメーターを無視する必要があります（SHOULD）。この推奨事項は必須ではないため、エージェントは、認識されないパラメーターのないSIO-Labelヘッダーフィールドを持つメッセージとは異なる方法で、認識されないパラメーターを持つSIO-Labelヘッダーフィールドを持つメッセージを処理できます。
Each message SHALL contain zero or one SIO-Label header field.
各メッセージには、ゼロまたは1つのSIO-Labelヘッダーフィールドが含まれている必要があります。
Extended Example:
拡張された例：
SIO-Label: marking*=us-ascii'en'EXAMPLE%20CONFIDENTIAL;
fgcolor = black ; bgcolor = red ;
type=":ess"; label*0="MQYG";
label*1="ASkCAQM="
The Extended Example is equivalent to the ESS Label Example above.
拡張された例は、上記のESSラベルの例と同等です。
Any service agent MAY record label changes in an SIO-Label-History header. This header field is intended to provide trace information (and only trace information). For instance, it can be used to record the label change when an SIO-Label header is added, modified, or deleted by a service agent. This field can be used in other situations as well. For instance, a gateway that translates X.400 messages to RFC 5322 mail can use this header field to record labeling changes made while translating a message.
サービスエージェントは、SIO-Label-Historyヘッダーでラベルの変更を記録できます（MAY）。このヘッダーフィールドは、トレース情報（およびトレース情報のみ）を提供することを目的としています。たとえば、SIO-Labelヘッダーがサービスエージェントによって追加、変更、または削除されたときに、ラベルの変更を記録するために使用できます。このフィールドは、他の状況でも使用できます。たとえば、X.400メッセージをRFC 5322メールに変換するゲートウェイは、このヘッダーフィールドを使用して、メッセージの変換中に行われたラベル付けの変更を記録できます。
The SIO-Label-History header field is considered to be a trace field as defined in Section 3.6.7 of [RFC5322].
[RFC5322]のセクション3.6.7で定義されているように、SIO-Label-Historyヘッダーフィールドはトレースフィールドと見なされます。
The formal syntax of the SIO-Label-History header is the same as the SIO-Label, but with the following parameters:
SIO-Label-Historyヘッダーの正式な構文はSIO-Labelと同じですが、次のパラメーターがあります。
o change - one of "add", "replace", "delete".
o 変更-「追加」、「置換」、「削除」のいずれか。
o changed-by - contains a string identifying the agent, commonly the agent's fully qualified domain name.
o changed-by-エージェントを識別する文字列が含まれます。通常は、エージェントの完全修飾ドメイン名です。
o changed-at - contains a date-time production, as specified in [RFC5322], representing the date and time the header was rewritten.
o changed-at-ヘッダーが書き換えられた日時を表す、[RFC5322]で指定されている日時生成が含まれます。
o changed-comment - contains a string containing a comment.
o changed-comment-コメントを含む文字列が含まれています。
o marking, fgcolor, bgcolor, type, label - records the message's label information prior to adding, modifying, or deleting SIO-Label, using the same parameter syntax used for SIO-Label. These parameters are absent when the change action is "add".
o マーキング、fgcolor、bgcolor、タイプ、ラベル-SIO-Labelと同じパラメーター構文を使用して、SIO-Labelを追加、変更、または削除する前にメッセージのラベル情報を記録します。変更アクションが「追加」の場合、これらのパラメーターはありません。
o new-marking, new-fgcolor, new-bgcolor, new-type, new-label - records the message's label information after adding, modifying, or deleting SIO-Label, using the same parameter syntax used for corresponding SIO-Label parameters. These parameters are absent when the change type is "delete".
o new-marking、new-fgcolor、new-bgcolor、new-type、new-label-対応するSIO-Labelパラメーターに使用されているのと同じパラメーター構文を使用して、SIO-Labelを追加、変更、または削除した後にメッセージのラベル情報を記録します。変更タイプが「削除」の場合、これらのパラメーターはありません。
The header field SHALL minimally contain the "change", "changed-by", and "changed-at" parameters.
ヘッダーフィールドには、「change」、「changed-by」、および「changed-at」パラメータが最低限含まれている必要があります。
This header field can be extended to include additional parameters by future documents formally updating (or replacing) this document.
このヘッダーフィールドを拡張して、将来のドキュメントがこのドキュメントを正式に更新（または置換）することにより、追加のパラメーターを含めることができます。
Each message can contain zero or more SIO-Label-History header fields. All SIO-Label-History header fields should immediately follow the SIO-Label header field, if any, and be grouped together. Additional SIO-Label-History header fields should be added immediately preceding any existing SIO-Label-History header fields.
各メッセージには、0個以上のSIO-Label-Historyヘッダーフィールドを含めることができます。すべてのSIO-Label-Historyヘッダーフィールドは、SIO-Labelヘッダーフィールドがある場合は、その直後に続き、グループ化される必要があります。追加のSIO-Label-Historyヘッダーフィールドは、既存のSIO-Label-Historyヘッダーフィールドの直前に追加する必要があります。
SIO Label History Add, Modify, Delete Example:
SIOラベル履歴の追加、変更、削除の例：
SIO-Label-History: marking="EXAMPLE CONFIDENTIAL";
fgcolor=black; bgcolor=red;
type=":xml";
label*0="PFNlY0xhYmVsIHhtbG5zPSJodHRwOi8vZXhhbX";
label*1="BsZS5jb20vc2VjLWxhYmVsLzAiPjxQb2xpY3lJ";
label*2="ZGVudGlmaWVyIFVSST0idXJuOm9pZDoxLjEiLz";
label*3="48Q2xhc3NpZmljYXRpb24+MzwvQ2xhc3NpZmlj";
label*4="YXRpb24+PC9TZWNMYWJlbD4=";
change=delete;
changed-by="delete.example.com";
changed-at="18 Feb 2013 9:24 PDT";
changed-comment="delete"
SIO-Label-History: marking="EXAMPLE CONFIDENTIAL";
fgcolor=black; bgcolor=red;
type=":ess"; label="MQYGASkCAQM=";
new-marking="EXAMPLE CONFIDENTIAL";
new-fgcolor=black; new-bgcolor=red;
new-type=":xml";
new-label*0="PFNlY0xhYmVsIHhtbG5zPSJodHRwOi8vZXhhbX";
new-label*1="BsZS5jb20vc2VjLWxhYmVsLzAiPjxQb2xpY3lJ";
new-label*2="ZGVudGlmaWVyIFVSST0idXJuOm9pZDoxLjEiLz";
new-label*3="48Q2xhc3NpZmljYXRpb24+MzwvQ2xhc3NpZmlj";
new-label*4="YXRpb24+PC9TZWNMYWJlbD4=";
change=replace;
changed-by="modify.example.net";
changed-at="18 Feb 2013 8:24 PDT";
changed-comment="replaced with XML variant"
SIO-Label-History: new-marking="EXAMPLE CONFIDENTIAL";
new-fgcolor=black; new-bgcolor=red;
new-type=":ess"; new-label="MQYGASkCAQM=";
change=add;
changed-by="add.example.net";
changed-at="18 Feb 2013 7:24 PDT";
changed-comment="added label"
The SIO-Label and SIO-Label-History header fields have been registered in the "Provisional Message Header Field Registry" in accordance with [RFC3864].
SIO-LabelおよびSIO-Label-Historyヘッダーフィールドは、[RFC3864]に従って「暫定メッセージヘッダーフィールドレジストリ」に登録されています。
Header field name: SIO-Label
Applicable protocol: mail [RFC5322]
Status: provisional
Author/change controller: Kurt Zeilenga (kurt.zeilenga@isode.com)
Specification document(s): RFC 7444
Header field name: SIO-Label-History
Applicable protocol: mail [RFC5322]
Status: provisional
Author/change controller: Kurt Zeilenga (kurt.zeilenga@isode.com)
Specification document(s): RFC 7444
Sensitive information should be appropriately protected (whether labeled or not). For email messages, it is generally appropriate for the sending entity to authenticate the receiving entity and to establish transport-level security, including protective services for both data integrity and data confidentiality. When a receiving entity makes authorization decisions based upon assertions of the sending entity, including assertions of identity, it is generally appropriate for the receiving entity to authenticate the sending entity.
機密情報は適切に保護する必要があります（ラベル付けされているかどうかにかかわらず）。電子メールメッセージの場合、送信エンティティが受信エンティティを認証し、データ整合性とデータ機密性の両方の保護サービスを含むトランスポートレベルのセキュリティを確立することが一般的に適切です。受信エンティティがアイデンティティのアサーションを含む送信エンティティのアサーションに基づいて承認決定を行う場合、受信エンティティが送信エンティティを認証することは一般に適切です。
This document provides a facility for expressing the sensitivity of an email message. The mere expression of actual sensitivity generally does not elevate the sensitivity of the message; however, expressions of sensitivities can themselves be regarded as sensitive information. For instance, a marking of "BLACK PROJECT RESTRICTED" could disclose the existence of a sensitivity project.
このドキュメントは、電子メールメッセージの機密性を表現する機能を提供します。実際の感性の単なる表現は一般にメッセージの感性を高めません。ただし、機密性の表現自体は機密情報と見なすことができます。たとえば、「BLACK PROJECT RESTRICTED」のマークは、機密プロジェクトの存在を明らかにする可能性があります。
The SIO-Label header field expresses the sensitivity of the whole message, including the header and body. This document does not provide a means to express the sensitivity of portions of an email message, such as the possibly different sensitivities of various MIME parts that the message may be composed of. The approach used in this document favors simplicity and ease of use (i.e., a single expression of sensitivity) over the complexity and difficulty of marking and labeling portions of a message.
SIO-Labelヘッダーフィールドは、ヘッダーと本文を含むメッセージ全体の機密性を表します。このドキュメントでは、メッセージを構成するさまざまなMIMEパーツの機密性が異なる可能性があるなど、電子メールメッセージの一部の機密性を表現する手段を提供していません。このドキュメントで使用するアプローチは、メッセージの部分のマークとラベル付けの複雑さと難しさよりも、シンプルさと使いやすさ（つまり、単一の感度表現）を優先します。
The expressed sensitivity can be used in determining how to handle a message. For instance, the value of the SIO-Label header field (or lack thereof) can be used to determine if it is appropriate to be forwarded to a particular entity and, if so, what minimum security services ought to be used in the forwarding exchange. The mechanism for determining how to handle a message-based expressed sensitivity is beyond the scope of this document.
表現された感度は、メッセージの処理方法を決定する際に使用できます。たとえば、SIO-Labelヘッダーフィールドの値（またはその欠如）を使用して、特定のエンティティに転送することが適切かどうかを判断し、適切な場合は、転送交換で最低限必要なセキュリティサービスを使用する必要があります。 。メッセージベースの表現された機密性を処理する方法を決定するメカニズムは、このドキュメントの範囲を超えています。
The actual content may have more or less sensitivity than indicated by the security label. Agents should avoid lowering security requirements for message exchange with a particular entity based upon conveyed sensitivity.
実際のコンテンツの機密性は、セキュリティラベルで示されているものより多少高い場合があります。エージェントは、伝えられた機密性に基づいて、特定のエンティティとのメッセージ交換のセキュリティ要件を低下させないようにする必要があります。
This protocol does not itself provide message-signing services, such as used in providing message integrity protection, non-repudiation, and binding of attributes (such as the security label to the message). While it possible that this protocol could be used with a general message-signing service, this document does not detail such use.
このプロトコル自体は、メッセージの完全性保護、否認防止、属性（メッセージへのセキュリティラベルなど）のバインドなどのメッセージ署名サービスを提供しません。このプロトコルは一般的なメッセージ署名サービスで使用できる可能性がありますが、このドキュメントではそのような使用法について詳しく説明していません。
While security label and display marking parameters are expected to express the same sensitivity, nothing in this specification ensures that the security label and display marking values express the same sensitivity. For instance, an MUA could submit a message that contains a security label that expresses one sensitivity and a display marking with a different sensitivity, and by doing so, possibly cause an SA to inappropriately handle the message. It is generally appropriate for each SA using the SIO-Label values to determine if the security label and display marking values express the same sensitivity and, if not, take appropriate action (such as rejecting the message).
セキュリティラベルとディスプレイマーキングのパラメーターは同じ感度を表すことが期待されていますが、この仕様では、セキュリティラベルとディスプレイマーキングの値が同じ感度を表すことを保証していません。たとえば、MUAは、1つの機密性と異なる機密性を持つ表示マーキングを表すセキュリティラベルを含むメッセージを送信し、そうすることにより、SAがメッセージを不適切に処理する可能性があります。一般に、SIO-Label値を使用する各SAが、セキュリティラベルとディスプレイマーキング値が同じ機密性を表すかどうかを判断し、そうでない場合は適切なアクション（メッセージの拒否など）を行うことが適切です。
This document also provides a facility for expressing changes to the label of a message. This is intended to be used for trace purposes only. It is noted that the SIO-Label-History header field can include sensitive information and, as such, can be removed from the message when its inclusion would result in disclosure of inappropriate information.
このドキュメントは、メッセージのラベルへの変更を表現する機能も提供します。これは、トレース目的でのみ使用することを目的としています。 SIO-Label-Historyヘッダーフィールドには機密情報を含めることができるため、メッセージに含めると不適切な情報が開示される場合は、メッセージから削除することができます。
[CSS3-Color] Celik, T. and C. Lilley, "CSS3 Color Module", W3C Candidate Recommendation CR-css3-color-20030514, May 2003, <http://www.w3.org/TR/2003/CR-css3-color-20030514>.
[CSS3-Color] Celik、T。およびC. Lilley、「CSS3 Color Module」、W3C候補勧告CR-css3-color-20030514、2003年5月、<http://www.w3.org/TR/2003/CR -css3-color-20030514>。
[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>。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997, <http://www.rfc-editor.org/info/rfc2231>.
[RFC2231] Freed、N。およびK. Moore、「MIMEパラメータ値とエンコードされたワード拡張：文字セット、言語、および継続」、RFC 2231、1997年11月、<http://www.rfc-editor.org/info / rfc2231>。
[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>。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004, <http://www.rfc-editor.org/info/rfc3864>.
[RFC3864] Klyne、G.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、2004年9月、<http://www.rfc-editor.org/info / rfc3864>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月、<http：//www.rfc- editor.org/info/rfc3986>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月、<http://www.rfc-editor.org/info/rfc4648>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[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>。
[X.411] ITU-T, "Message Handling Systems (MHS) - Message Transfer System: Abstract Service Definition and Procedures", ITU-T Recommendation X.411, June 1999.
[X.411] ITU-T、「メッセージ処理システム（MHS）-メッセージ転送システム：抽象サービスの定義と手順」、ITU-T勧告X.411、1999年6月。
[X.690] ITU-T, "ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, November 2008.
[X.690] ITU-T、「ASN.1エンコーディングルール：Basic Encoding Rules（BER）、Canonical Encoding Rules（CER）and Distinguished Encoding Rules（DER）」の仕様、ITU-T勧告X.690、2008年11月。
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.
[XML] Bray、T.、Paoli、J.、Sperberg-McQueen、C.、Maler、E。、およびF. Yergeau、「Extensible Markup Language（XML）1.0（Fifth Edition）」、W3C勧告REC-xml- 20081126、2008年11月、<http://www.w3.org/TR/2008/REC-xml-20081126>。
[RFC0822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", STD 11, RFC 822, August 1982, <http://www.rfc-editor.org/info/rfc822>.
[RFC0822] Crocker、D。、「ARPAインターネットテキストメッセージのフォーマットの標準」、STD 11、RFC 822、1982年8月、<http://www.rfc-editor.org/info/rfc822>。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996, <http://www.rfc-editor.org/info/rfc2045>.
[RFC2045] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月、<http://www.rfc-editor.org/info / rfc2045>。
[X.841] ITU-T, "Security information objects for access control", ITU-T Recommendation X.841, October 2000.
[X.841] ITU-T、「アクセス制御のセキュリティ情報オブジェクト」、ITU-T勧告X.841、2000年10月。
[XEP258] Zeilenga, K., "XEP-0258: Security Labels in XMPP", XEP XMPP Extension Protocols, April 2013.
[XEP258] Zeilenga、K。、「XEP-0258：Security Labels in XMPP」、XEP XMPP Extension Protocols、2013年4月。
Acknowledgements
謝辞
The authors appreciate the review, comment, and text provided by community members, including Dave Cridland, Brad Hards, Russ Housley, Steve Kille, Graeme Lunt, Alan Ross, Jim Schaad, and David Wilson.
著者は、Dave Cridland、Brad Hards、Russ Housley、Steve Kille、Graeme Lunt、Alan Ross、Jim Schaad、David Wilsonなどのコミュニティメンバーから提供されたレビュー、コメント、テキストを高く評価しています。
Authors' Addresses
著者のアドレス
Kurt Zeilenga Isode Limited
Kurt Linienga Isode Limited
EMail: Kurt.Zeilenga@isode.com
Alexey Melnikov Isode Limited 14 Castle Mews Hampton, Middlesex TW12 2NP United Kingdom
Alexey Melnikov Isode Limited 14 Castle Mewsハンプトン、ミドルセックスTW12 2NPイギリス
EMail: Alexey.Melnikov@isode.com