Tim:
Your note has a huge impact. You point out that the message originator
cannot ensure that the recipient will honor any attributbes in SignerInfo,
even if they are marked critical. For example, the recipient can ignore
the critical attribute containing the security label.
Here at the IETF meeting, I have asked several people about the usefulness
of critical attributes. Of the people that I polled, no one supports them.
At this point, I am planning to remove critical attributes from the next
draft of the CMS document.
Russ
At 10:28 AM 3/31/98 +0100, Tim Dean wrote:
Russ,
What happens if a recipient receives a forwarded message that include a
security policy in the eSSSecurityLabel that he/she in does not
understand,
is that still an error?
Absolutely. The security label must be marked critical, so the inability
to process the critical attribute must cause an error to be reported to the
user.
I think the proposed text will mislead implementations to always discarding
the message if a security policy is unknown. I do not think that is right.
We disagree. Rule-based access control cannot be enforced if the recipient
is allowed to ignore the security label.
Two thoughts:
1. Insisting that the UA software parse and understand the label before
showing the message to the user
raises serious denial-of-service issues. There are many circumstances
when operational necessity
demands label-based access control is over-ridden - certainly on reception
in a distributed system.
There are likely to be many, many label formats floating around out there,
and systems should not stop
working just because they don't recognise all of them.
2. I am somewhat doubtful that access control in the recipient's user
agent is going to add a jot of Real
Security in practice. It would surely be extremely unwise to place any
kind of reliance on it. Any
Computer Scientist worth his salt is quickly going to figure how to
by-pass this check and read
everything which arrives in his computer. (And he is probably the kind of
person you didn't want to
unintentionally send a message to anyway!)
Therefore I think I must agree with John R's suggestion on this: or at
least make the it a configurable
option dependent on security policy. Also, ESS should probably contain a
health warning about relying
on recipient side access control processing. By all means check message
labels on transmission and at
points along the path: for example just before the message is about to
exit your organisation. Hopefully
the label semantics are understood at least that far. After that I
suspect it may be too late.
Tim
-----------------------------------------------
Tim Dean
Defence Evaluation & Research Agency
Malvern
United Kingdom
telephone: +44-1684-894239
facsimile: +44-1684-896113
e-mail: t(_dot_)dean(_at_)eris(_dot_)dera(_dot_)gov(_dot_)uk
----------------------------------------------------
John Ross wrote:
What happens if a recipient receives a forwarded message that include a
security policy in the eSSSecurityLabel that he/she in does not understand,
is that still an error?
Absolutely. The security label must be marked critical, so the inability
to process the critical attribute must cause an error to be reported to the
user.
I think the proposed text will mislead implementations to always discarding
the message if a security policy is unknown. I do not think that is right.
We disagree. Rule-based access control cannot be enforced if the recipient
is allowed to ignore the security label.
All I think needs to be done is to leave such decisions to local policy;
Thus reword your text as..
"Receiving agents SHOULD have a local policy which specifies
what action is taken when an eSSSecurityLabel is received which
includes a security-policy-identifier that the processing software
does not recognize."
If think there is a need to specify default handling, then It should be to
ignore security labels when the policy is not understood.
Completely disagree!
Also, I still think that the security policy should not be optional.
Wow. We agree on this one. The syntax that we are using comes from X.411.
In X.411, this field is optional, and we are trying to maintain
compatibility. I suggest that we use english text to state that the
security policy must be present.
-- Russ