idnits 2.17.1 draft-zeilenga-email-seclabel-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 17, 2014) is 3469 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'FWS' is mentioned on line 254, but not defined -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Zeilenga 3 Internet-Draft A. Melnikov 4 Intended status: Informational Isode Limited 5 Expires: April 20, 2015 October 17, 2014 7 Security Labels in Internet Email 8 draft-zeilenga-email-seclabel-09 10 Abstract 12 This document describes a header field, SIO-Label, for use in 13 Internet Mail to convey the sensitivity of the message. This header 14 field which may carry a textual representation (a display marking) 15 and/or a structural representation (a security label) of the 16 sensitivity of the message. This document also describes a header 17 field, SIO-Label-History, for recording changes in the message's 18 label. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 20, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Relationship to Inline Sensitivity Markings . . . . . . . 3 56 1.2. Relationship to preexisting Security Label Header Fields 4 57 1.3. Relationship to Enhanced Security Services for S/MIME . . 4 58 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 59 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. The SIO-Label header field . . . . . . . . . . . . . . . . . 6 61 5. The SIO-Label-History header field . . . . . . . . . . . . . 9 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 66 8.2. Informative References . . . . . . . . . . . . . . . . . 13 67 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 69 1. Introduction 71 A security label, sometimes referred to as a confidentiality label, 72 is a structured representation of the sensitivity of a piece of 73 information. A security label can be used in conjunction with a 74 clearance, a structured representation of what information 75 sensitivities a person (or other entity) is authorized to access, and 76 a security policy to control access to each piece of information. 77 For instance, an email message could have a EXAMPLE CONFIDENTIAL 78 label, and hence requiring the sender and the receiver to have a 79 clearance granting access to EXAMPLE CONFIDENTIAL labeled 80 information. X.841 [X.841] provides a discussion of security labels, 81 clearances, and security policy. 83 A display marking is a textual representation of the sensitivity of a 84 piece of information. For instance, "EXAMPLE CONFIDENTIAL" is a 85 textual representation of the sensitivity. A security policy can be 86 used to generate display markings from security labels. Display 87 markings are generally expected to be prominently displayed whenever 88 the content is displayed. 90 Sensitivity-based authorization is used in networks which operate 91 under a set of information classification rules, such as in 92 government military agency networks. The standardized formats for 93 security labels, clearances, and security policy and associated 94 authorization models are generalized and can be used in non- 95 government deployments where appropriate. 97 Security labels may also be used for purposes other than 98 authorization. In particular, they may be used simply to convey the 99 sensitivity of a piece information. The security label could be 100 used, for instance, to organize content in a content store. 102 This document describes a protocol for conveying the sensitivity of a 103 electronic mail message [RFC5322], as a whole. In particular, this 104 document describes a header field, SIO-Label, to carry a security 105 label, a display marking, and display colors. This document also 106 describes a header field, SIO-Label-History, to record changes in the 107 message's security label. 109 This protocol is based in part upon Security Labels in XMPP [XEP258] 110 protocol. 112 1.1. Relationship to Inline Sensitivity Markings 114 In environments requiring messages to be marked with an indication of 115 their sensitivity, it is common to place a textual representation of 116 the sensitivity, a display marking, within the body to the message 117 and/or in the Subject header field. For instance, the authors often 118 receives messages of the form: 120 To: author ; 121 From: Some One ; 122 Subject: the subject (UNCLASSIFIED) 124 UNCLASSIFIED 126 Text of the message. 128 UNCLASSIFIED 130 Typically, when placed in the body of the message, the marking is 131 inserted into the content such that it appears as the first line(s) 132 of text of the body of the message. This is known as a FLOT (First 133 Line(s) of Text) marking. The marking may or may not be surrounded 134 by other text indicating the marking denotes the sensitivity of the 135 message. A FLOT may also accompanied by a LLOT (Last Line(s) of 136 Text) marking. The message above contains a two-line FLOT and a two- 137 line LLOT (in both cases, a line providing the marking and a empty 138 line between the marking and the original content). 140 Typically, when placed in the Subject of the message, the marking is 141 inserted before or after the original subject field contents 142 surrounded with by parentheses or the like, and/or separated from the 143 content by white space. 145 The particulars syntax and semantics of inline sensitivity markings 146 is generally a local matter. This hinders interoperability within an 147 organization wanting to take actions based upon these markings, and 148 hinders interoperability between cooperating organizations wanting to 149 usefully share sensitivity information 151 The authors expect such markings to be continued to widely used, 152 especially in absence of ubiquitous support for a standardized header 153 field indicating the sensitivity of the message. 155 The authors hope that through the use of formally-specified header 156 field, interoperability within organizations and between 157 organizations can be improved. 159 1.2. Relationship to preexisting Security Label Header Fields 161 A number of non-standard header fields, such as the X-X411 field, are 162 used to carry a representation of the sensitivity of the message, 163 whether a structured representation or textual representation. 165 The authors hope the use of preexisting (non-standard) header fields 166 will be replaced, over time, with use of the header field described 167 in this document. 169 1.3. Relationship to Enhanced Security Services for S/MIME 171 Enhanced Security Services for S/MIME (ESS) [RFC2634] provides, 172 amongst other services, signature services "for content integrity, 173 non-repudiation with the proof of origin, and [securely] binding 174 attributes (such as a security label) to the original content. 176 While it may be possible to utilize the protocol described in this 177 document concurrently with ESS, this protocol should generally be 178 viewed as an alternative to ESS. 180 It is noted that in ESS, the security label applies to MIME [RFC2045] 181 content, where in this protocol the label applies to the message as a 182 whole. 184 It is also noted that in ESS, security labels are securely bound to 185 the MIME content through the use of digital signatures. This 186 protocol does not provide message signing services, and hence does 187 not provide securely binding the label to the message, or for content 188 integrity, or for non-repudiation of the proof of origin. 190 This protocol is designed for situations/environments where message 191 signing is not necessary to provide sufficient security. 193 2. Conventions Used in This Document 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in [RFC2119]. 199 The formal syntax specifications in this document use the Augmented 200 Backus-Naur Form (ABNF) as described in [RFC5234]. 202 The term "base64 encoding" is used to refer to the Base 64 encoding 203 defined in Section 4 of [RFC4648]. The term "BER encoding" is used 204 to refer to encoding per the Basic Encoding Rules (BER) as defined in 205 [X.690]. 207 3. Overview 209 A Mail User Agent (MUAs) originating a message can, if so configured, 210 offer the user with a menu of sensitivities to choose from and, upon 211 selection, insert the display marking, foreground and background 212 colors, and security label parameters associated with that selection 213 into the SIO-Label header field of the message. 215 Mail Submission Agents (MSAs), Mail Transfer Agents (MTAs), and Mail 216 Delivery Agents (MDAs) then can, if so configured, use the provided 217 (or lack thereof) sensitivity information in determining whether to 218 accept, forward, or otherwise act on the message as submitted. These 219 agents, here after referred to as Service Agents (SAs), can, if so 220 configured, modify the sensitivity information of the message, such 221 as replacing the security label and/or display marking with an 222 equivalent representations of the sensitivity of the message. SAs 223 which add or modify or delete the SIO-Label header field SHOULD add 224 an SIO-Label-History header. 226 Receiving MUAs which implement this extension SHALL, when displaying 227 the message, also prominently display the marking, if any, conveyed 228 in the SIO-Label header field or, if policy aware and configured to 229 display locally generated markings, a marking generated by the 230 conveyed label and the governing policy. It is also desirable to 231 display this marking in listings of messages. In the case the 232 conveyed marking is displayed, marking SHOULD be displayed using the 233 foreground and background colors conveyed in the header field. In 234 the case the marking was generated from conveyed label and the 235 governing policy, the marking SHOULD be displayed using the 236 foreground and background colors conveyed by the governing policy. 238 While MUAs are not expected to make authorization decisions based 239 upon values of the SIO-Label header field, MUAs can otherwise use the 240 provided (or lack thereof) sensitivity information in determining how 241 to act on the message. For instance, the MUA may organize messages 242 in its store of messages based upon the content of this header field. 244 4. The SIO-Label header field 246 The header field name is "SIO-Label" and its content is a set of key/ 247 value pairs, each referred to as a parameter. 249 Formal header field syntax: 251 sio-label = "SIO-Label:" [FWS] sio-label-parm-seq [FWS] CRLF 253 sio-label-parm-seq = sio-label-parm 254 [ [FWS] ";" [FWS] sio-label-parm-seq ] 256 sio-label-parm = parameter 258 where the parameter production is defined in [RFC2231], the FWS 259 production are defined in [RFC5322], and the CRLF production is 260 defined in [RFC5234]. It is noted that the RFC 2231 productions rely 261 on [RFC0822] ABNF which implicitly allows for white space in certain 262 cases. In particular, white space is implicitly allowed in the 263 parameter production immediately before and after the "=". It is 264 also noted that RFC 2231 allows for quoted-string values (of the 265 parameter production) of substantial length and for string characters 266 outside of US-ASCII, or other such cases. Implementors should 267 consult the referenced specifications for specifics. 269 The "marking" parameter is a display string for use by 270 implementations which are unable or unwilling to utilize the 271 governing security policy to generate display markings. The 272 "marking" parameter SHOULD generally be provided in SIO-Label header 273 fields. It ought only be absent where an SA relies on other SA to 274 generate the marking. 276 The "fgcolor" and "bgcolor" parameters are tokens restricted to color 277 production representing the foreground and background colors, 278 respectively, for use in colorizing the display marking string. 279 Their values are RGB colors in hexadecimal format (e.g., "#ff0000"), 280 or one of the CSS color names (e.g., "red") given in named-color type 281 below (the 16 HTML4 colors + "orange") [CSS3-Color]. The default 282 foreground color is black. The default background is white. The 283 "fgcolor" and "bgcolor" parameters SHALL be absent if the marking 284 parameter is absent. The HEXDIG production below is defined in 285 [RFC5234] 287 Formal color syntax: 289 color = hex-color / named-color 291 hex-color = "#" 6HEXDIG ; Hex encoded RGB 293 named-color = 294 "aqua" / 295 "black" / 296 "blue" / 297 "fuschia" / 298 "gray" / 299 "green" / 300 "lime" / 301 "maroon" / 302 "navy" / 303 "olive" / 304 "purple" / 305 "red" / 306 "silver" / 307 "teal" / 308 "white" / 309 "yellow" / 310 "orange" ; named colors 312 The "type" parameter is a quoted-string containing the string ":ess" 313 or the string ":x411" or the string ":xml" or a URI [RFC3986] 314 denoting the type and encoding of "label" parameter. The "label" 315 parameter value is a quoted string. The "type" parameter SHALL be 316 present if the "label" parameter is present. The "label" parameter 317 SHALL be present if the "type" parameter is present. The absence of 318 the "type" and "label" parameters indicates the message is handled, 319 where sensitivity-based authorization is performed, under default 320 handling rules (e.g., as if no SIO-Label was present). 322 The string ":ess" indicates the "label" parameter value is the base64 323 encoding of the BER encoding of an ESS security label [RFC2634]. 325 ESS Label Example: 327 SIO-Label: marking="EXAMPLE CONFIDENTIAL"; 328 fgcolor=black; bgcolor=red; 329 type=":ess"; label="MQYGASkCAQM=" 331 The string ":x411" indicates the "label" parameter value is the 332 base64 encoding of the BER encoding of an X.411 security label 333 [X.411]. 335 X.411 Label Example: 337 SIO-Label: marking="EXAMPLE CONFIDENTIAL"; 338 fgcolor=black; bgcolor=red; 339 type=":x411"; label="MQYGASkCAQM=" 341 The string ":xml" indicates the "label" parameter value is the base64 342 encoding of a security label represented using [XML]. The XML prolog 343 SHOULD be absent unless specifically required (such as when the 344 character encoding is not UTF-8). The particular flavor of security 345 label representation is indicated by the root element name and its 346 name space. 348 XML Label Example: 350 SIO-Label: marking="EXAMPLE CONFIDENTIAL"; 351 fgcolor=black; bgcolor=red; 352 type=":xml"; 353 label*0="PFNlY0xhYmVsIHhtbG5zPSJodHRwOi8vZXhhbX"; 354 label*1="BsZS5jb20vc2VjLWxhYmVsLzAiPjxQb2xpY3lJ"; 355 label*2="ZGVudGlmaWVyIFVSST0idXJuOm9pZDoxLjEiLz"; 356 label*3="48Q2xhc3NpZmljYXRpb24+MzwvQ2xhc3NpZmlj"; 357 label*4="YXRpb24+PC9TZWNMYWJlbD4="; 359 where XML label, with new lines and white space added for 360 readability, is: 362 363 364 3 365 367 The ":ess" and ":x411" formats SHOULD be used represent ESS or X.411 368 security labels, respectively, instead of any direct XML 369 representation of these formats. 371 The header field SHALL minimally contain a "marking" parameter or 372 contain both the "type" and "label" parameters. 374 This header field may be extended to include additional parameters by 375 future document formally updating (or replacing) this document. 376 Implementations SHOULD ignore additional parameters they do not 377 recognize. This recommendation is not a mandate so as to allow 378 agents to process a message with an SIO-header field with 379 unrecognized header fields differently than a message less those 380 unrecognized header fields. 382 Each message SHALL contain zero or one SIO-Label header field. 384 Extended Example: 386 SIO-Label: marking*=us-ascii'en'EXAMPLE%20CONFIDENTIAL; 387 fgcolor = black ; bgcolor = red ; 388 type=":ess"; label*0="MQYG"; 389 label*1="ASkCAQM=" 391 The Extended Example is equivalent to the ESS Label Example above. 393 5. The SIO-Label-History header field 395 Any service agent MAY record label changes in an SIO-Label-History 396 header. This header field is intended to provide trace information 397 (and only trace information). For instance, it can be used to record 398 the label change when an SIO-Label header is added, modify, or 399 deleted by an service agent. This field use can be used in other 400 sitations as well. For instance, an X.400 to Internet messagging 401 gateway can use this header field to record labeling changes made 402 while translating a message. 404 The formal syntax of the SIO-Label-History header is the same as the 405 SIO-Label, but with parameters as discussed here 407 change - one of "add", "replace", "delete". 409 changed-by - contains a string identify the agent, commonly the 410 agent's fully qualified domain name. 412 changed-at - contains a date-time production, as specified in 413 [RFC5322] representing the date and time the header was rewritten. 415 changed-comment - contains a string containing a comment. 417 marking, fgcolor, bgcolor, type, label - records the message's label 418 information prior to add, modify, delete of SIO-Label, using same 419 parameter syntax used of SIO-Label. These parameters are absent when 420 the change action is add. 422 new-marking, new-fgcolor, new-bgcolor, new-type, new-label - records 423 the message's label information after add, modify, delete of SIO- 424 Label, using same parameter syntax used for corresponding SIO-Label 425 parameters. These parameters are absent when the change type is 426 delete. 428 The header field SHALL minimally contain the "change", "changed-by", 429 and "changed-at" parameters. 431 This header field can be extended to include additional parameters by 432 future document formally updating (or replacing) this document. 434 Each message can contain zero or more SIO-Label-History header 435 fields. All SIO-Label-History header fields should immediately 436 follow the the SIO-Label header field, if any, and be grouped 437 together. Additional SIO-Label-History header fields should be added 438 immediately preceeding any existing SIO-Label-History header fields. 440 SIO Label History add, modify, delete example: 442 SIO-Label-History: marking="EXAMPLE CONFIDENTIAL"; 443 fgcolor=black; bgcolor=red; 444 type=":xml"; 445 label*0="PFNlY0xhYmVsIHhtbG5zPSJodHRwOi8vZXhhbX"; 446 label*1="BsZS5jb20vc2VjLWxhYmVsLzAiPjxQb2xpY3lJ"; 447 label*2="ZGVudGlmaWVyIFVSST0idXJuOm9pZDoxLjEiLz"; 448 label*3="48Q2xhc3NpZmljYXRpb24+MzwvQ2xhc3NpZmlj"; 449 label*4="YXRpb24+PC9TZWNMYWJlbD4="; 450 change=delete; 451 changed-by="delete.example.com"; 452 changed-at="18 Feb 2013 9:24 PDT"; 453 changed-comment="delete" 454 SIO-Label-History: marking="EXAMPLE CONFIDENTIAL"; 455 fgcolor=black; bgcolor=red; 456 type=":ess"; label="MQYGASkCAQM="; 457 new-marking="EXAMPLE CONFIDENTIAL"; 458 new-fgcolor=black; new-bgcolor=red; 459 new-type=":xml"; 460 new-label*0="PFNlY0xhYmVsIHhtbG5zPSJodHRwOi8vZXhhbX"; 461 new-label*1="BsZS5jb20vc2VjLWxhYmVsLzAiPjxQb2xpY3lJ"; 462 new-label*2="ZGVudGlmaWVyIFVSST0idXJuOm9pZDoxLjEiLz"; 463 new-label*3="48Q2xhc3NpZmljYXRpb24+MzwvQ2xhc3NpZmlj"; 464 new-label*4="YXRpb24+PC9TZWNMYWJlbD4="; 465 change=replace; 466 changed-by="modify.example.net"; 467 changed-at="18 Feb 2013 8:24 PDT"; 468 changed-comment="replaced with XML variant" 469 SIO-Label-History: new-marking="EXAMPLE CONFIDENTIAL"; 470 new-fgcolor=black; new-bgcolor=red; 471 new-type=":ess"; new-label="MQYGASkCAQM="; 472 change=add; 473 changed-by="add.example.net"; 474 changed-at="18 Feb 2013 7:24 PDT"; 475 changed-comment="added label" 477 6. IANA Considerations 479 Registration of the the SIO-Label and SIO-Label-History header fields 480 in the "Provisional Message Header Field Registry" is requested in 481 accordance with [RFC3864]. 483 Header field name: SIO-Label 484 Applicable protocol: mail [RFC5322] 485 Status: provisional 486 Author/change controller: Kurt Zeilenga (kurt.zeilenga@isode.com) 487 Specification document(s): this document 489 Header field name: SIO-Label-History 490 Applicable protocol: mail [RFC5322] 491 Status: provisional 492 Author/change controller: Kurt Zeilenga (kurt.zeilenga@isode.com) 493 Specification document(s): this document 495 7. Security Considerations 497 Sensitive information should be appropriately protected (whether 498 labeled or not). For email messages, it is generally appropriate for 499 the sending entity to authenticate the receiving entity and to 500 establish transport level security, including both data integrity and 501 data confidential protective services. Where a receiving entity to 502 make authorization decisions based upon assertions of the sending 503 entity, including assertions of identity, it is generally appropriate 504 for the receiving entity to authenticate the sending entity. 506 This document provides a facility for expressing the sensitivity of 507 an email message. The mere expression of actual sensitivity of a 508 generally does not elevate the sensitivity of the message, however 509 expressions of sensitivities can themselves be regarded as sensitive 510 information. For instance, a marking of "BLACK PROJECT RESTRICTED" 511 could disclose the existence of a sensitivity project. 513 The SIO-Label header field expresses the sensitivity of the whole 514 message, including the header and body. This document does not 515 provide a means to express the sensitivity of portions of an email 516 message, such as the possibly different sensitivities of various MIME 517 parts that the message may be composed of. This approach used in 518 this favors simplicity and ease of use of a single expression of 519 sensitivity over the complexity and difficultly of use of portion 520 marking and labeling. 522 The expressed sensitivity can be used in determining how to handle a 523 message. For instance, the value of the SIO-Label header (or lack 524 thereof) field can be used to determine if it appropriate to be 525 forwarded to a particular entity and, if so, what the minimum 526 security services are that which ought to be used in the forwarding 527 exchange. The mechanism for determining how to handle a message 528 based expressed sensitivity is beyond the scope of this document. 530 The actual content may be more or less sensitivity than indicated by 531 the security label. Agents should avoid lowering security 532 requirements for message exchange with a particular entity based upon 533 conveyed sensitivity. 535 This protocol does not itself provide message signing services, such 536 a used in providing message integrity protection, non-repudiation, 537 and binding of attributes, such the security label to the message. 538 While it possible that this protocol could be used with a general 539 message signing service, this document does not detail such use. 541 While security label and display marking parameters are expected to 542 express the same sensitivity, nothing in this specification ensures 543 that the security label and display marking values express the same 544 sensitivity. For instance, an MUA could submit a message which 545 contains security label which expresses one sensitivity and a display 546 marking a different sensitivity, and by doing so, possibly cause an 547 SA to inappropriately handle the message. It is generally 548 appropriate for each SA making use of the SIO-Label values to 549 determine if the security label and display marking values express 550 the same sensitivity and, if not, take appropriate action (such as 551 rejecting the message). 553 This document also provides a facility for expressing changes to the 554 label of a message. This is intended to be used for trace purposes 555 only. It is noted that this SIO-Label-History header field can 556 include sensitive information and, as such, can be removed from the 557 message where its inclusion would result in an inapprorpriate 558 information disclosure. 560 8. References 562 8.1. Normative References 564 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 565 Requirement Levels", BCP 14, RFC 2119, March 1997. 567 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 568 Word Extensions: 569 Character Sets, Languages, and Continuations", RFC 2231, 570 November 1997. 572 [RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 573 2634, June 1999. 575 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 576 Procedures for Message Header Fields", BCP 90, RFC 3864, 577 September 2004. 579 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 580 Resource Identifier (URI): Generic Syntax", STD 66, RFC 581 3986, January 2005. 583 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 584 Encodings", RFC 4648, October 2006. 586 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 587 October 2008. 589 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 590 Specifications: ABNF", STD 68, RFC 5234, January 2008. 592 [XML] Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F., 593 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth 594 Edition)", World Wide Web Consortium Recommendation REC- 595 xml-20081126, November 2008, 596 . 598 [X.411] International Telephone and Telegraph Consultative 599 Committee, "Message Handling Systems (MHS) - Message 600 Transfer System: Abstract Service Definition and 601 Procedures", CCITT Recommendation X.411, June 1999. 603 [X.690] International Telephone and Telegraph Consultative 604 Committee, "ASN.1 encoding rules: Specification of basic 605 encoding Rules (BER), Canonical encoding rules (CER) and 606 Distinguished encoding rules (DER)", CCITT Recommendation 607 X.690, July 2002. 609 [CSS3-Color] 610 Celik, T. and C. Lilley, "CSS3 Color Module", World Wide 611 Web Consortium CR CR-css3-color-20030514, May 2003, 612 . 614 8.2. Informative References 616 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 617 text messages", STD 11, RFC 822, August 1982. 619 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 620 Extensions (MIME) Part One: Format of Internet Message 621 Bodies", RFC 2045, November 1996. 623 [X.841] International Telephone and Telegraph Consultative 624 Committee, "Security information objects for access 625 control", CCITT Recommendation X.841, October 2000. 627 [XEP258] Zeilenga, K., "XEP-0258: Security Labels in XMPP", XEP 628 XMPP Extension Protocols, August 2011. 630 Appendix A. Acknowledgements 632 The authors appreciate the review, comment, and text provided by 633 community members, including Dave Cridland, Brad Hards, Russ Housley, 634 Steve Kille, Graeme Lunt, Alan Ross, Jim Schaad, and David Wilson. 636 Authors' Addresses 638 Kurt Zeilenga 639 Isode Limited 641 EMail: Kurt.Zeilenga@isode.com 643 Alexey Melnikov 644 Isode Limited 645 14 Castle Mews 646 Hampton, Middlesex TW12 2NP 647 UK 649 EMail: Alexey.Melnikov@isode.com