xeps/xep-0258.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM 'xep.ent'>
  <!ENTITY LABEL "&lt;label/&gt;">
  <!ENTITY CATALOG "&lt;catalog/&gt;">
  <!ENTITY SECURITYLABEL "&lt;securitylabel/&gt;">
  <!ENTITY DISPLAYMARKING "&lt;displaymarking/&gt;">
  <!ENTITY EQUIVALENTLABEL "&lt;equivalentlabel/&gt;">
  <!ENTITY HEADLINE "&lt;headline/&gt;">
  <!ENTITY IDENTITY "&lt;identity/&gt;">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
  <title>Security Labels in XMPP</title>
  <abstract>This document describes the use of security labels in XMPP.  The document
    specifies how security label metadata is carried in XMPP, when this metadata
    should or should not be provided, and how the metadata is to be processed.</abstract>
  &LEGALNOTICE;
  <number>0258</number>
  <status>Experimental</status>
  <type>Standards Track</type>
  <sig>Standards</sig>
  <approver>Council</approver>
  <dependencies>
    <spec>XMPP Core</spec>
    <spec>XEP-0001</spec>
  </dependencies>
  <supersedes/>
  <supersededby/>
  <shortname>sec-label</shortname>
  <author>
    <firstname>Kurt</firstname>
    <surname>Zeilenga</surname>
    <email>Kurt.Zeilenga@Isode.COM</email>
    <jid>Kurt.Zeilenga@Isode.COM</jid>
  </author>
  <revision>
        <version>0.7</version>
        <date>2010-11-09</date>
        <initials>kdz</initials>
        <remark><p>Illustrate XEP 45 security label room configuration.  Make clarifications and m inor editorial changes.</p></remark>
  </revision>
  <revision>
    <version>0.6</version>
    <date>2010-07-30</date>
    <initials>kdz</initials>
    <remark><p>Extend catalog handling.  Minor editorial changes.</p></remark>
  </revision>
  <revision>
    <version>0.5</version>
    <date>2009-07-27</date>
    <initials>kdz</initials>
    <remark><p>Remove &LABEL;/&EQUIVALENTLABEL; type= attribute. Clarify label catalog discovery.  Clarify syntax of selector= attribute.</p></remark>
  </revision>
  <revision>
    <version>0.4</version>
    <date>2009-07-23</date>
    <initials>kdz</initials>
    <remark><p>Update label catalogs to include user input selector.</p></remark>
  </revision>
  <revision>
    <version>0.3</version>
    <date>2009-03-20</date>
    <initials>kdz</initials>
    <remark><p>Add text regarding default bg/fg colors.  Correct examples.</p></remark>
  </revision>
  <revision>
    <version>0.2</version>
    <date>2009-03-10</date>
    <initials>kdz</initials>
    <remark><p>Reworked discovery and various updates.</p></remark>
  </revision>
  <revision>
    <version>0.1</version>
    <date>2009-01-05</date>
    <initials>psa</initials>
    <remark><p>Initial published version.</p></remark>
  </revision>
  <revision>
    <version>0.0.081203</version>
    <date>2008-12-03</date>
    <initials>kdz</initials>
    <remark><p>Initial draft.</p></remark>
  </revision>
</header>

<section1 topic='Introduction' anchor='intro'>
  <p>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 is used in conjunction with a clearance, a structured representation of what
     information sensitivities a person (or other entity) is authorized to access, and a security
     policy to control access to each piece of information.  For instance, message could be
     labeled as "SECRET", and hence requiring the sender and the receiver to each have a
     clearance granting access to "SECRET" information.  &X.841; provides a discussion of
     security labels, clearances, and security policy.</p>
  <p>Sensitivity-based authorization is used in networks which operate under a set of
     information classification rules, such as in government agency networks.  The
     standardized formats for security labels, clearances, and security policy are
     generalized and do have application in non-government networks.</p>
  <p>This document describes the use of security labels in &xmpp;.  The document specifies
     how security label metadata is carried in XMPP.  It standardizes a mechanism for
     carrying ESS Security Labels in XMPP, as well as provides for use of other label
     formats.  ESS Security Labels are specified in &rfc2634;.  ESS Security Labels are
     commonly used in conjunction with &X.500; clearances and either X.841 or &SDN.801c;
     security policies.</p>
  <example caption="Message with ESS Security Label"><![CDATA[
<message to='romeo@example.net' from='juliet@example.com/balcony'>
    <body>This content is classified.</body>
    <securitylabel xmlns='urn:xmpp:sec-label:0'>
        <displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking>
        <label><esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'>
            MQYCAQQGASk=
        </esssecuritylabel></label>
    </securitylabel>
</message>
  ]]></example>
  <example caption="Message with IC-ISM Label"><![CDATA[
<message to='romeo@example.net' from='juliet@example.com/balcony'>
    <body>This content is classified.</body>
    <securitylabel xmlns='urn:xmpp:sec-label:0'>
        <displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking>
        <label><icismlabel xmlns='http://example.gov/IC-ISM/0' classification='S'
            ownerProducer='USA'/></label>
    </securitylabel>
</message>
  ]]></example>
  <p>Note: The &IC-ISM; label example is for <em>illustrative purposes only</em>.</p>
  
  <p>The document details when security label metadata should or should not be provided, and how
     this metadata is to be processed.</p>

  <p>This document does not provide:
     <ul>
     <li>any mechanism for a client might discover the security policy
        enforce at its home server, or any other server;</li>
     <li>any mechanism for a client to discover the user's clearance,
         or the clearance of associated with any resource; nor</li>
     <li>any administrative mechanism for a client to configure
        configure policy, clearance, and labels of any resource.</li>
     </ul>

  Such mechanisms may be introduced in subsequent documents.</p>

  <p>This document does discuss how one might securely bind a security label to a stanza.
	It is expected a subsequent document will tackle this topic.</p>
</section1>

<section1 topic='Discovering Feature Support' anchor='disco'>
  <p>An entity (client or server) which supports the XMPP Security Label protocol
     MUST report that fact by including a service discovery feature of
	 "<tt>urn:xmpp:sec-label:0</tt>" in response to a &xep0030; information request.</p>
  <p>Clients wishing to include a XMPP Security Label element in any stanza they
	 generate SHOULD determine if their server supports the XMPP Security Label protocol.
	 If their server does not support XMPP Security Label, the client SHOULD NOT generate
     XMPP Security Labels as the server not supporting this protocol will generally
	 ignore XMPP Security Labels as they would any other unrecognized element.</p>
  <p>As each service domain may have different support for security labels, servers
     should advertise and clients should perform appropriate discovery lookups on a
     per service basis.</p>
  <example caption="Service Discovery information request"><![CDATA[
<iq type='get'
    from='user@example.com/Work'
    to='example.com'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
  ]]></example>
  <example caption="Service Discovery information response"><![CDATA[
<iq type='result'
    from='example.com'
    to='user@example.com/Work'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='urn:xmpp:sec-label:0'/>
    ...
  </query>
</iq>
  ]]></example>
</section1>

<section1 topic='Protocol' anchor='protocol'>
  <p>An element, &SECURITYLABEL;, is defined to carry security label metadata.  This metadata
     includes a security label, zero or more equivalent security labels, and optionally display
     marking data.</p>
  <example caption="Labeled Message"><![CDATA[
<message to='romeo@example.net' from='juliet@example.com/balcony'>
    <body>This content is classified.</body>
    <securitylabel xmlns='urn:xmpp:sec-label:0'>
        <displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking>
        <label>
            <esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'
                >MQYCAQIGASk=</esssecuritylabel>
        </label>
        <equivalentlabel>
            <esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'
                >MRUCAgD9DA9BcXVhIChvYnNvbGV0ZSk=</esssecuritylabel>
        </equivalentlabel>
    </securitylabel>
</message>
  ]]></example>
  <p>The security label metadata is carried in an &SECURITYLABEL; element.
     The &SECURITYLABEL; element which contains one and only one &LABEL; element,
     zero or more &EQUIVALENTLABEL; elements, and an optional &DISPLAYMARKING; element.</p>
  <p>The &LABEL; provides the primary security label.  It is commonly issued
     by the sender under the security policy of that they and their home
     server operating under.  The &LABEL; contains either a single element
     representing the primary security label or is empty to indicate use of
     a default.</p>
  <p>Each &EQUIVALENTLABEL; represents an equivalent security label under
     other policies.  Each &EQUIVALENTLABEL; contains a single element
     representing the equivalent label.  This element might be used when
     a recepient is known to hold a clearance under a different policy
     than the sender.</p>
  <p>The &DISPLAYMARKING; element contains a display string for use by
     implementations which are unable to utilize the applicable security policy
     to generate display markings.  The element may optionally contain two
     attributes, <tt>fgcolor=</tt> and <tt>bgcolor=</tt>, whose values are HTML
     color strings (e.g., '<tt>red</tt>' or '<tt>#ff0000</tt>'), for use in
     colorizing the display marking.  The <tt>fgcolor=</tt> default is <tt>black</tt>.
     The <tt>bgcolor=</tt> default is <tt>white</tt>.
  </p>
</section1>

<section1 topic='Label Catalog Discovery' anchor='label-catalog'>
    <p>A client can request a catalog for a particular JID by sending
       a catalog discovery request to the client's server.  Where the JID
       is hosted by some other server, the client's server is expected to
       produce a suitable catalog (or fail the request).  The client's server
       may, as needed, query catalogs from other servers in order to
       fulfill the client's request.</p>
    <p>While this specification does not preclude a client from directing
       a catalog request elsewhere, it is noted that catalog returned by
       a party other than its server may not be directly useable by the
       client.  For instance, the client's server might require a particular
       only-locally-known label be used in messages to a particular remote
       JID.</p>
    <p>It is RECOMMENDED the server publish catalogs of security label
       for use by clients.</p>
	<p>If catalog is restrictive, as indicated by the restrict attribute
	   with value of true, the client SHOULD use one of the labels
	   (or no label) offered by the catalog.</p>
    <p>One and only one of the items may have a default attribute with
	   value of true.  The client should default the label selection to
	   this item in cases where the user has not selected an item.</p>
	<p>An item may have no label.  Such an item offers a choice of
	   sending a stanza without a label.</p>
    <p>Each catalog provided should only contain labels for which the client
       is allowed to use (based upon the user's authorization) in a particular
       context (such as in chatroom).  A catalog may not be include the
       complete set of labels available for the use by the client in the
       context.</p>
    <blockquote>Note: the single catalog per context approach used here
       is likely inadequate in enviroments where there are a large number
       of labels in use.  It is expected that a more sophisticated approach
       will be introduced in a subsequent revision of this
       specification.</blockquote>
    <p>As each service domain may have different support for security labels,
       servers should advertise and clients should perform appropriate
       discovery lookups on a per service basis.</p>
    <p>To indicate the support for label catalog discovery, a server
       advertises the <tt>urn:xmpp:sec-label:catalog:2</tt> feature.
       The following pair of examples illustrates this feature discovery.</p>
    <p>Items in the catalog may contain a selector attribute.  The
       value of this attribute represents the item's placement in a
       hierarchical organization of the items.  If one item has a selector
       attribute, all items should have a selector item. The value of the selector
       attribute conforms to the selector-value ABNF production:
<blockquote>
<![CDATA[
selector-value = (<item>"|")*<item>
]]>
</blockquote>
    </p>
    <p>where &lt;item&gt; is a sequence of characters not including "|".</p>
    <p>A value of "X|Y|Z" indicates that this item is "Z" in the
       the "Y" subset of the "X" subset of items.  This information may
       be used, for instance, in generating label selection menus in
       graphical user interfaces.</p>
    <blockquote>Note: use of unnecessarily deep hierarchies should be
	avoided.</blockquote>
    <example caption="Label Catalog Feature Discovery request"><![CDATA[
<iq type='get'
    to='example.com'
    from='user@example.com/Work'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
  ]]></example>
  <example caption="Label Information Feature Discovery response"><![CDATA[
<iq type='result'
    from='example.com'
    to='user@example.com/Work'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='urn:xmpp:sec-label:catalog:2'/>
    ...
  </query>
</iq>
  ]]></example>
  
    <p>The following example pair illustrates catalog discovery.  Note that client directs the &IQ; to its server regardless of which catalog it requests (via the to= attribute of in &CATALOG; element).</p>

    <example caption="Label Catalog request"><![CDATA[
<iq to='example.com' type='get' id='cat1'>
  <catalog xmlns='urn:xmpp:sec-label:catalog:2' to='example.com'/>
</iq>
  ]]></example>

     <example caption="Label Catalog Get response"><![CDATA[
<iq type='result' to='user@example.com/Work' id='cat1'>
  <catalog xmlns='urn:xmpp:sec-label:catalog:2'
      to='example.com' name='Default'
      desc='an example set of labels'
	  restrict='false'>
	<item selector="Classified|SECRET">
            <securitylabel xmlns='urn:xmpp:sec-label:0'>
                <displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking>
                <label>
                    <esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'
                        >MQYCAQQGASk=</esssecuritylabel>
                </label>
            </securitylabel>
	</item>
	<item selector="Classified|CONFIDENTIAL">
            <securitylabel xmlns='urn:xmpp:sec-label:0'>
                <displaymarking fgcolor='black' bgcolor='navy'>CONFIDENTIAL</displaymarking>
                <label>
                    <esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'
                        >MQYCAQMGASk</esssecuritylabel>
                </label>
            </securitylabel>
	</item>
	<item selector="Classified|RESTRICTED">
            <securitylabel xmlns='urn:xmpp:sec-label:0'>
                <displaymarking fgcolor='black' bgcolor='aqua'>RESTRICTED</displaymarking>
                <label>
                    <esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'
                        >MQYCAQIGASk=</esssecuritylabel>
                </label>
            </securitylabel>
	</item>
	<item selector="UNCLASSIFIED" default="true"/>
  </catalog>
</iq>
  ]]></example>

</section1>

<section1 topic='Use in XMPP' anchor='xmpp-use'>
  <p>The sensitivity-based access control decisions discussed herein are to be
     made independently of other access control decisions or other facilities.
     That is, the sensitivity-based access control decisions are not conditional
     on other factors.</p>
  <p>It is intended that &SECURITYLABEL; elements are only used as prescribed by
     this document, or other formal specifications.  Any other use of
     &SECURITYLABEL; SHOULD be viewed as a protocol violation.  The stanza SHOULD
     be discarded with, if approrpriate, an error response.  Such error responses
     SHOULD NOT include content from the violating stanza, excepting that
     necessary to well-formed error responses.</p> 
  <p>When use of a &SECURITYLABEL; element is prescribed, that use is RECOMMENDED.
     Absence of a &SECURITYLABEL; element implies the stanza has the default label
     as specified in the governing security policy.  Given that the governing
     policy may not specify a default label, hence denying access to the stanza,
     supporting clients SHOULD provide a &SECURITYLABEL; element where prescribed.</p>
  <p>Typically, a client would allow the user to choose populate the
     &SECURITYLABEL; from one of from a small set of security labels selections
     known to it (through configuration and/or discovery and/or other means),
     such as from a pull-down menu.   That selection would include appropriate
     values for the &LABEL;, &DISPLAYMARKING;, and &EQUIVALENTLABEL; elements.</p>
  <p>A policy-aware client may provide the user with an interface allowing the
     user to produce custom labeling data for inclusion in this set.  A
     policy-aware client SHOULD preclude the user from producing &LABEL; values
     which the user's own clearance does not grant access to, and SHOULD preclude
     sending any label which the user's own clearance does not grant access to.
     Each &EQUIVALENTLABEL; value, if any, MUST be equivalent under an equivalent
     policy to the &LABEL;.  The &DISPLAYMARKING; element SHOULD be set the
     display marking prescribed for the &LABEL; under the governing policy, or,
     if the governing policy prescribes no display marking for the &LABEL;,
     absent.</p>
  <p>A client which receives a stanza with &SECURITYLABEL; element is to promiently
     display the &DISPLAYMARKING; value.   A policy-aware may alternatively
     promiently display the marking for the &LABEL; prescribed by the governing
     policy.</p>
  <p>Each server is expected to make a number of sensitivity-based authorization
     decisions. Each decision is made by evaluating an Access Control Decision
     Function (ACDF) with a governing policy, a clearance, and a security label.
     The ACDF yields either <em>Grant</em> or <em>Deny</em>.</p>
  <p>If the user holds a valid clearance (known to the server) under the
     governing policy, the clearance input is the user's clearance.  Otherwise,
     if the governing policy provides a default clearance, the clearance input
     is the default clearance. Otherwise, the clearance input is the nil clearance.
     The nil clearance is a clearance for which the ACDF always returns Deny when
     given as the clearance input.</p>
  <p>If the stanza contains a &SECURITYLABEL; element and the either the &LABEL;
     element or one of the &EQUIVALENTLABEL; elements contain an appropriate label,
     that label input is that label.  Otherwise, the label input is the default
     label provided the governing policy or, if no default label is provided,
     the nil label.  The nil label is a label for which the ACDF always returns
     Deny when given as the label input.</p>
  <p>The term "effective clearance" and "effective label" refer, respectively,
     to the clearance and label provided as input to the ACDF.</p>
  <p>Not all sensitivity-based authorization decisions an XMPP server might make
     involve a user clearance and/or stanza label.  A server may only provide
     service to users which hold an appropriate clearance as determined by calling
     the ACDF with the user's clearance and a label associated with the service.
     A clearance might also be associated with the service to restrict the set
     of labels may be used in labeling stanzas.  Labels and clearances can also
     be associated with network interfaces, remote servers, chatrooms, pubsub
     notes.</p>
  <section2 topic='Use in Instant Messaging' anchor='im-use'>
    <p>A client may provide a &SECURITYLABEL; element in any &MESSAGE; it sends.</p>
<!--
    <p>The server will make, at a minimum, the following accessing control decisions:
    <ul>
    <li>TBD</li>
    </ul>
    </p>
-->
  </section2>
  <section2 topic='Use in Group Chat and Multi-User Chat' anchor='muc-use'>
    <p>A client may provide a &SECURITYLABEL; element in &MESSAGE; stanzas.</p>
    
    <section3 topic='Discovery' anchor='muc-disco'>
        <p>A server SHOULD provide a label feature and information discovery for the room.</p>
        <p>Clients SHOULD discover label feature and information on a per room basis.</p>
    </section3>
    <section3 topic='Sending Messages' anchor='muc-send'>
        <p>Sending groupchat messages is similiar to sending normal messages, however
           their are a few differences.</p>
        <p>Groupchat messages are addressed to the room.  The room clearance must
           be suitable for the message label, else it should be rejected.</p>
        <p>The room's clearance may allow a variety of labels to be used.  Not all
           partipants may be cleared for all labels allowed in the room.  The server
           MUST only deliver messages to partipants for which they are cleared to
           receive.</p>
    </section3>
    <section3 topic='Private Messages' anchor='muc-private'>
        <p>Private messages are treated as discussed in the "Use in Instant Messaging"
           section.  (Should private messages be restricted by room's configuration?)</p>
    </section3>
    <section3 topic='Invitations' anchor='muc-invite'>
        <p>Invitations may be labeled.</p>
    </section3>
    <section3 topic='Changing Subject' anchor='muc-subject'>
        <p>This section discusses semantics of &SECURITYLABEL; elements contained
           in &MESSAGE; stanzas containing a &SUBJECT; element.</p>
        <p>The presence of a &SECURITYLABEL; element indicates a request to change
           the room's label, either to the provided label or, if the element is empty,
           to unset the room's label.  The server is to refuse the request if the
           requestor is not authorized to change the subject, not cleared for the
           requested label, or if the server is otherwise unwilling or unable to make
           the change.  If the label change is refused, so must the accompanied
           subject change.  Likewise, if the subject change is refused, so must the
           accompanied label change.</p>
        <p>Upon change of the room's label, the server MUST immediately remove from
           the room all members whom are not cleared for that label.</p>
        <p>In absence of a &SECURITYLABEL; element, the label associated with the
           room is unchanged.</p>
        <p>The room's label can also be changed through room configuration (to be
           discussed in later revision of this document).</p>
    </section3>
    <section3 topic='Room Configuration' anchor='muc-config'>
        <p>The server may allow for configuration of security label parameters
           via room configuration mechanisms.  The approach is intended to be
           ad-hoc.  Hence this section is intended to be illustrative of one
		   possible approach.  Implementations are free to utilize other
		   approaches.</p>
  <example caption="Room Configuration Form"><![CDATA[
<iq from='room@muc.example.com'
    id='create1'
    to='user@example.com/Work'
    type='result'>
<query xmlns='http://jabber.org/protocol/muc#owner'>
    <x xmlns='jabber:x:data' type='form'>
       <title>"darkcave" room configuration</title>
       ...
       <field label='Room Label' type='list-single' var='sec-label#label'>
       <value>Catalog:UNCLASSIFIED</value>
       <option label='SECRET'><value>Catalog:SECRET</value></option>
       <option label='CONFIDENTIAL'><value>Catalog:CONFIDENTIAL</value></option>
       <option label='UNCLASSIFED'><value>Catalog:UNCLASSIFIED</value></option>
       <option label='Custom'><value>Custom</value></option>
       </field>
       <field label='Custom Room Label' type='text-single'
            var='sec-label#custom-label'/>

       <field label='Room Allowed Markings' type='list-multi' var='sec-label#clearance'>
       <value>Catalog:UNCLASSIFIED</value>
       <option label='SECRET'><value>Catalog:SECRET</value></option>
       <option label='CONFIDENTIAL'><value>Catalog:CONFIDENTIAL</value></option>
       <option label='UNCLASSIFED'><value>Catalog:UNCLASSIFIED</value></option>
       <option label='Custom'><value>Custom</value></option>
       </field>
       <field label='Custom Room Clearance' type='text-single'
            var='sec-label#custom-clearance'/>
    </x>
</query>
</iq>
  ]]></example>
    <p>In the above example, the server allows the room label to be set to one of
       to a subset of labels from the label catalog (see below), using the display
       name for selection, as well as custom label support.  For custom label choice
       support, the server offers an single text box for entry of an appropriate
	   text string indicating the label to use.  Likewise for the room clearance
	   and default room clearance.</p>
    <p>Though offering choices from the label catalog is often desirable,
       a server could only offer custom label and/or clearance support.</p>
  <example caption="Room Configuration Form"><![CDATA[
<iq from='room@muc.example.com'
    id='create1'
    to='user@example.com/Work'
    type='result'>
<query xmlns='http://jabber.org/protocol/muc#owner'>
    <x xmlns='jabber:x:data' type='form'>
       <title>"darkcave" room configuration</title>
       ...
       <field label='Room Label' type='text-single'
            var='sec-label#custom-label'/>
       <field label='Room Clearance' type='text-single'
            var='sec-label#custom-clearance'/>
    </x>
</query>
</iq>
  ]]></example>
    </section3>
  </section2>
  <section2 topic='Use in Presence' anchor='presence-use'>
    <p>&SECURITYLABEL; elements are not to appear in &PRESENCE; stanzas.  Server
       SHALL treat any &PRESENCE; stanza that contains a &SECURITYLABEL; as a
       protocol violation.</p>
    <p>Presence information is subject to sensitivity-base authorization decisions,
       however these decisions are made are made using a label associated with the
       presence resource, such as a chatroom's label.</p>
  </section2>
  <section2 topic='Use in PubSub' anchor='pubsub-use'>
    <section3 topic='Discovery' anchor='pubsub-disco'>
        <p>A server SHOULD provide a label feature and information discovery for each node.</p>
        <p>Clients SHOULD discover label feature and information on a per node basis.</p>
    </section3>
    <section3 topic='Publishing items with Security Labels' anchor='muc-send'>
        <p>Each item may be individually labeled.</p>
  <example caption="Publishing with a Security Label"><![CDATA[
<iq type='set'
    from='hamlet@denmark.lit/blogbot'
    to='pubsub.shakespeare.lit'
    id='pub1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='princely_musings'>
      <item>
        <entry xmlns='http://www.w3.org/2005/Atom'>
          <title>Soliloquy</title>
          <summary>
To be, or not to be: that is the question:
Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing end them?
          </summary>
          <link rel='alternate' type='text/html'
                href='http://denmark.lit/2003/12/13/atom03'/>
          <id>tag:denmark.lit,2003:entry-32397</id>
          <published>2003-12-13T18:30:02Z</published>
          <updated>2003-12-13T18:30:02Z</updated>
        </entry>
        <securitylabel xmlns='urn:xmpp:sec-label:0'>
            <displaymarking fgcolor='black' bgcolor='green'>UNCLASSIFIED</displaymarking>
            <label>
                <esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'>MQMGASk=</esssecuritylabel>
            </label>
        </securitylabel>
      </item>
    </publish>
  </pubsub>
</iq>
  ]]></example>
        <p>The service then notifies appropriately cleared subscribers.</p>
  <example caption="Publishing with a Security Label"><![CDATA[
<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node=princely_musings'>
      <item id='ae890ac52d0df67ed7cfdf51b644e901'>
        <entry xmlns='http://www.w3.org/2005/Atom'>
          <title>Soliloquy</title>
          <summary>
To be, or not to be: that is the question:
Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing end them?
          </summary>
          <link rel='alternate' type='text/html'
                href='http://denmark.lit/2003/12/13/atom03'/>
          <id>tag:denmark.lit,2003:entry-32397</id>
          <published>2003-12-13T18:30:02Z</published>
          <updated>2003-12-13T18:30:02Z</updated>
        </entry>
        <securitylabel xmlns='urn:xmpp:sec-label:0'>
            <displaymarking fgcolor='black' bgcolor='green'>UNCLASSIFIED</displaymarking>
            <label>
                <esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'>MQMGASk=</esssecuritylabel>
            </label>
        </securitylabel>
      </item>
    </items>
  </event>
</iq>
  ]]></example>
    </section3>
  </section2>
</section1>

<section1 topic='Extension Considerations' anchor='exts'>
  <p>
  This extension is itself is extensible.  In particular, the &LABEL; and &EQUIVALENTLABEL;
  elements are designed to hold a range of security labels formats.  XML namespaces SHOULD
  be used to avoid name clashes.
  </p>
</section1>

<!--
<section1 topic='Implementation Notes' anchor='impl'>
  <p>OPTIONAL.</p>
</section1>
-->
<section1 topic='Security Considerations' anchor='security'>
  <p>This document is all about authorization, a key aspect of security.  Hence,
     security considerations are discussed through this document.</p>
  <p>Certain XMPP stanzas, such as &PRESENCE; stanzas, are not themselves subject
     to any sensitity-based authorization decisions, and may be forwarded throughout
     the XMPP network.  The content of these stanzas should not contain information
     requiring sensitivity-based dissemination controls.</p>
  <p>It is desirable to securely bind the security label to the object it labels.
	 This may be accomplished through use of digital signatures.  Specification of such
	 is left to a future document.
     </p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
  <p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  <p>It is requested the &REGISTRAR; add the extension's namespaces
     and schemas to appropriate XMPP registries.</p>
</section1>
<section1 topic='XML Schemas' anchor='schema'>
<section2 topic='Extension Schema' anchor='schema-sl'>
  <p>
    <code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:xmpp:sec-label:0"
    xmlns="urn:xmpp:sec-label:0" elementFormDefault="qualified">

    <xs:annotation>
        <xs:documentation>The protocol documented by this schema is defined in XEP-0258:
            http://www.xmpp.org/extensions/xep-0258.html</xs:documentation>
    </xs:annotation>

    <xs:simpleType name="colorCSS">
        <xs:annotation>
            <xs:documentation>CSS colors (W3C colors + "orange")</xs:documentation>
        </xs:annotation>
        <xs:restriction base="xs:string">
            <xs:enumeration value="aqua"/>
            <xs:enumeration value="black"/>
            <xs:enumeration value="blue"/>
            <xs:enumeration value="fuschia"/>
            <xs:enumeration value="gray"/>
            <xs:enumeration value="green"/>
            <xs:enumeration value="lime"/>
            <xs:enumeration value="maroon"/>
            <xs:enumeration value="navy"/>
            <xs:enumeration value="olive"/>
            <xs:enumeration value="purple"/>
            <xs:enumeration value="red"/>
            <xs:enumeration value="silver"/>
            <xs:enumeration value="teal"/>
            <xs:enumeration value="white"/>
            <xs:enumeration value="yellow"/>
            <xs:enumeration value="orange"/>
        </xs:restriction>
    </xs:simpleType>

    <xs:simpleType name="colorRGB">
        <xs:annotation>
            <xs:documentation>Hex encoded RGB</xs:documentation>
        </xs:annotation>
        <xs:restriction base="xs:string">
            <xs:pattern value="#[0-9A-Fa-f]{6}"/>
        </xs:restriction>
    </xs:simpleType>

    <xs:simpleType name="color">
        <xs:annotation>
            <xs:documentation>Color</xs:documentation>
        </xs:annotation>
        <xs:union memberTypes="colorCSS colorRGB"/>
    </xs:simpleType>

    <xs:complexType name="displaymarking">
        <xs:annotation>
            <xs:documentation>Display Marking</xs:documentation>
            <xs:documentation>String to be prominently displayed along with labeled
                object.</xs:documentation>
        </xs:annotation>
        <xs:simpleContent>
            <xs:extension base="xs:string">
                <xs:attribute name="bgcolor" type="color" use="optional" default="white"/>
                <xs:attribute name="fgcolor" type="color" use="optional" default="black"/>
            </xs:extension>
        </xs:simpleContent>
    </xs:complexType>

    <xs:complexType name="label">
        <xs:choice minOccurs="0">
            <xs:any namespace="##other" processContents="lax"/>
        </xs:choice>
    </xs:complexType>

    <xs:element name="securitylabel">
        <xs:annotation>
            <xs:documentation>A Security Label</xs:documentation>
        </xs:annotation>
        <xs:complexType>
            <xs:sequence>
                <xs:element name="displaymarking" type="displaymarking">
                    <xs:annotation>
                        <xs:documentation>A Display Marking</xs:documentation>
                        <xs:documentation>To be prominently displayed</xs:documentation>
                    </xs:annotation>
                </xs:element>
                <xs:element name="label" type="label">
                    <xs:annotation>
                        <xs:documentation>The Primary Label</xs:documentation>
                    </xs:annotation>
                </xs:element>
                <xs:element name="equivalentlabel" type="label" minOccurs="0" maxOccurs="unbounded">
                    <xs:annotation>
                        <xs:documentation>An Equivalent Label</xs:documentation>
                    </xs:annotation>
                </xs:element>
            </xs:sequence>
        </xs:complexType>
    </xs:element>
</xs:schema>
    ]]></code>

    A copy of this schema is available at
        <link url='http://www.xmpp.org/schemas/sec-label.xsd'>
        http://www.xmpp.org/schemas/sec-label.xsd</link>.
  </p>
</section2>
<section2 topic='&lt;catalog/&gt; schema' anchor='schema-catalog'>
    <p>
      <code><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:sl="urn:xmpp:sec-label:0"
    xmlns="urn:xmpp:sec-label:catalog:2" targetNamespace="urn:xmpp:sec-label:catalog:1"
    elementFormDefault="qualified">

    <xs:annotation>
        <xs:documentation>The protocol documented by this schema is defined in XEP-0258:
            http://www.xmpp.org/extensions/xep-0258.html</xs:documentation>
    </xs:annotation>

    <xs:import schemaLocation="xep258.xsd" namespace="urn:xmpp:sec-label:0"/>

    <xs:attribute name="to" type="xs:string">
        <xs:annotation>
            <xs:documentation>Target JabberId</xs:documentation>
        </xs:annotation>
    </xs:attribute>

    <xs:attribute name="name" type="xs:string">
        <xs:annotation>
            <xs:documentation>Name</xs:documentation>
        </xs:annotation>
    </xs:attribute>

    <xs:attribute name="desc" type="xs:string">
        <xs:annotation>
            <xs:documentation>Description</xs:documentation>
        </xs:annotation>
    </xs:attribute>

    <xs:attribute name="id" type="xs:string">
        <xs:annotation>
            <xs:documentation>Identifer for current revision, commonly a hash</xs:documentation>
        </xs:annotation>
    </xs:attribute>

    <xs:attribute name="size" type="xs:integer">
        <xs:annotation>
            <xs:documentation>Number of items</xs:documentation>
        </xs:annotation>
    </xs:attribute>

    <xs:attribute name="restrict" type="xs:boolean">
        <xs:annotation>
            <xs:documentation>Restrictive</xs:documentation>
        </xs:annotation>
    </xs:attribute>

    <xs:attribute name="selector" type="xs:string">
        <xs:annotation>
            <xs:documentation>User input selector</xs:documentation>
        </xs:annotation>
    </xs:attribute>

    <xs:attribute name="default" type="xs:boolean">
        <xs:annotation>
            <xs:documentation>default selection</xs:documentation>
        </xs:annotation>
    </xs:attribute>

    <xs:element name="catalog">
        <xs:annotation>
            <xs:documentation>A Catalog of Labels</xs:documentation>
        </xs:annotation>

        <xs:complexType>
            <xs:sequence>
                <xs:element name="item" minOccurs="0" maxOccurs="unbounded">
                    <xs:complexType>
                        <xs:sequence>
                            <xs:element ref="sl:securitylabel"/>
                        </xs:sequence>
                        <xs:attribute ref="selector" use="optional"/>
                        <xs:attribute ref="default" use="optional"/>
                    </xs:complexType>
                </xs:element>
            </xs:sequence>
            <xs:attribute ref="to" use="optional"/>
            <xs:attribute ref="name" use="optional"/>
            <xs:attribute ref="desc" use="optional"/>
            <xs:attribute ref="id" use="optional"/>
            <xs:attribute ref="size" use="optional"/>
            <xs:attribute ref="restrict" use="optional"/>
        </xs:complexType>
    </xs:element>
</xs:schema>
    ]]></code>
  
    A copy of this schema is available at
        <link url='http://www.xmpp.org/schemas/sec-label-catalog.xsd'>
        http://www.xmpp.org/schemas/sec-label-catalog.xsd</link>.   
    </p>
</section2>
<section2 topic='&lt;esssecuritylabel/&gt; schema' anchor='schema-ess'>
  <p>
    <code><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:xmpp:sec-label:ess:0"
    xmlns="urn:xmpp:sec-label:ess:0" elementFormDefault="qualified">
    <xs:annotation>
        <xs:documentation> The protocol documented by this schema is defined in XEP-0258:
            http://www.xmpp.org/extensions/xep-0258.html </xs:documentation>
    </xs:annotation>
    <xs:element name="esssecuritylabel" type="xs:base64Binary">
        <xs:annotation>
            <xs:documentation>An S/MIME ESS SecurityLabel [RFC2634]</xs:documentation>
            <xs:documentation>Value is the base64 encoding of the BER/DER encoding of an ASN.1
                ESSSecurityLabel type as defined in RFC 2634. </xs:documentation>
        </xs:annotation>
    </xs:element>
</xs:schema>
    ]]></code>

    A copy of this schema is available at
        <link url='http://www.xmpp.org/schemas/sec-label-ess.xsd'>
        http://www.xmpp.org/schemas/sec-label-ess.xsd</link>.
  </p>
</section2>
</section1>
</xep>