[Top] [All Lists]

Re: Signed Label (was RE: 'Signature Purpose' attribute?)

1998-04-14 08:09:26
John (P)

I think I now understand your key assumption:

You state:" The originator should ensure that the single eSSSecurityLabel
includes values that are either defined under the recipient's security

This means that all originators must know all the recipients security

I do not agree that this is practical solution in a global messaging

Also you state:"Another reason that I disagree with your scenarios is
because there is no reason to include different semantically-equivalent
eSSSecurityLabels in a single signedData object because the originator and
each recipient can locally translate the "identical" eSSSecurityLabel to a
specific security policy, if required."

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.  Would it not be
more practical to do that mapping just one at security domain boundary?

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 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?

<Prev in Thread] Current Thread [Next in Thread>