ESSSecurityLabel Change

John,

You are probably not going to believe this, but I agree with your proposal
to make the eSSSecurityLabel security-policy-identifier a mandatory field.
The security-policy-identifier identifes the syntax and semantics of the
remaining fields, so I agree that it must always be present.  I agree that
the syntax should force the security-policy-identifier to always be present.
This reults in the following new ESSSecurityLabel syntax:

ESSSecurityLabel ::= SET {
  version                    [0] Version DEFAULT v1,
  security-policy-identifier     SecurityPolicyIdentifier,
  security-classification        SecurityClassification OPTIONAL,
  privacy-mark                   ESSPrivacyMark OPTIONAL,
  security-categories            SecurityCategories OPTIONAL }

ESSPrivacyMark ::= CHOICE {
    pString                      PrintableString (SIZE
(1..ub-privacy-mark-length)),
    -- If pString is used, the ESSSecurityLabel version is set to v1
    utf8String               [1] IMPLICIT OCTET STRING SIZE (1..MAX)
    -- If utf8String is used, its contents MUST be in UTF8 format, and
    -- the ESSSecurityLabel version is set to v2
}


I believe that ESS should state: "Receiving agents SHOULD have a local
policy regarding whether or not to show the inner content of a signedData
object that includes an eSSSecurityLabel security-policy-identifier that the
processing software does not recognize.  If the receiving agent does not
recognize the eSSSecurityLabel security-policy-identifier value, then it
SHOULD stop processing the message and indicate an error."

I agree with your statement: "and make the access control processing of the
eSSSecurityLabel depending on supporting the value of the
SecurityPolicyIdentifier."  I beleive that ESS Section 3 already makes that
clear.  I don't believe that ESS should include any further requirements
regarding processing security labels or mandating access control strategies.
Those are issues for local organizations to determine when they define their
security policies and access control strategies.  This is consistent with
your statement that access control is dependent on the
security-policy-identifier value.

You stated: "Your concern about complex access control rules still applies
in the multi-wrapping case.  Whenever multiple labels can exists, complex
access control rules are needed to process them."  I agree that complex
access control rules still apply in the multi-wrapping case, but at least we
can simplify the access control decision applied to each signedData object
by mandating that all essSecurityLabels in the signedData onject MUST be
identical.   That way we avoid the situation, for example, in which one
eSSSecurityLabel in a signedData states "US SECRET" and another states "US
UNCLASSIFIED".  With the separate wrappers, it simplifies the overall access
control decision strategy.  For example, a local organization may have
different strategies for handling access control failures in outer
signedData objects than in inner signedData objects.

In summary, I don't believe that ESS should mandate the access control
stratgies to be used by local organnizations, but I believe that we can make
some simple rules (as are currently included in ESS) to simplify the
decision made for each signedData object.

================================
John Pawling, jsp(_at_)jgvandyke(_dot_)com                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================