GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc7444

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7444.txt · Last modified: 2015/02/18 22:46 (external edit)