Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org> wrote:
Do others on the list agree with Jim that, even if we can define
EquivalentLabels, they will not be of enough value to add them in at this
late date?
Paul,
No, I think this sounds like a valuable feature. I've been concerned about
label policy mapping since it was raised earlier this year, and this gives us a
much better (and more appropriate) alternative to wrapping successive layers of
SignedData.
I say accept John's proposal.
Chris
-----------------------------------------------------------
| International Electronic Communication Analysts, Inc. |
| Christopher D. Bonatti Principal Engineer |
-----------------------------------------------------------
_____________________
Subject: RE: ESS EquivalentLabel Proposal
Date: Thu, 28 May 1998 17:31:04 -0700
From: Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org>
To: <ietf-smime(_at_)imc(_dot_)org>
At 05:11 PM 5/28/98 -0700, Jim Schaad (Exchange) wrote:
I don't believe that this solves a large enough set of problems to be
interesting.
This I might agree with. On the other hand, many of the things in ESS might
fall into that category as well.
Do others on the list agree with Jim that, even if we can define
EquivalentLabels, they will not be of enough value to add them in at this
late date?
I would hardly call items 1 and 2 irrelevant. These are
normal cases which will show up in day to day actvities.
Sure. But there are lots of other things we would want to do with inner
signatures that we can't, such as add countersignatures. I don't see the
desire to add EquivalentLabels as different from other desires.
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.
Sorry, I thought that was obvious. A recipient would have a list of trusted
mappers. The new addition now reads:
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; determining who is allowed to specify equivalence mappings is a
local policy. 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 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.
See the wordiing above. You check both, and they do not need to be
identical. If both check out and both are authorized to do mappings and
both are different, you pick either. It's just like a single policy that
has an "or" in it.
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.
I agree. On the other hand, I don't think it hurts, and it helps a bit
because it labels the new policy as a mapped one, not an original. But I'm
not particularly attached to it.
--Paul Hoffman, Director
--Internet Mail Consortium