All,
Recommend adding the following text as ESS Section 3.4:
"3.4. Equivalent Security Labels
Because organizations are allowed to define their own security policies,
many different security policies will exist. Some organizations may wish to
create equivalencies between their security policies with the security
policies of other organizations. For example, the Acme Company and the
Widget Corporation may reach a bilateral agreement that the "Acme private"
security-classification value is equivalent to the "Widget sensitive"
security-classification value.
The EquivalentLabel authenticated attribute is defined as:
EquivalentLabel ::= SEQUENCE OF ESSSecurityLabel
The id-equivalentLabel OID (TBD value) identifies the EquivalentLabel attribute.
As stated earlier, the ESSSecurityLabel contains the sensitivity values
selected by the original signer of the signedData. If an ESSSecurityLabel
is present in a signerInfo, all signerInfos in the signedData MUST contain
an ESSSecurityLabel and they MUST all be identical. In addition to an
ESSSecurityLabel, a signerInfo MAY also include an equivalentLabel
authenticated attribute. If present, the equivalentLabel attribute MUST
include one or more security labels that are believed by the signer to be
semantically equivalent to the ESSSecurityLabel attribute included in the
same signerInfo.
All security-policy object identifiers (OID) MUST be unique in the set of
ESSSecurityLabel and EquivalentLabel security labels. Before using an
EquivalentLabel attribute, an agent MUST ensure that all security-policy
OIDs are unique in the security label(s) included in the EquivalentLabel.
Once the agent selects the security label (within the EquivalentLabel) to be
used for processing, then the security-policy OID of the selected
EquivalentLabel security label MUST be compared with the ESSSecurityLabel
security-policy OID to ensure that they are unique.
In the case that an ESSSecurityLabel attribute is not included in a
signerInfo, then an EquivalentLabel attribute may still be included. For
example, in the Acme security policy, the absence of an ESSSecurityLabel
could be defined to equate to a security label composed of the Acme
security-policy OID and the "unmarked" security-classification.
Please note that equivalentLabel MUST NOT be used to convey security labels
that are semantically different from the ESSSecurityLabel included in the
signerInfo(s) in the signedData. If an entity needs to apply a security
label that is semantically different from the ESSSecurityLabel, then it MUST
include the sematically different security label in an outer signedData
object that encapsulates the signedData object that includes the
ESSSecurityLabel.
If present, the equivalentLabel attribute MUST be an authenticated
attribute; it MUST NOT be an unauthenticated attribute. CMS defines
authenticatedAttributes as a SET OF AuthAttribute. A signerInfo MUST NOT
include multiple instances of the equivalentLabel attribute. CMS defines
the ASN.1 syntax for the authenticated attributes to include attrValues SET
OF AttributeValue. A equivalentLabel attribute MUST only include a single
instance of AttributeValue. There MUST NOT be zero or multiple instances of
AttributeValue present in the attrValues SET OF AttributeValue."
================================
John Pawling, jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
www.jgvandyke.com
================================