Your arguments only serve to further convince me that the ESS
eSSSecurityLabel processing requirements must not be changed. Your
statement that an intermediate entity can "veto" the originator's label
confirms my fear that intermediate entities may be allowed (if given the
chance) to invalidate the original signer's eSSSecurityLabel. If that
happens, then the original signer is not receiving the security security
services that she requested when she originally signed the content.
Your requirements can be met by nesting signedData layers. The original
signer can include her eSSSecurityLabel in the original, inner signedData
layer. The intermediate entity can include its eSSSecurityLabel in an outer
signedData layer that encapsulates the original, inner signedData layer.
This is the optimal strategy because the recipient MUST make a separate
access control decision for each of the signedData layers. The recipient
MUST process the eSSSecurityLabel in each
signedData object that it verifies. Because the recipient will verify both
the outer and inner signedData objects, then it MUST process the
eSSSecurityLabel attribute in each of the signedData objects. Therefore,
both the original signer's and intermediate entity's eSSSecurityLabels are
processed by the recipient.
If your proposal was accepted and multiple eSSSecurityLabels were allowed in
the same signerInfo or same signedData, then there would be mass confusion
and room for contradiction when different labels are processed by the
recipient as part of the same cumulative access control decision applied to
the individual signedData object. I believe that it is impractical to try
to force the S/MIME community into accepting a complicated access control
decision strategy such as would be required to define the rules to process
multiple eSSSecurityLabels included in the same signerInfo or same signedData.
In summary, my opinion is that Dave Kemp's security label example must be
John Pawling, jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
At 11:48 AM 3/23/98 -0000, Tim Dean wrote:
I must respectfully disagree that in all cases, all intermediate entities
must respect the original signer's
wishes regarding the label. In many environments, such as ours, security
authorities have the power of
veto over any label created by an originator. In electronic (S/MIME)
terms, my 'environment' will
probably create the label automatically for me. That 'environment' could
be the current enclave/domain
where I am working, or the machine I am currently logged onto, or even the
client software on the
machine, e.g. on a Compartmented Mode Workstation. In certain cases the
labelling authority will be a
human-being acting as a 'release authority'. This signed label will
probably be checked by the Guard
before onward transmission.
In short, I want to create and sign messages as an originator; some third
party will counter-sign and label
them for me. I am very much hoping that ESS and S/MIME in general will
accommodate this model as
well as other security policies. As a general principle, I believe ESS and
S/MIME should be security-
policy neutral wherever possible. I am very much hoping that with the
addition of sig-purpose attribute
'content Reviewer', my particular policy could be supported. For this
reason, I would very much like all
of Dave Kemp's original examples, including security label, to remain.