Re: Signed Label (was RE: 'Signature Purpose' attribute?)

    I have some other concerns with the current restrictions on ESS security 
label.  As long as each instance of the label in the signedData element must 
contain the same value, I think there are very important scenarios that cannot 
be serviced.

    It may be necessary to for the signer to include multiple instances of the 
security label using different policy IDs and/or security category structures 
for the purpose of satisfying the requirements of multiple policy domains.  
This would require a change to the wording of ESS clause 3.1.1.  For simplistic 
labeling, this is probably not a concern.  However, we don't have (nor are we 
likely to soon have) a standard for representing categories/compartments in 
varying security domains.  As long as this is the case, we are going to have 
variations in the labeling requirements on a per-policy basis.  This will 
essentially require label conversion (as John Ross suggests) or multiple signed 
labels with different values.

    There is another circumstance in which it may be necessary to include 
either or both of an "information" or "system" security label.  If both labels 
are present, the information label will convey the "true" label of the content 
from the originator to the recipient.  The system label will convey the label 
of the content to be used for access control purposes.  This split label may, 
among other things, be used to convey the actual content classification when 
used in a system-high environment.  Whether either or both of these labels is 
present is a function of security policy.  The security policy ID may, in fact, 
be used to discriminate between these two.  This scenario likewise requires a 
change to ESS clause 3.1.1.

    It should also noted that in cases where multiple labels are provided by 
the same signer, it would be VERY inefficient to convey each of these in a 
separate signerInfo elements because of the overhead of multiple signature 
operations.  Therefore, the implied restriction in 3.1.1 on multiple instances 
of the label attribute might not make sense.

    I would suggest that a better way to handle this would be to make the ESS 
security label attribute internally multivalued and include a mechanism for 
identifying the purpose of each instance of the label.  For example, the ESS 
label attribute could be changed to the following:

        ESSSecurityLabel ::= SEQUENCE OF LabelItem

        LabelItem ::= SEQUENCE {
            security-label    SecurityLabel,
            label-purpose    LabelPurpose }

        LabelPurpose ::= ENUMERATED {
             system-label (0),
             information-label (1), ... }

        SecurityLabel ::= SET {
            security-policy-identifier    SecurityPolicyIdentifier OPTIONAL,
            security-classification        SecurityClassification OPTIONAL,
            privacy-mark                    ESSPrivacyMark OPTIONAL,
            security-categories            SecurityCategories OPTIONAL }

This plus some better wording in secution 3 of ESS could open S/MIME up to 
support a more complex labeling environment.

    Thoughts?

Chris


 ---------------------------------------------------------------
 |  International Electronic Communication Analysts, Inc.      |
 |  Christopher D. Bonatti                 9010 Edgepark Road  |
 |  Vice-president                     Vienna, Virginia 22182  |
 |  bonattic(_at_)ieca(_dot_)com   Tel: 301-212-9428   Fax: 703-506-8377  |
 ---------------------------------------------------------------