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