Let me summarize my position (and the position of many others with whom I
have discussed this issue). The current ESS strategy (all eSSSecurityLabels
in a signedData MUST be identical) meets all of the requirements that some
have argued should be met by including different, semantically-equivalent
eSSSecurityLabels in a single signedData object. This is true because the
originator and each recipient can locally translate the "identical"
eSSSecurityLabel to a specific security policy, if required.
Furthermore, ESS MUST prohibit semantically different eSSSecurityLabels from
being included in a single signedData because that creates a significant
possiblity that there will be contradictions between the semantically
different labels that would lead to errorneous or inconsistent access
Therefore, since different, semantically-equivalent eSSSecurityLabels are
not required and semantically-different eSSSecurityLabels MUST be
prohibited, then the current ESS text is correct to mandate that all
eSSSecurityLabel attributes present in a signedData object must be identical.
You cite the
access control requirement, which is of course not satisfied by
SignedData nesting any more than it is by using parallel SignerInfos,
and is therefore not an argument for or against either method.
I disagree with everything after "of course". The ESS "nested signedData"
strategy provides the local organization with the flexibility to generate
its security policy such that the actions taken when an access control
failure occurs while processing an outer signedData are different (if
required) than when an access control failure occurs while processing an
inner signedData. The "nested signedData" strategy makes this simple to
specify and simple to implement. This facilitates a simple strategy by
which a recipient can distinguish "outer" gateway-applied security labels
from the "inner" security label applied by the original signer who made the
original decisions regarding the sensitivity of the content. This
granuluarity is more complicated to specify and to implement in the
processing of parallel signerInfos in a single signedData that contain
different eSSSecurityLabels. Mandating that all eSSSecurityLabels must be
identical in a signedData ensures that only a single semantic label is bound
with the content and that significantly simplifies the access control problem.
John Pawling, jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.