John,
My comments regarding access control checks were meant to support my
assertion that multiple different security labels are not required to be
attached to a single content. I was not implying that my statements should
be incorporated into the ESS I-D.
You stated:
This means that all originators must know all the recipients security
policy. I do not agree that this is practical solution in a global messaging
environment.
That is the only solution. If an originator does not understand the
authorizations of a recipient, then she had better not send a sensitive
message to that recipient.
This assumes that all recipients will understand security labels from all
users in all security domains, and be able to map the security label they
receive to one understood under the local security policy.
That is correct. If you don't understand somebody else's security policy,
then don't communicate sensitive data with them.
Would it not be
more practical to do that mapping just one at security domain boundary?
I believe that the security label values assigned by the human signer are
sacred and must not be removed, changed, superseded or otherwise corrupted.
The human signer understands the complete context of the message and the
security policy rules that apply to labeling that message. The human signer
makes conscious decisions regarding the sensitivity of the content which may
be based on subjective or other knowledge that is not available to the
gateway software. Therefore, I disagree with your implication that a
gateway should change the signer's label or inlcude a translated label in
the signer's signedData object. If the gateway wants to add an outer
signedData including a translated label, then that is fine because the GW is
the signer of that signedData and can populate the security label with the
appropriate values. The recipient will be able to easily distinguish
between the GW's outer signedData and human signer's inner signedData.
If I understand correctly your main concern, it is the possibility of
inconsistency between semantics of the security label as known and generated
by the originator and the semantics of other security labels (which may be
added later in the message path). My view is the semantics of a security
label and how it is processed on receipt is dictated by the security policy
in the receiving domain and not the originating domain.
I disagree. It is a function of all of the security policies involved with
the message transaction. If a GW strips out the signer's security label (or
otherwise supersedes it), then the recipient's software never gets a chance
to see the human signer's label.
I disagree with all of the following text because it is too detailed for
inclusion in the ESS spec. This should be up to the local organizations.
I think what you are in fact trying to achieved is a global security policy,
which in itself is a commendable goal.
Possible solution:
I wonder, if one way round this problem be to specify a default security
policy identifier in the S/MIME specifications which implies the policy you
have in mind. Which I think is something like : (When an originator uses
this policy id, it implies that the originators policy must be understood by
the recipient and supersedes any other security label within the same signed
data, if the policy id is not understood by the recipient the message shall
be rejected).
If you make the behaviour rules you are looking for dependant upon the
security policy in the way proposed above, I think the behaviour you are
looking for can be achieved. The above proposal should also meet other
domains needs as well, when other policy ids are used.
Does anybody else have a view?