John,
With all due respect, your message is a great example of why I oppose the
proposal to allow different eSSSecurityLabels to be present in a single
signedData object. Your message is full of assumptions about the way
organizations are going to perform access control. It implies adding
greater complexity at every stage of the processing. It assumes that there
are guards present that are going to perform various types of security
services. This is too much complexity to try to gain consensus to add to
the ESS spec. The ESS spec should leave these details to the local
organizations.
Your proposal also implies that the receiving agent will simply ignore
eSSSecurityLabels that it does not understand. This is unacceptable because
the entity that applied that security label did it for a purpose. If you
ignore that security label, you run the risk of ignoring important guidance
requested by the originator or one of the intermediate processing agents. I
believe that there should be one common eSSSecurityLabel that applies to a
single content. If the receiving agent does not understand the security
policy in the common eSSSecurityLabel, then the receiving agent should
reject the message. In most cases, the originator will have already
performed access control checks to ensure that the recipient has the proper
authorizations to receive the message. The originator should ensure that
the single eSSSecurityLabel includes values that are either defined under
the recipient's security policy or can be locally translated by the
recipient to her security policy.
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. 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 applied to a content. Therefore, since
different, semantically-equivalent eSSSecurityLabels are not required and
semantically-different eSSSecurityLabels MUST be prohibited, then the
current ESS text is correct to mandate that all eSSSecurityLabel attributes
present in a signedData object must be identical.
- John Pawling
At 09:47 AM 4/14/98 +0100, JOHN ROSS wrote:
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