diff options
Diffstat (limited to 'doc/rfc/rfc7444.txt')
| -rw-r--r-- | doc/rfc/rfc7444.txt | 899 |
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] + |