ietf-smime
[Top] [All Lists]

RE: ESS EquivalentLabel Proposal

1998-05-28 15:23:41
At 02:28 PM 5/28/98 -0700, Jim Schaad (Exchange) wrote:
It appears that this would be something that is added by gateways and not by
senders.

Correct. The sender would put what they thought the right label the
recipient could use. I envision that it would be incoming gateways that
would be putting on EquivalentLabels. That is, for
SenderA -> STMPX -> the Internet -> STMPY -> RecipientB
the equivalent labels would go on at SMTPY or after.

The problem is that gateways cannot solve the problem without
completely breaking security.

I disagree. It cannot solve all problems, but EquivalentLabels solves some
of them without breaking anything.

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

True, but irrelevant. In the case of a wrapped message, inner security
labels are untouchable.

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.

True, but irrelevant. This is true for any attribute added to an encrypted
message anywhere in the stream.

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.

Correct. However, it's up to the recipient to determine what to do with
random EquivalentLabels. I propose adding the following text:

When processing an EquivalentLabels attribute, the receiving agent MUST
validate the signature onthe EquivalentLabels to determine if there are
additional security labels it wishes to use. A receiving agent MUST NOT act
on EquivalentLabels for which the signature could not be validated or
EquivalentLabels not signed by entities trusted to add or change access
policies. A receiving agent SHOULD process the ESSSecurityLabel before
processing the EquivalentLabels. If the policy in the ESSSecurityLabel is
understood by the receiving agent, it SHOULD process that label and ignore
the EquivalentLabels.

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.

Er, so what? That's true of all security labels, not just mapped ones. If I
send a message which refers to a policy that gets changed before the
message is received, I'm in the same boat.

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.

Unfortunately, I disagree: we have a fair of time while we wait for patent
issues with CMS and PKIX to settle.

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.

Good point. I believe my additional text above covers this.

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?

I don't see them as conflicting. I think the scenario you meant to describe
was you receive a message with an ESSSecurityLabel, an EquivalentLabels
signed by B, and an EquivalentLabels signed by C. If you don't know the
policy in the ESSSecurityLabel, and you verify and trust both B and C, you
can pick either of the EquivalentLabels to use in processing.

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.

I have no idea what you mean here. You can't "just add" a conflicting
security label in the same level as on that is already there. Could you be
more specific about this scenario?

--Paul Hoffman, Director
--Internet Mail Consortium

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