doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc7444.txt b/doc/rfc/rfc7444.txt
new file mode 100644
index 0000000..00b9d5a
--- /dev/null
+++ b/doc/rfc/rfc7444.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+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.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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.
+
+   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.
+
+Copyright Notice
+
+   Copyright (c) 2015 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+
+
+
+
+
+
+Zeilenga & Melnikov           Informational                     [Page 1]
+
+RFC 7444            Security Labels in Internet Email      February 2015
+
+
+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
+
+1.  Introduction
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+Zeilenga & Melnikov           Informational                     [Page 2]
+
+RFC 7444            Security Labels in Internet Email      February 2015
+
+
+   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.
+
+   This protocol is based in part upon "XEP-0258: Security Labels in
+   XMPP" [XEP258].
+
+1.1.  Relationship to Inline Sensitivity Markings
+
+   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).
+
+   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.
+
+
+
+
+Zeilenga & Melnikov           Informational                     [Page 3]
+
+RFC 7444            Security Labels in Internet Email      February 2015
+
+
+   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.
+
+1.2.  Relationship to Preexisting Security Label Header Fields
+
+   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.
+
+   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.
+
+1.3.  Relationship to Enhanced Security Services for S/MIME
+
+   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".
+
+   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.
+
+   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.
+
+   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.
+
+   This protocol is designed for situations/environments where message
+   signing is not necessary to provide sufficient security.
+
+
+
+
+Zeilenga & Melnikov           Informational                     [Page 4]
+
+RFC 7444            Security Labels in Internet Email      February 2015
+
+
+2.  Conventions Used in This Document
+
+   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].
+
+   The formal syntax specifications in this document use the Augmented
+   Backus-Naur Form (ABNF) as described in [RFC5234].
+
+   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].
+
+3.  Overview
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+Zeilenga & Melnikov           Informational                     [Page 5]
+
+RFC 7444            Security Labels in Internet Email      February 2015
+
+
+   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.
+
+4.  The SIO-Label Header Field
+
+   The header field name is "SIO-Label", and its content is a set of
+   key/value pairs, each referred to as a parameter.
+
+   Formal header field syntax:
+
+   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 = 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.
+
+   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.
+
+   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
+
+
+
+
+
+Zeilenga & Melnikov           Informational                     [Page 6]
+
+RFC 7444            Security Labels in Internet Email      February 2015
+
+
+   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].
+
+   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
+
+   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).
+
+   The string ":ess" indicates that the "label" parameter value is the
+   base64 encoding of the BER encoding of an ESS security label
+   [RFC2634].
+
+
+
+
+
+
+
+
+
+Zeilenga & Melnikov           Informational                     [Page 7]
+
+RFC 7444            Security Labels in Internet Email      February 2015
+
+
+   ESS Label Example:
+
+   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].
+
+   X.411 Label Example:
+
+   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 Example:
+
+   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:
+
+   <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.
+
+   The header field SHALL minimally contain a "marking" parameter or
+   contain both the "type" and "label" parameters.
+
+
+
+Zeilenga & Melnikov           Informational                     [Page 8]
+
+RFC 7444            Security Labels in Internet Email      February 2015
+
+
+   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.
+
+   Each message SHALL contain zero or one SIO-Label header field.
+
+   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.
+
+5.  The SIO-Label-History Header Field
+
+   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.
+
+   The SIO-Label-History header field is considered to be a trace field
+   as defined in Section 3.6.7 of [RFC5322].
+
+   The formal syntax of the SIO-Label-History header is the same as the
+   SIO-Label, but with the following parameters:
+
+   o  change - one of "add", "replace", "delete".
+
+   o  changed-by - contains a string identifying the agent, commonly the
+      agent's fully qualified domain name.
+
+   o  changed-at - contains a date-time production, as specified in
+      [RFC5322], representing the date and time the header was
+      rewritten.
+
+   o  changed-comment - contains a string containing a comment.
+
+
+
+
+
+Zeilenga & Melnikov           Informational                     [Page 9]
+
+RFC 7444            Security Labels in Internet Email      February 2015
+
+
+   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  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".
+
+   The header field SHALL minimally contain the "change", "changed-by",
+   and "changed-at" parameters.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga & Melnikov           Informational                    [Page 10]
+
+RFC 7444            Security Labels in Internet Email      February 2015
+
+
+   SIO Label History Add, Modify, Delete Example:
+
+   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"
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga & Melnikov           Informational                    [Page 11]
+
+RFC 7444            Security Labels in Internet Email      February 2015
+
+
+6.  IANA Considerations
+
+   The SIO-Label and SIO-Label-History header fields have been
+   registered in the "Provisional Message Header Field Registry" in
+   accordance with [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
+
+7.  Security Considerations
+
+   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.
+
+   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.
+
+
+
+
+
+
+Zeilenga & Melnikov           Informational                    [Page 12]
+
+RFC 7444            Security Labels in Internet Email      February 2015
+
+
+   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.
+
+   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).
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga & Melnikov           Informational                    [Page 13]
+
+RFC 7444            Security Labels in Internet Email      February 2015
+
+
+8.  References
+
+8.1.  Normative References
+
+   [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>.
+
+   [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>.
+
+   [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>.
+
+   [RFC2634]    Hoffman, P., Ed., "Enhanced Security Services for
+                S/MIME", RFC 2634, June 1999,
+                <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>.
+
+   [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>.
+
+   [RFC4648]    Josefsson, S., "The Base16, Base32, and Base64 Data
+                Encodings", RFC 4648, October 2006,
+                <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>.
+
+   [RFC5322]    Resnick, P., Ed., "Internet Message Format", RFC 5322,
+                October 2008, <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.
+
+
+
+
+
+Zeilenga & Melnikov           Informational                    [Page 14]
+
+RFC 7444            Security Labels in Internet Email      February 2015
+
+
+   [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.
+
+   [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>.
+
+8.2.  Informative References
+
+   [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>.
+
+   [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>.
+
+   [X.841]      ITU-T, "Security information objects for access
+                control", ITU-T Recommendation X.841, October 2000.
+
+   [XEP258]     Zeilenga, K., "XEP-0258: Security Labels in XMPP", XEP
+                XMPP Extension Protocols, April 2013.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga & Melnikov           Informational                    [Page 15]
+
+RFC 7444            Security Labels in Internet Email      February 2015
+
+
+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.
+
+Authors' Addresses
+
+   Kurt Zeilenga
+   Isode Limited
+
+   EMail: Kurt.Zeilenga@isode.com
+
+
+   Alexey Melnikov
+   Isode Limited
+   14 Castle Mews
+   Hampton, Middlesex  TW12 2NP
+   United Kingdom
+
+   EMail: Alexey.Melnikov@isode.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga & Melnikov           Informational                    [Page 16]
+