From fa5086e125f0b665de9f3b511300c046259d7236 Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Mon, 15 Aug 2011 10:01:32 -0700 Subject: [PATCH] v0.9 editorial changes and add optional jid to catalog request. --- xep-0258.xml | 64 ++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 45 insertions(+), 19 deletions(-) diff --git a/xep-0258.xml b/xep-0258.xml index fe95c239..b44ed322 100644 --- a/xep-0258.xml +++ b/xep-0258.xml @@ -15,8 +15,8 @@
Security Labels in XMPP 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. + specifies how security label meta-data is carried in XMPP, when this meta-data + should or should not be provided, and how the meta-data is to be processed. &LEGALNOTICE; 0258 Experimental @@ -36,6 +36,12 @@ Kurt.Zeilenga@Isode.COM Kurt.Zeilenga@Isode.COM + + 0.9 + 2011-09-15 + kdz +

Add optional from attribute to catalog element for S2S requests. Make editorial changes.

 + 0.8 2011-08-11 @@ -46,7 +52,7 @@ 0.7 2011-03-08 kdz -

Illustrate XEP 45 security label room configuration. Make clarifications and minor editorial changes.

 +

Illustrate XEP Multi-User Chat room security label configuration. Make clarifications and minor editorial changes.

 0.6 @@ -106,7 +112,7 @@ standardized formats for security labels, clearances, and security policy are generalized and do have application in non-government networks.

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 + how security label meta-data 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; @@ -134,8 +140,8 @@ ]]>

Note: The &IC-ISM; label example is for illustrative purposes only.

-

The document details when security label metadata should or should not be provided, and how - this metadata is to be processed.

+

The document details when security label meta-data should or should not be provided, and how + this meta-data is to be processed.

This document does not provide:

    @@ -188,7 +194,7 @@ -

    An element, &SECURITYLABEL;, is defined to carry security label metadata. This metadata +

    An element, &SECURITYLABEL;, is defined to carry security label meta-data. This meta-data includes a security label, zero or more equivalent security labels, and optionally display marking data.

    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 + a party other than its server may not be directly usable 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.

    @@ -255,11 +261,11 @@ sending a stanza without a label.

    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 + context (such as in chat room). A catalog may not be include the complete set of labels available for the use by the client in the context.

    Note: the single catalog per context approach used here - is likely inadequate in enviroments where there are a large number + is likely inadequate in environments 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.
    @@ -308,7 +314,11 @@ selector-value = ("|")* ]]>     -

    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).

    + +

    The following example pair illustrates catalog discovery. The +client directs the &IQ; to its server regardless of which catalog +it requests via the to= attribute of in &CATALOG; element. The +client SHOULD NOT provide a from= attribute in the &CATALOG; element.

    @@ -354,6 +364,15 @@ selector-value = ("|")* ]]> +

    +Where the server needs to obtain a catalog from another server in order +to respond to its client, it can send an &IQ; to that server requesting +that catalog. The requesting server provides the bare JID of the +requesting user in the from= attribute in the &CATALOG; element when +it desires a catalog to be prepared specifically for the user. +Otherwise the from= attribute in the &CATALOG; element is absent. +

    +     @@ -389,7 +408,7 @@ selector-value = ("|")* absent.

    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 + prominently display the marking for the &LABEL; prescribed by the governing policy.

    Each server is expected to make a number of sensitivity-based authorization decisions. Each decision is made by evaluating an Access Control Decision @@ -415,7 +434,7 @@ selector-value = ("|")* 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 + be associated with network interfaces, remote servers, chat rooms, pubsub nodes.

    A client may provide a &SECURITYLABEL; element in any &MESSAGE; it sends.

    @@ -435,13 +454,13 @@ selector-value = ("|")*

    Clients SHOULD discover label feature and information on a per room basis.

    -

    Sending groupchat messages is similiar to sending normal messages, however +

    Sending groupchat messages is similar to sending normal messages, however their are a few differences.

    Groupchat messages are addressed to the room. The room clearance must be suitable for the message label, else it should be rejected.

    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 + participants may be cleared for all labels allowed in the room. The server + MUST only deliver messages to participants for which they are cleared to receive.

     @@ -540,7 +559,7 @@ selector-value = ("|")* protocol violation.

    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.

    + presence resource, such as a chat room's label.

     @@ -622,7 +641,7 @@ And by opposing end them?

    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 + elements are designed to hold a range of security labels formats. XML name spaces SHOULD be used to avoid name clashes.

    @@ -636,7 +655,7 @@ And by opposing end them?

    This document is all about authorization, a key aspect of security. Hence, security considerations are discussed through this document.

    Certain XMPP stanzas, such as &PRESENCE; stanzas, are not themselves subject - to any sensitity-based authorization decisions, and may be forwarded throughout + to any sensitivity-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.

    It is desirable to securely bind the security label to the object it labels. @@ -779,6 +798,12 @@ And by opposing end them? + + + Target JabberId + + + Name @@ -839,6 +864,7 @@ And by opposing end them? +