Compartmented Mode Workstation Labeling: Encodings Format

Chapter 4 Information Label Encodings

The INFORMATION LABELS: section specifies the words that make up a human-readable representation of an information label, as well as the required combinations and combination constraints on these words. This section is used by the system to convert a human-readable representation of non-classification information label words into the internal bit-string form, and to translate the internal form to a human-readable representation.

The WORDS: subsection, which must appear immediately after INFORMATION LABELS:, specifies each word as well as the prefixes and suffixes needed by some words. The REQUIRED COMBINATIONS: and COMBINATION CONSTRAINTS: subsections follow the WORDS: subsection, in that order.

The Words: Subsection

The WORDS: subsection consists of zero or more word specifications. Each word specification starts with a name= keyword, and ends with the next name= keyword or the start of the REQUIRED COMBINATIONS: subsection. Therefore, a name= keyword must be the first keyword to follow the INFORMATION LABELS: keyword. Any other WORDS: keywords appearing before the first name= keyword are ignored. Other keywords used to define information label words are the sname=, iname=, prefix, suffix, minclass=, maxclass=, ominclass=, omaxclass=, compartments=, markings=, prefix=, suffix=, access related, and flags= keywords. These keywords can appear in any order after a name= keyword. A word cannot have the slash (/), comma (,) or whitespace (space, tab, carriage return, linefeed, formfeed) characters.

Defining Prefixes And Suffixes

Words can have prefixes and suffixes. An example of words that might have a prefix are country names. REL CNTRY1 is an example of the word CNTRY1 that requires the prefix REL. REL CNTRY1/CNTRY2 is an example of two words (CNTRY1 and CNTRY2), both of which require the same prefix. An example of words that might have a suffix are project names, whose suffix might be the word LIMDIS to indicate that distribution of the information is limited to people working on the project. Thus PROJECT X LIMDIS is an example of the word PROJECT X that requires the suffix LIMDIS, and PROJECT X/PROJECT Y LIMDIS is an example of two words that require the same suffix LIMDIS.

It is also possible for a word to require both a prefix and a suffix. However, in such a case, the prefix and suffix must always be used together. In other words, if word W requires prefix P and suffix S, word X cannot require prefix P without also requiring suffix S.

It should be noted that words themselves can contain blanks (such as PROJECT X above), so simply having a blank in a word is no reason to define it as a word with a prefix. Rather, prefixes and suffixes should be used only when there are multiple words that require the same prefix or suffix.

The Name= Keyword

The name= keyword is used to define the full name of the prefixes, suffixes, and other words. The name is taken to begin with the first non-blank character following the blank after the keyword, and continues up to the next semicolon or the end of the line. The name can contain underscores and dashes (-). A particular name value should not be specified more than once per section of the encodings file.

The full name specified is used when producing all human-readable labels. The full name specified can also be entered by users as part of a label.

The Sname= Keyword

The optional sname= keyword assigns an alternative (presumably shorter or abbreviated) name to prefixes, suffixes, and other words. The name is taken to begin with the first non-blank character following the blank after the keyword, and continues up to the next semicolon or the end of the line. The name can contain underscores and dashes (-). A particular sname value should not be specified more than once per section of the encodings file. If sname= is specified more than once for the same word, all specifications except the last are ignored. Hence, sname= should be specified at most once.

Any short names specified can be entered by users as part of a label. Short names are never used in producing human-readable labels.

The Iname= Keyword

The optional iname= keyword assigns input names to prefixes, suffixes, and other words. The name is taken to begin with the first non-blank character following the blank after the keyword and continues up to the next semicolon or the end of the line. The name can contain underscores and dashes (-). A particular iname value should not be specified more than once per section of the encodings file. The iname= keyword can be specified any number of times for the same word to specify multiple input names.

A specified iname or input name can be entered by users as part of a label, but are never used in producing human-readable labels. The intended purpose of the iname= keyword is to specify common word misspellings.

note that extra names for the same word can also be specified with an exact alias (a word with markings and compartments identical to a preceding word), as described in Chapter 7, General Considerations for Specifying Encodings. Using an iname is preferable to using an exact alias.

Defining Prefix and Suffix Words

All prefixes and suffixes themselves must be defined as words at the beginning of the WORDS: subsection. As with any other word, a prefix or suffix itself can have both long and short names. A prefix is defined by specifying its name with the name= keyword, its optional short name with the sname= keyword, optional input names with iname=, and the keyword prefix. A suffix is defined by specifying its name with the name= keyword, its optional short name with the sname= keyword, optional input names with iname=, and the keyword suffix.

Optionally, prefixes can be specified with compartments= and markings= keywords. These specify special inverse bits. Words that specify a prefix with special inverse bits are called special inverse words. See Using Prefixes to Specify Special Inverse Compartment and Marking Bits in Chapter 7, General Considerations for Specifying Encodings.

Defining Non-Prefix/Non-Suffix Words

The order in which non-prefix/non-suffix words are specified in the encodings file is extremely important. When translating an internal format of a label to human-readable form, the applicable words will be placed in the human-readable string in the order in which they appear in the encodings file. Therefore, the order of the words in the encodings file determines the canonical form of the human-readable representation of the label. By convention, the most important words appear first. Usually, the most important words are those that designate sensitive data, and therefore typically represent compartments, subcompartments, or codewords.

All words must have a name, and can optionally have a short name and multiple input names. If the word requires a prefix, the prefix it requires must be specified with the prefix= keyword. The prefix specified starts with the first non-blank character following the blank after the keyword, and continues up to the next semicolon or the end of the line. Either the short or long name of the prefix can be specified, as long as the prefix is defined at the beginning of the WORDS subsection. If the word requires a suffix, it must have a suffix= keyword. The suffix specified starts with the first non-blank character following the blank after the keyword, and continues up to the next semicolon or the end of the line. Either the short or long name of the suffix can be specified, as long as the suffix is defined at the beginning of the WORDS subsection.

The remaining keywords associated with words define the semantics of the word, rather than the syntax of its human-readable representation. The meaning and specification of each of these remaining keywords are described below.

The Minclass= Keyword

The optional minclass= keyword specifies the minimum classification with which the word should appear in a human-readable label. The classification specified starts with the first non-blank character following the blank after the keyword, and continues up to the next semicolon or the end of the line. The classification can be either the short, long, or alternate name of a classification defined in the CLASSIFICATIONS: section. If the minimum classification with which a word can appear is the classification with the lowest value (as defined by the value= keyword), then there is no need to make a minclass= keyword specification.

If a word with an associated minclass is added to a label with a classification below that minclass, the classification in the label is automatically raised to the minclass, assuming the well formedness rules otherwise allow adding the word to the label.

The Ominclass= Keyword

The optional ominclass= keyword specifies the output minimum classification for the word. The output minimum classification is the minimum classification with which the word can be output (i.e., appear in a human-readable representation of a label converted from internal format). The classification specified starts with the first non-blank character following the blank after the keyword, and continues up to the next semicolon or the end of the line. The classification can be the short, long, or alternate name of a classification defined in the CLASSIFICATIONS: section. If the output minimum classification with which a word can be associated is the classification with the lowest value (as defined by the value= keyword), then there is no need to make an ominclass= keyword specification.

The distinction between minclass= and ominclass= is subtle but very important. Specifying ominclass for a word prevents that word from appearing in human-readable labels with classifications below the ominclass, even if the internal representation of the label specifies the word. A word with an associated ominclass cannot be added to a label with a classification below that ominclass, unless the word also has a minclass that is greater than or equal to the ominclass.(In this case, the only reason the word can be added is that the minclass, being greater than or equal to the ominclass, causes the label's classification to be raised when the word is added, such that the classification of the label is greater than or equal to the ominclass, so that the word can appear in the label.) The following examples shed more light on the differences between ominclass and minclass.

Typically, ominclass= would be specified only for those inverse words associated only with inverse bits, when the word—by convention—is not shown in labels below a certain classification. (The most typical case of an inverse word is one associated with only inverse bits. This is the case for all the words of the form REL XX in Appendix B, Annotated Sample Encodings. However, more complex inverse words are possible. An example is the codeword bravo4 in Appendix B, Annotated Sample Encodings. This codeword is associated with an inverse bit and several non-inverse bits. There is no need to specify an ominclass for bravo4, primarily because of the presence of the non-inverse bits in its internal form.) The best example of such a word is a release marking, e.g., REL CNTRY1. The word REL CNTRY1 indicates that the information is releasable to CNTRY1. Therefore, CONFIDENTIAL information that was releasable to CNTRY1 would have a label of CONFIDENTIAL REL CNTRY1. However, note that UNCLASSIFIED information is—by virtue of its not being classified—releasable to CNTRY1. Therefore, the semantics of REL CNTRY1 is such that its internal representation must be present in UNCLASSIFIED labels, yet—by convention—it is not shown in the human-readable representation of the label UNCLASSIFIED. Therefore, specifying an ominclass= CONFIDENTIAL for the word REL CNTRY1 prevents REL CNTRY1 from appearing with UNCLASSIFIED in human-readable labels. In conjunction with specifying the CONFIDENTIAL output minimum classification for REL CNTRY1, the bit patterns that represent the presence of REL CNTRY1 in a label should be specified in the initial compartments and/or markings of all classifications below CONFIDENTIAL.

An ominclass can be specified in conjunction with a minclass, for a variety of reasons. As mentioned above, specifying a minclass equal to the ominclass allows adding the word to a label with a classification below the ominclass. Specifying an ominclass greater than the minclass is a common case, as indicated in the above REL CNTRY1 example, and automatically occurs when an ominclass greater than the lowest classification is specified, but no minclass is specified, in which case the minclass becomes the lowest classification.

It is meaningful, in some cases, to specify an ominclass below the minclass of the word. The word charlie in Appendix B, Annotated Sample Encodings illustrates such a case. The word charlie is an inverse word with a minclass of SECRET and an ominclass of CONFIDENTIAL. The internal representation of charlie is specified by UNCLASSIFIED labels. Ignoring the minclass specification, charlie looks very similar to the REL CNTRY1 word described above. However, with the minclass specified as SECRET, charlie can appear only in labels with classifications of SECRET or higher. Thus, UNCLASSIFIED labels have an internal representation that specifies charlie, but the word charlie does not appear in UNCLASSIFIED labels. CONFIDENTIAL labels have an internal representation that does not specify charlie, and charlie cannot appear in such a label. Adding charlie to such a label changes the classification in the label to SECRET. SECRET labels have an internal representation that does not specify charlie but charlie can be added to such a label without changing its classification, assuming the well formedness rules allow adding charlie to the label. If the ominclass for charlie was equal to the minclass instead of being below it, charlie could not be added to a confidential label (forcing the label to SECRET, as described above). With the word charlie, the choice of an ominclass of CONFIDENTIAL versus SECRET depends entirely on the desired behavior of the system when a user tries to add charlie to a CONFIDENTIAL label.

The Maxclass= Keyword

The optional maxclass= keyword specifies the maximum classification with which the word should be associated. The classification specified starts with the first non-blank character following the blank after the keyword, and continues up to the next semicolon or the end of the line. The classification can be either the short, long, or alternate name of a classification defined in the CLASSIFICATIONS: section. If the maximum classification with which a word can be associated is the classification with the highest value (as defined by the value= keyword), then there is no need to make a maxclass= keyword specification.

The maxclass= keyword must be used with extreme caution. Care must be taken if maxclass= is specified for a word to insure that the classification in a label with the word cannot be raised through combination with a label containing a higher classification. Such a combination must automatically remove the word with the maxclass. Note that both words in Appendix B, Annotated Sample Encodings with a maxclass= specification, bravo4 and charlie, are inverse words that are removed upon combination with a label with a higher classification:

The Omaxclass= Keyword

The optional omaxclass= keyword specifies the output maximum classification for the word. The output maximum classification is the maximum classification with which the word can be output (i.e., appear in a human-readable representation of a label converted from internal format). The classification specified starts with the first non-blank character following the blank after the keyword and continues up to the next semicolon or the end of the line. The classification can be the long, short, or alternate name of a classification defined in the CLASSIFICATIONS: section. If the output maximum classification with which a word can be associated is the classification with the highest value (as defined by the value= keyword), then there is no need to make an omaxclass= keyword specification.

This keyword supports a marking like EFTO (Encrypt For Transmission Only), which should appear in only UNCLASSIFIED human-readable labels, but is semantically present in all labels with classifications above UNCLASSIFIED. To support EFTO, with markings bit N, the encodings should specify markings bit N as a default bit for classification above UNCLASSIFIED:

CLASSIFICATIONS:

name= UNCLASSIFIED;	value= 1;	

name= CONFIDENTIAL;	value= 4;	initial markings= N;

name= SECRET:	value= 5;	initial markings= N;

name= TOP SECRET;	value= 6; 	initial markings= N;

and then specify EFTO as a word with an omaxclass of UNCLASSIFIED:

name= EFTO;   omaxclass=UNCLASSIFIED;   MARKINGS= N;

With these specifications, EFTO does not appear in human-readable representations of CONFIDENTIAL, SECRET, and TOP SECRET labels, but its internal (bit) representation is present in these labels. With these specifications, if an information label of UNCLASSIFIED EFTO is combined with one of SECRET, the result is SECRET.

The Compartments= Keyword

The optional compartments= keyword is used to specify which compartment bits (if any) must be 1 or 0 if the word is present in a label. For example, if the word is a codeword of a particular compartment, the compartment bit associated with that compartment would also be associated with the codeword.

The specification of compartment bits starts with the first non-blank character following the blank after the keyword, and continues up to the next semicolon or the end of the line. The specification consists of zero or more blank-separated subspecifications which consist of either 1) a decimal integer specification of a bit position, numbering bits from the left starting at 0, or 2) a range of such bit positions specified as two decimal integers with a “-” in between. The start of a range must be lower than the end of a range. The maximum bit position allowed is 127, for a total of 128 bits. Each of these subspecifications can be immediately preceded by a ~ (with no blank in between) to indicate that the specified bits must be 0.

The following table shows compartments specification examples.

Table 4–1 Compartments Specifications

Specification 

Meaning 

compartments= 1; 

Compartment bit 1 must be on (1)  

compartments= 2-3; 

Compartment bits 2 and 3 must be on (1) 

compartments= ~4; 

Compartment bit 4 must be off (0); this would be an inverse compartment bit 

compartments= ~5-7; 

Compartment bits 5, 6, and 7 must be off (0) 

compartments= 1 3; 

Compartment bits 1 and 3 must be on (1) 

compartments= ~4 6; 

Compartment bit 4 must be off (0), and bit 6 must be on (1) 

compartments= ~4 ~6; 

Compartment bits 4 and 6 must be off (0) 

compartments= 2 4-6; 

Compartment bits 2, 4, 5, and 6 must be on (1) 

compartments= ; 

Ignored 

The compartments= keyword is of critical importance in implementing the desired label adjudications for the words in a system, because this keyword, along with the markings= keyword, specifies the association between human-readable words and the internal bit representations that are logically “or-ed” together when labels are adjudicated. Chapter 8, Enforcing Proper Label Adjudications discusses how the compartments= and markings= (see below) keywords can be used to effect the various types of adjudications described in Chapter 1, Introduction.

The Markings= Keyword

The optional markings= keyword is used to specify which marking bits (if any) must be 1 or 0 if the word is present in a label. For example, if the word is a codeword, the marking bit(s) associated with that codeword would be specified.

The specification of marking bits starts with the first non-blank character following the blank after the keyword, and continues up to the next semicolon or the end of the line. The specification consists of zero or more blank-separated subspecifications which consist of either 1) a decimal integer specification of a bit position, numbering bits from the left starting at 0, or 2) a range of such bit positions specified as two decimal integers with a “-” in between. The start of a range must be lower than the end of a range. The maximum bit position allowed is 127, for a total of 128 bits. Each of these subspecifications can be immediately preceded by a ~ (with no blank in between) to indicate that the specified bits must be 0.

The following table shows markings specification examples.

Table 4–2 Markings Specifications

Specification 

Meaning 

markings= 1; 

Marking bit 1 must be on (1)  

markings= 2-3; 

Marking bits 2 and 3 must be on (1) 

markings= ~4; 

Marking bit 4 must be off (0); this would be an inverse marking 

markings= ~5-7; 

Marking bits 5, 6, and 7 must be off (0) 

markings= 1 3; 

Marking bits 1 and 3 must be on (1) 

markings= ~4 6; 

Marking bit 4 must be off (0), and bit 6 must be on (1) 

markings= ~4 ~6; 

Marking bits 4 and 6 must be off (0) 

markings= 2 4-6; 

Marking bits 2, 4, 5, and 6 must be on (1) 

markings= ; 

Ignored 

The markings= keyword is of critical importance in implementing the desired label adjudications for the words in a system, because this keyword, along with the compartments= keyword, specifies the association between human-readable words and the internal bit representations that are logically “or-ed” together when labels are adjudicated.

Chapter 8, Enforcing Proper Label Adjudications discusses how the compartments= and markings= (see above) keywords can be used to effect the various types of adjudications described in Chapter 1, Introduction.

The Access Related Keyword

The optional access related keyword, when present, specifies that the word is considered access related and must therefore appear in the warning statement on printed output banner pages. More precisely, the access related keyword should be specified for information label words 1) whose addition to a label increases the sensitivity of the label and 2) that do not also appear in sensitivity labels. Banner pages contain warning statements specifying how information is to be protected unless it is manually reviewed and downgraded. Therefore, if an information label word is access related (e.g. NOFORN), it will appear in the banner page warning statement if it is defined with the access related keyword. Figure 4–1 shows the format of a printer banner page example with an access related word denoted.

Figure 4–1 Printer Banner Example Denoting Access-Related Word

Illustration shows a printer banner with the access-related
word "NOFORN" highlighted after the label "TOP SECRET A B SA".

The Flags= Keyword

The optional flags= keyword, when present, specifies which of 15 flags should be associated with this word. The flags are specified as the numbers 0 through 14, in a manner identical to the specification of compartment or marking bits, although the ~ has no meaning in this context. Flags are not used by the system itself, but could be used by applications specifically written to use them.

Flags might be used to define certain words that appear only in printer banner labels, not in normal labels. Flags could also be used to define certain words that appear only in labels embedded in formal message traffic. See Specifying Aliases in Chapter 7, General Considerations for Specifying Encodings for more information on the potential usage of flags.

The Required Combinations: Subsection

The REQUIRED COMBINATIONS: subsection is used to specify any combinations of two words that must always appear together in a human-readable label. This subsection states criteria for well formed labels. This section can contain zero or more required combination specifications. Each required combination is specified on a separate line following the REQUIRED COMBINATIONS: keyword. Each such line should consist of exactly two label words, and is taken to mean that the first word, if present, must be combined with the second word. Any required prefixes or suffixes must also be specified. Any number of lines containing required combinations can be specified. The end of the list is taken to be a line starting with the COMBINATION CONSTRAINTS: keyword.

Note that required combinations are not bidirectional. That is, the required combination:

WORD1 WORD2

means that WORD1 cannot appear without WORD2, but does not mean that WORD2 cannot appear without WORD1.

Required combinations are automatically enforced during translation from human-readable to internal formats. Thus, given the above example, if the label TS WORD1 were entered, the translation would automatically add WORD2 to the label.

Chapter 7, General Considerations for Specifying Encodings discusses some very important considerations concerning the specification of required combinations.

The Combination Constraints: Subsection

The COMBINATION CONSTRAINTS: subsection is used to specify certain kinds of constraints on the combination of words in a human-readable label. This subsection states criteria for well formed labels. This section can contain zero or more required combination specifications. Whereas the REQUIRED COMBINATIONS: subsection described above specified which label words must be combined, the COMBINATION CONSTRAINTS: subsection specifies what label words cannot be combined. Each combination constraint is specified on a separate line following the COMBINATION CONSTRAINTS: keyword. Each such line should consist of exactly one constraint specification (see below for a discussion of continuation lines). Any required prefixes or suffixes must also be specified. Any number of lines containing combination constraints can be specified. The end of the list is taken to be a line starting with the SENSITIVITY LABELS: keyword.

Combination constraint lines can take one of the following three forms:

  1. 	WORDS1 ! WORDS2
  2. 	WORDS1 & WORDS2
  3. 	WORDS1 &

In all of the cases above, WORDS1 and WORDS2 represent either a single word or multiple words separated by “ | ” (think of | as meaning “or”). Note that blanks or tabs must appear on both sides of the !, &, and | characters in combination constraints. Form 1 specifies that none of the words WORDS1 can be combined with any of the words WORDS2. Form 2 specifies that any of the words WORDS1 can be combined only with any of the words WORDS2 (it specifies nothing about what the words WORDS2 can or cannot be combined with). Form three specifies that any of the words WORDS1 cannot be combined with any other words.

Because combination constraint lines can get very long, and because each constraint must be on its own line, combination constraint lines can be continued onto the next real line of the file. A combination constraint line is continued by using a \ as the last character of the line. A blank must precede the \. The next non-blank line after a line ending with a \ is taken to be a logical continuation of that line. A single word (including its prefix and/or suffix) cannot be separated with a \; each word must appear together on the same actual line. Thus, using words from Appendix B, Annotated Sample Encodings.

REL CNTRY3 ! REL CNTRY1 | \

REL CNTRY2

is a valid continuation of a combination constraint, whereas

REL CNTRY3 ! REL  \

CNTRY11 | REL CNTRY2

is invalid because the prefix REL and the base word CNTRY1 were split across two lines.

Combination constraints need not be specified among words in a hierarchy. In other words, if WORD2 is in a hierarchy over WORD1, then these two words can never appear together in a label. There is no need to additionally specify a combination constraint to prevent their combination.

Similarly, any non-hierarchical mutually exclusive words need not be specified in combination constraints. For example, consider the specification of the following two words:

name= WORD7;   markings=   6 ~7; 
name= WORD8;   markings= ~6   7;

The bit encodings of these two words make them mutually exclusive, yet they are not hierarchically related. Such words are automatically prevented from appearing together in a label, even if a combination constraint is not specified.

Conversely, combination constraints cannot prevent the combination of words if the bit encodings of those words force their combination, such with a non-hierarchical composite word (see Chapter 8, Enforcing Proper Label Adjudications). For example, consider the three words:

name= WORD12;	markings= 6 7; 
name= WORD10;	markings= 0 6;
name= WORD11;	markings= 1 7; 

Note that there are no hierarchies among these words. If both WORD10 and WORD11 are in a label, WORD12 is also automatically present. A combination constraint cannot be used to keep WORD12 from appearing in a label with either WORD10 or WORD11, as long as WORD10 and WORD11 can be combined.

Chapter 7, General Considerations for Specifying Encodings discusses some very important considerations concerning the specification of combination constraints.