Dave,
If you could produce an example demonstrating an incorrect access
control decision, I would be more inclined to believe this assertion.
OK, lets assume that anybody can add whatever eSSSecuritylabel to a
signedData object that they desire. Assume User A drafts a content, decides
that the content is classified ACME PROPRIETARY and sends the signedData in
which User A's signerInfo includes an ESSSecurityLabel including the ACME
PROPRIETARY security classification. Assume user B receives user A's
signedData, decodes it, decides that it should really be classified as ACME
PERSONNEL DATA. User B adds her signerInfo to the original signedData
object in which she includes an ESSSecurityLabel including the ACME
PERSONNEL DATA security classification and sends it off. User C receives
the signedData from User B. User C's software verifies User B's signerInfo
and User A's signerInfo. User C's SW detects one ESSSecurityLabel including
the ACME PROPRIETARY security classification and another ESSSecurityLabel
including the ACME PERSONNEL DATA security classification. What is the real
classification of the content???? That is the problem.
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.
I disagree. With the current ESS strategy, a separate decsion is made for
each encapsulated content. That is an important distinction.
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.
First, let me add some detail to your left diagram:
_______________
| ___________ |
| | | |
| | _________ | |
| || Inner || |
| || Content || |
| ||- - - - -|| |
| || Label X || |
| ||_________|| |
| | | |
| | Outer | |
| | Content | |
| ----------- |
|- - - - - - - -|
| Label Y |
|_______________|
My point is that there are two completely independent access control
decisions made. One decision is based on Label Y which applies to the outer
content. The other decision is based on Label X which applies to the inner
content. This "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.
In the model on the right, there is a single access control decision
applying to the content that includes Label X and Label Y as inputs. If
Label X and Label Y are different, what is the real classification of the
content upon which the single access control decsion is to be based????
That is the problem.
(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.)
We are not talking ONLY about recipient-based access control decisions. The
current ESS strategy does not limit access control to ONLY being
recipient-based. An access control strategy MUST include checking a
recipient's authorizations before sending sensitive data to that recipient
to ensure that the recipient's authorizations indicate that the recipient is
allowed to have access to the data. IMHO, we should not specify access
control strategies in the S/MIME specs. This should be left to the local
organizations.
================================
John Pawling, jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
www.jgvandyke.com
================================