From: jsp(_at_)jgvandyke(_dot_)com (John Pawling)
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,
I don't disagree with the requirement; I do disagree that the
"identical label" restriction simplifies the access control problem.
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
control decisions.
If you could produce an example demonstrating an incorrect access
control decision, I would be more inclined to believe this assertion.
My assertion is that the identical decision will be produced from a
set of semantically different labels regardless of whether the signatures
are wrapped or parallel.
Consider the following two messages, where the boxes represent SignedData
structures, and "Label X" and "Label Y" represent semantically different
eSSSecurityLabels contained in the signed-attributes of two SignerInfo
structures. With the current restriction, only the left message is legal.
If the restriction were eliminated, both the left and the right messages
would be legal, and the choice of which to use could be based on other
criteria.
_____________ _________
| _________ | | Content |
| | Content | | |- - - - -|
| |- - - - -| | | Label X |
| | Label X | | |- - - - -|
| |_________| | | Label Y |
|- - - - - - -| |_________|
| Label Y |
|_____________|
An ACDF operating on Label Y and the recipient's privileges will produce
a binary access decision "Grant" or "Deny" (True or False). An ACDF on
Label X and the recipient's privileges will produce another binary
decision. Please explain how those decisions when applied to the left
message will be correct and consistent, while the same decisions applied
to the right message might be erroneous or inconsistent.
Remember, we aren't talking about EnvelopedData, where double or triple
wrapping is necessary (and meaningful); we're talking about a
restriction which (IMHO unnecessarily) forces wrapping of a SignedData
within another SignedData.
(Remember too that we're discussing recipient-based access control of
unencrypted data, which is a near-zero-assurance process. But that's
another topic altogether.)