Russ,
I completely agree with your argument when it is applied to the inner
security label (i.e. securityLabel authenticated attribute included in inner
signedData layer).
However, I disagree with your argument when applied to the outer security
label (i.e. securityLabel authenticated attribute included in outer
signedData layer). The outer layer is intended to provide security services
between intermediate entities in addition to involving end entities. When
an intermediate entity creates an outer signedData object, it signs the data
included in that object. IMHO, it is OK for the MLA to compose a new
securityLabel based on the MLA's local policies. The bottom line is that
the MLA signs the securityLabel that it constructs. If ESS included a rule
limiting the values that an intermediate entity can place in the
securityLabel that it creates in the outer signedData, then it is impossible
for the recipient to cryptographically verify that the intermediate entity
actually followed the securilyLabel-related rule because the recipient
verifies the intermediate entity's signature of the outer signedData
(including authenticated attributes including the securityLabel).
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
===============================
At 06:07 PM 2/28/98 -0500, Russ Housley wrote:
John:
I understnad your point, and I mostly agree. I am concerned with label
translation. Translation is never perfect. Translating from domain A to
domain B will loose informations (or worse), and then translation back to
domain A will result in a different label. For this reason, I think it is
prudent to maintain a label throughout the delivery path (perhaps multiple
MLAs), and then translate only once at the final recipient.
Russ
At 06:17 PM 2/19/98 -0500, John Pawling wrote:
Russ,
I agree that the MLA MUST NEVER change the original signer's securityLabel
authenticated attribute contained in the innermost signedData. Because
CMS/ESS binds the securityLabel authenticatedAttribute with the signature of
the data, intermediate entities can't change the securityLabel without
breaking the original signer's signature. That is an excellent feature of
CMS/ESS.
However, I respectfully disagree with your proposal that the MLA must be
restricted from defining the securityLabel values in the outermost
signedData envelope that it creates and signs. When an MLA-expanded message
is received by the ultimate recipient, the receiving software will process
the securityLabel defined by the MLA when it validates the MLA-generated
outermost signedData layer and will separately process the securityLabel
defined by the original signer when it validates the innermost signedData
layer. IMHO, the policy defining how an MLA derives the values for the
securityLabel included in the outermost signedData that it signs should be a
matter of local customer policy, not mandated by the ESS spec. Your
proposal would unnecessarily (IMHO) limit the flexibility of the CMS/ESS
spec, so I oppose it.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
===============================
At 03:44 PM 2/19/98 -0500, Russ Housley wrote:
John:
I disagree with your handling of security label. MLAs should not modify an
existing security label attribute. This action would encourage label
translation.
I suggest that we permit the addition of a security label if it is absent,
but otherwise the MLA should preserve the outter security label.
Russ