ietf-smime
[Top] [All Lists]

RE: ESS EquivalentLabel Proposal

1998-05-28 14:23:39
John and Darren,

I am afraid that I am going to have to disagree.  After spending some more
time looking at the proposal, many of my original fears are now fleshed out.

It appears that this would be something that is added by gateways and not by
senders.  The problem is that gateways cannot solve the problem without
completely breaking security.

1.  It is not possible to modify the security label on an embedded message
without breaking the outer message's signature.

2.  It is not posible to modify the security label on a message which has
encryption applied to it, unless the gateway is one of the encryption
receipients or it has a copy of all users keys.

3.  One must construct a set of rules to decide if the signer of the
ESSEquivalentLabel knows what they are talking about.  There is nothing to
prevent random originators from including this attribute.

4.  This proposal does nothing to allow for dynamic changes in the policy.
If I receive the mail before the mapping goes into effect or if the mapping
is removed after I receive the mail, no changes in the equivalence can be
updated.

5.  Depending on the speed that CMS gets finished, I think this is going to
slow ESS from last call.  I think this is going to be an item of
controversy.

6.  If I have two policy modules installed on the system, one for OID A and
one for OID B, do I check all possible policys for acceptance?  You now have
introduced a degree of ambiguitiy since there are multiple possible policies
which apply.

7.  There is now a question about forwarding of messages between different
orgs which may or may not agree on policy mappings.  What happens if I send
a message from A to B, which adds an equivalence label, and then from B to
C, which adds an equilvance label, I now have multiple conflicting
equivalency labels.  How do I select the correct one and do the mapping?

8.  The adding of a security label by the gateway can be accomplished by
just adding a security label, there is no need to have an equivalency label
in this case.


-----Original Message-----
From: Darren Harter [mailto:dharter(_at_)email(_dot_)msn(_dot_)com]
Sent: Monday, May 25, 1998 9:02 PM
To: ietf-smime
Subject: Fw: ESS EquivalentLabel Proposal


Sorry, Forgot to CC the list on my reply....

Darren

-----Original Message-----
From: Darren Harter <dharter(_at_)email(_dot_)msn(_dot_)com>
To: John Pawling <jsp(_at_)jgvandyke(_dot_)com>
Date: Sunday, May 24, 1998 12:25
Subject: Re: ESS EquivalentLabel Proposal


John,

IMO, I think this is an excellent proposal.  I personally send paper-based
messages marked under different labelling policies every day - sometimes
these messages are marked under different labelling schemes for each
recipient, although the labels themselves are semantically equivalent (i.e.
All recipients understand them as meaning the same thing).

I was concerned as to how I would implement this using S/MIME, but your
proposal solves the problem with, I believe, an added bonus.  If I connect
to domains together that operate under different labelling policies, and
the
management of those domains can agree on a mapping between the different
elements of the labels employed, a single gateway device could add an
ESSEquivalentLabel  to each message as it passed between domains.
Applications in the receiving domain would not process the ESSSecurityLabel
as they would not understand the policy OID in it, but they would process
the ESSEquivalentLabel  as they would understand the policy OID in that.
The advantage being that when you connect domains together you don't have
to
upgrade each end system to understand the new labelling policies, they only
have to understand their own.

I believe this is a simple and obvious addition to ESS, and probably one
that the IESG would have raised on submission for an RFC.

Darren






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