On Mar 11, 2009, at 10:44 AM, Dave Cridland wrote:
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.
http://en.wikipedia.org/wiki/Web_colors#Web-safe_colors
>> > 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.
Portion markings are about marking portions of documents (messages).
This specification does not support portion markings.
Under SDN 801c, X.841, and like systems, there are multiple display
strings that can be produced with knowledge of the Security Policy (a
SPIF), none of which are indented to be used a portion marking.
These specification simply did not discussion portion marking.
In electronic messaging (and X.500 directory systems), only two of the
seven display strings are used. The "pageBottom" string is to be
prominently displayed when the labeled content (a message) is
display. The "userInput" string can be used for label selection (when
labeling a message).
For ESS labels, <displaymarking> is the pageBottom string. I was
thinking of placing providing the "userInput" string in label catalogs
for selection.
Generally speaking, the userInput string is often shorter than the
pageBottom string. But as all strings are policy driven, that's
certainly not guaranteed.
Given Boyd's use description, I am fine with <displayMarking/> and
<userSelectionString/> to provide two strings, and detailing the use
as discussed above. The latter seems reasonable to only have in
catalogs, but I don't mind if it always allowed.
>
>> > 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.
I want each <label/> element to have zero or one child element which,
if present, is an XML presentation of the scheme-specific security
label.
That element might be very simple or quite complex.
I have one example where this label is basically:
<textlabel xmlns='xxxxxx'>SECRET</textlabel>
I have another example where the element is fully XML encoding of an
ASN.1 ESSSecurityLabel value (as opposed to <essecuritylabel/> which
is just contains a BER encoding of an ASN.1 ESSSecurityLabel value).
>
>> > 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.
I think this approach is better. I much prefer that such semantics be
explicit in the catalog instead of merely implied by order of the
label elements.
"default" labels are sometimes specified by the policy, in X.841
terms, so I think we could do that.
Right, for instance, SDN 801 Security Policies have a concept of
default policy data which specifies how messages without labels and
persons without clearances are to be processed. This default policy
data commonly states that a message without label is to treated as if
labeled "UNCLASSIFIED" and a person without a clearance as if cleared
for "UNCLASSIFIED". In absence of default policy data, access to
unlabeled messaged and/or by users without clearances is to be
denied. This "default" is system wide.
But, beyond this, there are some other useful "default" concepts, such
as "system high" and "system low". The problem with treating the
first and last label in a catalog as "system high"/"system low" is
that labels at the highest/lowest classification might not be
comparable (as illustrated by the S// markings above). Such defaults
generally depend on what's meant by "system". It could be truly
"system-wide", but it's often much more limited, e.g. "chat room".
As I noted above, I don't mind having catalogs loosely ordered so long
the specification is clear that its only a loose ordering. But see my
note above for how I prefer to handle resource-specific "default"
label semantics.
Certainly our implementation allows specification of a default label
per chatroom, too.
Yes because we expect to be dealing with clients that have no labeling
support whatsoever.
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
