2023-07-18 15:08:15+03:00

RFC7444_-_Security_Labels_in_Internet_Email/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]
+

RFC9057_-_Email_Author_Header_Field/rfc9057.txt

@@ -0,0 +1,350 @@
+
+
+
+
+Independent Submission                                        D. Crocker
+Request for Comments: 9057                   Brandenburg InternetWorking
+Category: Experimental                                         June 2021
+ISSN: 2070-1721
+
+
+                       Email Author Header Field
+
+Abstract
+
+   Internet mail defines the From: header field to indicate the author
+   of the message's content and the Sender: field to indicate who
+   initially handled the message on the author's behalf.  The Sender:
+   field is optional if it has the same information as the From: field.
+   This was not a problem until development of stringent protections on
+   use of the From: field.  It has prompted Mediators, such as mailing
+   lists, to modify the From: field to circumvent mail rejection caused
+   by those protections.  In effect, the From: field has become
+   dominated by its role as a handling identifier.
+
+   The current specification augments the altered use of the From: field
+   by specifying the Author: field, which ensures identification of the
+   original author of the message and is not subject to modification by
+   Mediators.  This document is published as an Experimental RFC to
+   assess community interest, functional efficacy, and technical
+   adequacy.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This is a contribution to the RFC Series, independently
+   of any other RFC stream.  The RFC Editor has chosen to publish this
+   document at its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not candidates for any level of Internet Standard;
+   see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9057.
+
+Copyright Notice
+
+   Copyright (c) 2021 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
+   (https://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.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Terminology
+   3.  Author Header Field
+   4.  Discussion
+   5.  Security Considerations
+   6.  IANA Considerations
+   7.  Experimental Goals
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Acknowledgements
+   Author's Address
+
+1.  Introduction
+
+   Internet mail conducts asynchronous communication from an author to
+   one or more recipients and is used for ongoing dialog amongst them.
+   Email has a long history of serving a wide range of human uses and
+   styles, within that simple framework, and the mechanisms for making
+   email robust and safe serve that sole purpose.
+
+   Internet mail defines the content header's From: field to indicate
+   the author of the message and the Sender: field to indicate who
+   initially handled the message on the author's behalf [Mail-Fmt].  The
+   Sender: field is optional if it has the same information as the From:
+   field.  That is, when the Sender: field is absent, the From: field
+   has conflated semantics as both a handling identifier and a content
+   creator identifier.  These fields were initially defined in [RFC733],
+   and making the redundant Sender: field optional was a small, obvious
+   optimization in the days of slower communications, expensive storage,
+   and less powerful computers.
+
+   The dual semantics were not a problem until development of stringent
+   protections on use of the From: field.  It has prompted Mediators,
+   such as mailing lists, to modify the From: field to circumvent
+   receiver mail rejection caused by those protections.  This affects
+   end-to-end usability of email between the author and the final
+   recipients, because mail received from the same author is treated
+   differently by the recipient's software, depending on what path the
+   message followed.
+
+   By way of example, mail originating with:
+
+   From:  Example User <user@example.com>
+
+   which is sent directly to a recipient, will show the author's display
+   name correctly and can correctly analyze, filter, and aggregate mail
+   from the author based on their email address.  However, if the author
+   sends through a mailing list and the mailing list conducts a common
+   form of From: modification needed to bypass enforcement of stringent
+   authentication policies, then the received message might instead have
+   a From: field showing:
+
+   From: Example User via Example List <listname@list.example.org>
+
+   The change inserts an operational address, for the Mediator, into the
+   From: field and distorts the field's display name as a means of
+   recording the modification.
+
+   In terms of email identification semantics, this is a profound
+   change:
+
+   *  The result is that the recipient's software will see the message
+      as being from an entirely different author and will handle it
+      separately, such as for sorting or filtering.  In effect, the
+      recipient's software will see the same person's email as being
+      from a different address; this includes the person's actual
+      address and each of the mailing lists that person's mail transits.
+
+   *  Mediators might create a Reply-To: field with the original From:
+      field email address.  This facilitates getting replies back to the
+      original author, but it does nothing to aid other processing or
+      presentation done by the recipient's Mail User Agent (MUA) based
+      on what it believes is the author's address or original display
+      name.  This Reply-To action represents another knock-on effect
+      (e.g., collateral damage) by distorting the meaning of that header
+      field, as well as creating an issue if the field already exists.
+
+   In effect, the From: field has become dominated by its role as a
+   handling identifier.  The current specification augments this altered
+   use of the From: field by specifying the Author: field, which
+   identifies the original author of the message and is not subject to
+   modification by Mediators.
+
+   While it might be cleanest to move towards more reliable use of the
+   Sender: field and then to target it as the focus of authentication
+   concerns, enhancement of existing standards works best with
+   incremental additions, rather than with efforts at replacement.  To
+   that end, this specification provides a means of supplying author
+   information that is not subject to modification by processes seeking
+   to enforce stringent authentication.
+
+   This version is published as an Experimental RFC to assess community
+   interest, functional efficacy, and technical adequacy.  See
+   Section 7.
+
+2.  Terminology
+
+   Terminology and architectural details in this document are
+   incorporated from [Mail-Arch].
+
+   Normative language, per [RFC8174]:
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+3.  Author Header Field
+
+   Author: is a new message header field being defined.  It has the same
+   syntax as the From: header field [Mail-Fmt].  As with the original
+   and primary intent for the From: field, the Author: field is intended
+   to contain the email address of the author of the message content.
+   It also can contain the displayable human name of the author.
+
+   The [ABNF] for the field's syntax is:
+
+   author = "Author:" mailbox-list CRLF
+
+   which echos the syntax for the From: header field.
+
+   This header field can be added as part of the original message
+   creation process, or it can be added later, by a Mediator, to
+   preserve the original author information from the From: field.
+
+   The goal of the Author: field is to reflect information about the
+   original author.  However, it is possible that the author's MUA or
+   Mail Submission Agent (MSA) will not create it but that a Mediator
+   might know it will be modifying the From: field and wish to preserve
+   the author information.  Hence, it needs to be allowed to create the
+   Author: field for this if the field does not already exist.
+
+   Processing of the Author: field follows these rules:
+
+   *  If an Author: field already exists, a new one MUST NOT be created,
+      and the existing one MUST NOT be modified.
+
+   *  An author's MUA or MSA MAY create an Author: field, and its value
+      MUST be identical to the value in the From: field.
+
+   *  A Mediator MAY create an Author: field if one does not already
+      exist, and this new field's value MUST be identical to the value
+      of the From: field at the time the Mediator received the message
+      (and before the Mediator causes any changes to the From: field).
+
+4.  Discussion
+
+   The Author: header field, here, is intended for creation during
+   message generation or during mediation.  It is intended for use by
+   recipient MUAs, as they typically use the From: field.  In that
+   regard, it would be reasonable for an MUA that would normally
+   organize, filter, or display information based on the From: field to
+   give the Author: header field preference.
+
+   Original-From: is a similar header field referenced in [RFC5703].  It
+   is registered with IANA, which cites [RFC5703] as the controlling
+   source for the entry.  However, that document only has a minimal
+   definition for the field.  Also, the field is solely intended for use
+   by Mediators to preserve information from a modified From: field.
+   The current specification can be used during either origination or
+   mediation.
+
+   While the basic model of email header fields is highly extensible,
+   there well might be implementation and usability considerations for
+   carrying this field through to end users, such as via [IMAP].
+
+   Obviously, any security-related processing of a message needs to
+   distinguish the From: field from the Author: field and treat their
+   information accordingly.
+
+5.  Security Considerations
+
+   Any header field containing identification information is a source of
+   security and privacy concerns, especially when the information
+   pertains to content authorship.  Generally, the handling of the
+   Author: header field needs to receive scrutiny and care, comparable
+   to that given to the From: header field, but preferably not in a way
+   that defeats its utility.
+
+   Given the semantics of the Author: header field, it is easy to
+   believe that use of this field will create a new attack vector for
+   tricking end users.  However (and perhaps surprisingly), for all of
+   the real and serious demonstrations of users being tricked by
+   deceptive or false content in a message, there is no evidence that
+   problematic content in a header field, which is providing information
+   about message's author, directly contributes to differential and
+   problematic behavior by the end user.  (The presents an obvious
+   exercise for the reader to find credible, documented evidence.)
+
+6.  IANA Considerations
+
+   IANA has registered the Author: header field, per [RFC3864], in the
+   "Provisional Message Header Field Names" registry:
+
+   Header field name:  Author
+   Applicable protocol:  mail
+   Status:  Provisional
+   Author/Change controller:  Dave Crocker <dcrocker@bbiw.net>
+   Specification document(s):  RFC 9057
+
+7.  Experimental Goals
+
+   Given that the semantics of this field echo the long-standing From:
+   header field, the basic mechanics of the field's creation and use are
+   well understood.  Points of concern, therefore, are with possible
+   interactions with the existing From: field, anti-abuse systems, and
+   MUA behavior, along with basic market acceptance.  So the questions
+   to answer while the header field has experimental status are:
+
+   *  Is there demonstrated interest by MUA developers?
+
+   *  If MUA developers add this capability, is it used by authors?
+
+   *  Does the presence of the Author: field, in combination with the
+      From: field, create any operational problems, especially for
+      recipients?
+
+   *  Does the presence of the Author: field demonstrate additional
+      security issues?
+
+   *  Does the presence of the Author: field engender problematic
+      behavior by anti-abuse software, such as defeating its utility?
+
+8.  References
+
+8.1.  Normative References
+
+   [ABNF]     Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <https://www.rfc-editor.org/info/rfc5234>.
+
+   [Mail-Arch]
+              Crocker, D., "Internet Mail Architecture", RFC 5598,
+              DOI 10.17487/RFC5598, July 2009,
+              <https://www.rfc-editor.org/info/rfc5598>.
+
+   [Mail-Fmt] Resnick, P., Ed., "Internet Message Format", RFC 5322,
+              DOI 10.17487/RFC5322, October 2008,
+              <https://www.rfc-editor.org/info/rfc5322>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
+              Procedures for Message Header Fields", BCP 90, RFC 3864,
+              DOI 10.17487/RFC3864, September 2004,
+              <https://www.rfc-editor.org/info/rfc3864>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+8.2.  Informative References
+
+   [IMAP]     Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
+              4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
+              <https://www.rfc-editor.org/info/rfc3501>.
+
+   [RFC5703]  Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part
+              Tests, Iteration, Extraction, Replacement, and Enclosure",
+              RFC 5703, DOI 10.17487/RFC5703, October 2009,
+              <https://www.rfc-editor.org/info/rfc5703>.
+
+   [RFC733]   Crocker, D., Vittal, J., Pogran, K., and D. Henderson,
+              "Standard for the format of ARPA network text messages",
+              RFC 733, DOI 10.17487/RFC0733, November 1977,
+              <https://www.rfc-editor.org/info/rfc733>.
+
+Acknowledgements
+
+   The idea for this field was prompted by discussions in the IETF's
+   DMARC Working Group, with participation from: Benny Lyne Amorsen,
+   Kurt Anderson, Laura Atkins, Adrian Farrel, Murray S. Kucherawy, Mike
+   Hammer, John Levine, Alexey Melnikov, Jesse Thompson, and Alessandro
+   Vesely.
+
+Author's Address
+
+   Dave Crocker
+   Brandenburg InternetWorking
+
+   Email: dcrocker@bbiw.net