[Top] [All Lists]

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

1998-04-14 01:53:25
I agree with David, because the access control  decision process within the
recipients security domain will depend on which security policy is supported
(i,.e. is it Label x or Label y policy).

If the security policy of the recipients domain supports both label
policies, then both labels will be used irrespective of nesting.

However, if only one of the two security label policies is supported then
that is the label the recipients domain will use. Again this will be
irrespective of nesting (i.e it may or may not be nested labels).

I agree that the originators view of the classification (or other marking)
of the message should be respected by the recipient domain, but that is
achieved by guards at domain boundaries which do not let messages pass out
of a security domain into a security domain they do not trust will respect
the semantics of the originators label.

Once a security domain "releases" a message out of it's domain and control,
it must trust recipients domain will do the honourable thing and respect the
label semantics (irrespective of the syntax and which label is supported in
the recipients domain, which may be : x , y or both).  If a security domain
does not trust another security domain, it should not let the message pass
between the domains, this would be achieved by a suitable guard function.

-----Original Message-----
From: Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org>
To: ietf-smime(_at_)imc(_dot_)org <ietf-smime(_at_)imc(_dot_)org>
Date: 13 April 1998 23:35
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)

At 03:08 PM 4/13/98 -0400, David P. Kemp wrote:
  _____________          _________
 |  _________  |        | Content |
 | | Content | |        |- - - - -|
 | |- - - - -| |        | Label X |
 | | Label X | |        |- - - - -|
 | |_________| |        | Label Y |
 |- - - - - - -|        |_________|
 |   Label Y   |

This is a great picture of the problem with your advocacy of the scenario
on the right. On the left, the security processing software knows exactly
who the originator of the content is and can choose whether or not to honor
Label Y based on that knowledge. In your scenario, the processing software
has no idea which label was applied by the original signer.

Assume that the recipient's processing software has a policy that says "if
you don't understand a security label, toss the message if that label was
issued by the sender but ignore the label if it was added somewhere else".
In human terms, this says "ignore outer security information but pay
attention to the sender's wishes". This works fine for wrapping and fails
completely with signerInfo stuffing.

Basically, we have to trust the sender to specify their wishes.

--Paul Hoffman, Director
--Internet Mail Consortium