On 3/11/09 12:16 PM, "Kurt Zeilenga" <[email protected]> wrote:
>
>
> On Mar 10, 2009, at 5:00 PM, Boyd Fletcher wrote:
>
>> >
>> > I think it should be generalized further so not be specific to
>> > either ESS or ICISM.
>
> As nothing in the specification calls for use any particular label
> format in XMPP. In fact, the first and second implementations of this
> specification (both quite experimental at this stage) each used label
> formats not discussed in this XEP (and different from each other).
> One nice thing about using ESS in the illustrations is that value is
> just a base64 blob to most folks, so they are unlikely to attach any
> particular semantics to the value. (For this XEP, I assume the client
> is quite dumb. In particular, has no specific knowledge of the
> security (labeling) policy. While certainly supporting security
> (labeling) policy aware clients is desirable as well, but I rather
> save such features for another document.
>
>
>
>
>> > BTW, Example 2 <displaymarking> should be "U//FOUO" or
>> > "UNCLASSIFIED//FOR OFFICIAL USE ONLY" not "SECRET" because of the
>> > disseminationControls attribute of SECRET can¹t have FOUO.
>
> My bad... half an edit got applied.
>
>> > Also its probably safer to require that colors be specified in their
>> > #RRGGBB hexadecimal equivalent not the symbolic name.
>
> As a protocol guy, I hate multiple representations of any particular
> abstract value. However, in our use case, labels and other security
> information objects tend to get constructed using XML authoring tools
> more than anything else. Users of these tools much rather use
> symbolic names they understand than hexadecimal values. Raw labeled
> messages do get exposed to humans before/during/after transmission in
> various cases (such as in audit logs), so it seems reasonable to cater
> some to the human.
>
> Though I am not a GUI guy, I do recall discussion in HTML land that
> not all hexadecimal values are display safe, however this may now be
> of only historical interest.
>
> It also might be good to make a note about accessibility here.
>
>
hexadecimal have to be display safe. symbolic names may not depending on the
name to hexadecimal mapping used
>
>> > I think displayMarking should have two attribute portionMarking
>> > (i.e. ³S//REL USA and GBR²) and securityBanner (i.e. ²SECRET//REL
>> > USA and GBR²).
>> >
>> > securityBanner The long string representation of the security
>> > marking
>> > portionMarking The short string representation of the security
>> > marking
>
> I rather only have a single string to prominently display. Having two
> will likely lead to some implementations favoring one over the other.
> If there were to be two, I rather use generic names for them (e.g.,
> shortMarking, longMarking) and, most importantly, a clear statement of
> when/where each is to used.
>
shortM/LongM are fine with me but we need both. its likely the clients would
show the long name in drop down selector widget but the short name in chat
messages.
>
>> > we define a <feature> for MUC that specific to security markings,
>> > perhaps
>> > "http://www.xmpp.org/protocol/securitylabel";
>
> It's intended that "urn:xmpp:sec-label:0" feature be published in each
> service domain, and elsewhere, which is using security labels.
>
>
>> > <presence> and <iq> packets should be labeled be required to be
>> > label is message packets are. In many environments a person presence
>> > could be very sensitive.
>
> There are two models for handling presence. One is to regard a
> person's (or resource's) presence information (regardless of
> particulars) to have a given sensitivity.
>
> Another is to allow each statement of presence to have its own
> sensitivity. The latter introduces significant complexity into the
> security model. In particular, when a user's presence changes from "A
> (UNCLASSIFIED)" to "B (SECRET)", not all subscribers to the presence
> may be authorized to see "B (SECRET)" but as "A (UNCLASSIFIED)" is no
> longer the current presence, the server ends up in a quandary.
> Solutions seem to either violate the security model or lead to
> usability problems.
>
> Hence, this document takes the former approach.
>
without labeled presence and iq packets its useless for cross domain
transfer which is why we implement. The system may default the label to the
lowest level, but all data must be labeled.
>
>> > if you DISCO a room for the above feature it needs to return:
>
> Why just a room? The document provides security labeling on all
> <message/> traffic (IM, MUC, PUBSUB).
>
agree all features should be capable of handling labeling.
>
>> > 1. XML namespace of the security labeling scheme used
>
> Only one? Our server actually supports (concurrently) multiple label
> formats. Though in practice we hope only one format would be used, I
> can see cases where multiple formats are used concurrently in a single
> system (ugly as it might be).
>
very unlikely condition due to collisions between the labeling schemes. but
allowing more is fine with mine then all the items will need to be
namespaced as well.
>
>> > 2. labeling attributes/element used
>
> Given the focus of this XEP is not to require clients to have any
> particular knowledge of the label format or security policy, I cannot
> see what use this would be to such clients. As I noted above, I
> rather save features intended to support smarter clients to a follow-
> up XEP.
>
ok so you want to send the entire security marking as a single element?
>
>> > 3. an ordered list of security labels.
>> > in the ordered list only highest and lowest have meaning. since a
>> > label like ³S//REL USA and FRA² and ³S//REL USA and GBR² are non-
>> > comparable.
>
> The specification does provide a simple catalog of label discovery
> mechanism. I didn't define an order, but don't have a problem with
> saying that the labels should loosely ordered (as there is no strict
> ordering of labels).
must client in order to be useful need to know which is the dominant label
so that it is the default label for all messages. if you don¹t want do
ordered (and there are subtle complexities with doing it) then how about
³default² attribute or element that signals to the client which label to use
if the user doesn¹t select one. this ³default² element would also signify
the highest level of the chat room or service.
boyd
>
>> >
>> >
>> > On 3/10/09 6:03 PM, "XMPP Extensions Editor" <[email protected]> wrote:
>> >
>>> > > Version 0.2 of XEP-0258 (Security Labels in XMPP) has been released.
>>> > >
>>> > > 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.
>>> > >
>>> > > Changelog: Reworked discovery and various updates. (kdz)
>>> > >
>>> > > Diff:
>>> > >
>>>
http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0258.xml?%40diffMod
>>> > > e=u&%40diffWrap=s&r1=2598&r2=2867&u=3&ignore=&k=
>>> > >
>>> > > URL: http://www.xmpp.org/extensions/xep-0258.html
>>> > >
>
>
