misc updates

xep-0258.xml

@@ -36,6 +36,12 @@
     <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>
@@ -86,11 +92,11 @@
      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 have a
+     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 military agency networks.  The
+     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
@@ -125,7 +131,7 @@
   <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 <em>not</em> provide:
+  <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>
@@ -136,17 +142,20 @@
      </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>If an entity supports the XMPP Security Label protocol, it MUST report that fact
+  <p>An entity (client or server) which supports the XMPP Security Label protocol
-     by including a service discovery feature of "<tt>urn:xmpp:sec-label:0</tt>" in
+     MUST report that fact by including a service discovery feature of
-     response to a &xep0030; information request.  Clients wishing to include a XMPP
+	 "<tt>urn:xmpp:sec-label:0</tt>" in response to a &xep0030; information request.</p>
-     Security Label element in any stanza they generate SHOULD determine if their
+  <p>Clients wishing to include a XMPP Security Label element in any stanza they
-     server supports the XMPP Security Label protocol.  If their server does not
+	 generate SHOULD determine if their server supports the XMPP Security Label protocol.
-     support XMPP Security Label, the client SHOULD NOT generate XMPP Security Labels
+	 If their server does not support XMPP Security Label, the client SHOULD NOT generate
-     as the server not supporting this protocol will generally ignore XMPP Security
+     XMPP Security Labels as the server not supporting this protocol will generally
-     Labels as they would any other unrecognized element.</p>
+	 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>
@@ -170,10 +179,6 @@
   </query>
 </iq>
   ]]></example>
-<!--
-  <p>A server should only include &IDENTITY; elements in the response for services
-     the user is cleared to use.</p>
--->
 </section1>
 
 <section1 topic='Protocol' anchor='protocol'>
@@ -234,12 +239,12 @@
        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 restrictive attribute
+	<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 to this item in cases
+	   value of true.  The client should default the label selection to
-	   where the user has not selected an item.</p>
+	   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
@@ -258,9 +263,10 @@
     <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>Each item in the catalog may contain a selector attribute.  The
+    <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.  The value of the selector
+       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[
@@ -277,6 +283,7 @@ selector-value = (<item>"|")*<item>
 	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'/>
@@ -298,7 +305,7 @@ selector-value = (<item>"|")*<item>
     <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 type='get' id='cat1'>
+<iq to='example.com' type='get' id='cat1'>
   <catalog xmlns='urn:xmpp:sec-label:catalog:2' to='example.com'/>
 </iq>
   ]]></example>
@@ -308,7 +315,7 @@ selector-value = (<item>"|")*<item>
   <catalog xmlns='urn:xmpp:sec-label:catalog:2'
       to='example.com' name='Default'
       desc='an example set of labels'
-	  restrictive='false'>
+	  restrict='false'>
 	<item selector="Classified|SECRET">
             <securitylabel xmlns='urn:xmpp:sec-label:0'>
                 <displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking>
@@ -327,7 +334,7 @@ selector-value = (<item>"|")*<item>
                 </label>
             </securitylabel>
 	</item>
-	<item selector="Classified|RESTRICTED" default="true">
+	<item selector="Classified|RESTRICTED">
             <securitylabel xmlns='urn:xmpp:sec-label:0'>
                 <displaymarking fgcolor='black' bgcolor='aqua'>RESTRICTED</displaymarking>
                 <label>
@@ -336,10 +343,11 @@ selector-value = (<item>"|")*<item>
                 </label>
             </securitylabel>
 	</item>
-	<item selector="Unclassified|UNCLASSIFIED"/>
+	<item selector="UNCLASSIFIED" default="true"/>
   </catalog>
 </iq>
   ]]></example>
+
 </section1>
 
 <section1 topic='Use in XMPP' anchor='xmpp-use'>
@@ -455,12 +463,12 @@ selector-value = (<item>"|")*<item>
         <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, not
+           ad-hoc.  Hence this section is intended to be illustrative of one
-           prescriptive.</p>
+		   possible approach.  Implementations are free to utilize other
+		   approaches.</p>
   <example caption="Room Configuration Form"><![CDATA[
 <iq from='room@muc.example.com'
     id='create1'
@@ -479,6 +487,7 @@ selector-value = (<item>"|")*<item>
        </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>
@@ -488,13 +497,6 @@ selector-value = (<item>"|")*<item>
        </field>
        <field label='Custom Room Clearance' type='text-single'
             var='sec-label#custom-clearance'/>
-       <field label='Default Label' type='list-single' var='sec-label#default-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>
     </x>
 </query>
 </iq>
@@ -502,13 +504,11 @@ selector-value = (<item>"|")*<item>
     <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 appropriate choice (the label= string should
+       support, the server offers an single text box for entry of an appropriate
-       be selected to avoid confusion with display markings used in label=
+	   text string indicating the label to use.  Likewise for the room clearance
-       attributes). as well as a field for providing the custom label.  Likewise
+	   and default room clearance.</p>
-       for the room clearance.  The server also allows configuration of a default
-       label for use in handling of unlabeled messages.</p>
     <p>Though offering choices from the label catalog is often desirable,
-       a server may only offer custom label and/or clearance support.</p>
+       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'
@@ -527,7 +527,6 @@ selector-value = (<item>"|")*<item>
 </iq>
   ]]></example>
     </section3>
--->
   </section2>
   <section2 topic='Use in Presence' anchor='presence-use'>
     <p>&SECURITYLABEL; elements are not to appear in &PRESENCE; stanzas.  Server
@@ -630,13 +629,14 @@ And by opposing end them?
 <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>Security labels generally should be securely bound to the object.  This may be
-     accomplished through use of &xmppe2e; signing, or possibly other signing
-     mechanisms.</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>
@@ -803,7 +803,6 @@ And by opposing end them?
         </xs:annotation>
     </xs:attribute>
 
-
     <xs:attribute name="selector" type="xs:string">
         <xs:annotation>
             <xs:documentation>User input selector</xs:documentation>
@@ -812,7 +811,7 @@ And by opposing end them?
 
     <xs:attribute name="default" type="xs:boolean">
         <xs:annotation>
-            <xs:documentation>Default Item</xs:documentation>
+            <xs:documentation>default selection</xs:documentation>
         </xs:annotation>
     </xs:attribute>