-----Original Message-----
From: Paul Hoffman / IMC [mailto:phoffman(_at_)imc(_dot_)org]
Sent: Thursday, May 28, 1998 3:28 PM
To: ietf-smime
Subject: RE: ESS EquivalentLabel Proposal
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.
I don't believe that this solves a large enough set of problems to be
interesting. I would hardly call items 1 and 2 irrelevant. These are
normal cases which will show up in day to day actvities. I forward a piece
of mail to you which was signed and labeled by the originator --- you can't
open the message because you don't understand the policy involved. This is
exactly the type of thing I though this was suppose to solve.
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.
You need to do more than this. You must also verify (somehow) that the
signer of the equivalence label is trusted to do equivalence mapping, or you
must ignore the mapping.
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.
Yes that is true, however it is far more likely that I will change my
understanding of YOUR security policy than I will make an incompatable
change in MY security policy. Most of the time when policies are changed
locally they are not done in a "drastic" way. You add a new level or maybe
colapse together a couple of levels. You don't make a change along the
lines of "secret just became un-marked". You break secret into two
different levels.
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.
You may be right about this.
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.
You covered half of my issue What if two different signers have two
different ESSEquivalentLabels on them. Do I check both or must they be
identical.
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?
Not enough text. This had to do with the case of adding an equivlance
mapping when no security label existed on the message, i.e. no label is the
same as un-marked. There is no real need to have the equivalence label to
support this configuration.
--Paul Hoffman, Director
--Internet Mail Consortium
jim