On Wed Mar 11 16:49:05 2009, Boyd Fletcher wrote:
On 3/11/09 12:16 PM, "Kurt Zeilenga" <[email protected]>
wrote:
> On Mar 10, 2009, at 5:00 PM, Boyd Fletcher wrote:
> 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 Kurt's referring to the (now ancient) Netscape colour cube.
SYmbolic names do have definitions, and I'd generally prefer them to
be resolved into hex triplets as required by the server.
>> > 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.
That's interesting, as I'd assumed that the long name would be used,
for example, across the top of a chat window, whereas the short
portion marking would be both against messages and in the drop-down.
>
>> > 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.
There's a number of problems with labelling <iq/>, particularly that
the labelling would need to be symmetric, and we cannot easily find a
suitable syntax given the restrictions on the numbers of children.
Suggestions would be welcome here.
As for presence, one of the main reasons we've avoided this is
implementation experience - presence is not a message, but a
signalling of state change. In order to fully handle labelled
presence, you'd need to track a considerably greater amount of state.
Consider this (simplified) exchange:
1. Client sends initial presence.
<presence>
<securityLabel><label>SECRET</label></securityLabel>
<status>Squirrel</status>
</presence>
At this point, only clients (and services) with SECRET clearance (ie,
a clearance which the ACDF will evaulate true given it and a SECRET
label) see the client as online.
2. Client updates presence.
<presence>
<securityLabel><label>UNCLASSIFIED</label></securityLabel>
<status>Unicorn</status>
</presence>
Now:
a) Endpoints with only SECRET clearance will see the status as
"Squirrel".
b) Endpoints with only UNCLASSIFIED clearance will see the status as
"Unicorn".
c) Endpoints with both SECRET and UNCLASSIFIED clearance will see the
status as, erm, probably "Unicorn".
Now if a new endpoint comes online and probes the user, the server
must check the clearance against each presence in turn, in order to
detirmine the viewable state - this means we need to store older
presence stanzas until such time as anyone would see the presence as
offline.
We could do this another way, too, and assume that sending a presence
for which an endpoint doesn't have clearance to see is equivalent to
sending offline status. But the problem there is that a broadcast
available presence will go to only endpoints in the roster, whereas
broadcast unavailable should go to directed presence endpoints as
well.
So, sending a broadcast available presence might either leave you
joined to a chatroom when, in fact, you wanted to signal that your
availability is only visible to those with SECRET clearance, or else
we need to now consider whether the directed presence endpoints have
clearance to see the broadcast presence we're not going to show them
anyway.
Furthermore, there's a significant problem with how one labels a
synthetic offline presence. If it's labelled as UNCLASSIFIED, then a
SECRET-only service won't see it, which might mean that a SECRET-only
chatroom will have the user ghosted.
> 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?
The labels are single elements, the display marking is another, both
grouped in a single container 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.
"default" labels are sometimes specified by the policy, in X.841
terms, so I think we could do that. Certainly our implementation
allows specification of a default label per chatroom, too.
I'm not convinced that default labels are equivalent to the "highest"
level, though - they're quite often equivalent to the lowest level.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
