The intended usage of the initial compartments and initial markings specifications when used to specify inverse compartment or marking bits is described below. Potentially, the initial compartments and initial markings keywords can be used more flexibly than described below, but any such usage should be very carefully scrutinized to determine that the desired security and labeling properties are represented.
The intended usage is described below in terms of inverse words of the form REL XX, whose meaning is that data associated with the word is releasable to XX, where XX could represent a country, an organizational affiliation, or even a person.
It is often true that data of the lowest classification (or possibly classifications) is always releasable without restrictions. Therefore, the internal format of labels with the lowest classification would specify that all such REL XX words be logically present. Having these words present means that their associated bits should be 0. Therefore, it is not necessary to specify these inverse bits as initial compartments or markings in the lowest classification.
For classifications greater than the lowest, it would therefore typically follow that the bits associated with the REL XX words should be 1, because data whose label is one of these classifications standing alone is not releasable. Therefore, the same initial compartments (representing inverse bits) – if any – are intended to be specified for all classification values other than the lowest, and the same initial markings (representing inverse bits) – if any – are intended to be specified for all classification values other than the lowest.
When allocating compartment and marking bits, careful consideration must be given to deciding how many inverse bits should ever be needed throughout the life of the system. All inverse bits ever anticipated to be used on the system should be specified in the initial compartments and markings specifications even if they are not used initially for any marking words in the encodings. The best way to describe why this preallocation of inverse bits is necessary is to show what happens if inverse bits are not preallocated. Assume that marking bit 11 is encoded as an inverse bit whose meaning is REL CNTRY3 (as specified in Annotated Sample Encodings). Further assume that there are no other inverse marking bits and that marking bit 12 is assigned no meaning. Since marking bit 11 is the only inverse marking bit, the initial markings specification would be:
initial markings= 11;
If the system was used with the encoding file in this condition, a large number of information labels would be stored on the system (and on backup tapes) with marking bit 12 (and all other unused bits) having the value 0. Then, if it is later decided that REL CNTRY4 must be encoded using an inverse marking bit and bit 12 (or any other unused bit) is chosen, then all data previously stored on the system would automatically be treated as REL CNTRY4 because that would be the meaning of marking bit 12 being 0. Of course, all of the data would not be releasable to CNTRY4, such that all data on the system (and on backup tapes) would have to be relabeled. Therefore, it is best to preallocate some range of bits as inverse bits when the encodings file for a system is first loaded. Then, preallocated unused inverse bits can be later assigned meaning without the need to relabel.
Note that the above discussion covers the simplest and most common usage of inverse bits. More complex usage of inverse bits is possible, and needed in some instances. As an example, see the hypothetical bravo4 codeword in Annotated Sample Encodings.