Folks (and particularly Trey and Bret),
I was pointed at a discussion about security labelling on the main CTI list by a colleague at Surevine, and I'm mildly concerned that the CTI group may be reinventing security labelling and protective markings entirely anew. That's quite a big wheel, and I have a nice round one right here.
Firstly, the good news:
* There's been an existing model for handling security labelling in computer applications for a couple of decades, and the newest generation of that was published 16 years ago as SDN.801 Revision C. So this is as solved as a problem gets.
* While I've not yet got to a couple of bits, I and my employer published an MIT-licensed chunk of C++ for handling these a few months back. See
https://github.com/surevine/Spiffing
* Policy files dictate how to present machine-readable labels, so in principle internationalization can be performed at the policy file (or SPIF) level.
* Policy files can also include information on how labels from *other* policies should be converted, and how to convert labels into other policies. So if different organizations want to have entirely different labelling schemes, this is fine.
* There's a dozen label formats, and although the oldest formats are ASN.1 schemas, there are XML ones too, and it'd be trivial to write a JSON one if you want.
* Clearances are also handled, so you can easily perform machine-level filtering of feeds, etc.
* These standards have been successfully implemented even in cases where only the server understands the policy, and the client-side doesn't, in XMPP and email. In XMPP for example, XEP-0258 describes a mechanism for marking XMPP messages whereby the clients are unaware of policy or the label semantics, operating purely on text strings.
Now the not so good news:
* Because of the nature of the field, and the unaccountable desire of various national agencies from a number of countries to ensure they're paying way over the odds, much of the information is not publically available. An example is SDN.801 Revision C, which is "specifically prohibited from posting on unrestricted electronic web sites", for example, or the NATO XML labelling format which is (I think) NATO CONFIDENTIAL.
* The knock-on effect of the above is that even though I can publish a liberally-licensed open-source library, I'm not allowed to support all formats, and I cannot even easily produce comprehensive documentation for it.
* There are way too many formats, and I've not implemented them all yet (even the public ones). Some of these, such as the US IC ISM XML syntax, are policy-specific, which means that organizations may struggle to fit their own policy in. This is especially true if the policy doesn't use the "standard" classifications - true of, for example, the UK policy and the TLP (if modelled that way).
With all that in mind, while I'm entirely happy to answer questions, there is a limit to how much I can answer in public and without an NDA in place - this isn't down to me, I would much prefer if these documents and formats were all public.
Dave.