John,
3) I like the text in ESS as it stands now, but there may be suggestions
to modify the syntax and operation of eSSSecurityLabel to accommodate other
requirements. If ESS were changed, the example might apply.
[JSP: IMHO, the ESS text must stand. Your example is a good reason why it
must stand. If the original signer included an eSSSecurityLabel in the
original signedData object then additional signer's of that original
signedData object MUST not be allowed to include different security labels
in signerInfos within the same signedData object. If that were to be
allowed, 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. Furthermore, if the original signer did not include an
eSSSecurityLabel in the original signedData object, then the original signer
made the decision that the content did not need to be labeled and that
access control is not required to access the content. In all cases, all
intermediate entities MUST respect the original signer's wishes regarding
the eSSSecurityLabel that she included in the signedData that she created or
else she is not receiving the security services that she requested when she
originally signed the content.]
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.
Tim
----------
From: John Pawling [SMTP:jsp(_at_)jgvandyke(_dot_)com]
Sent: Thursday, March 19, 1998 10:34 PM
To: David P. Kemp; ietf-smime(_at_)imc(_dot_)org
Subject: Re: 'Signature Purpose' attribute?
Dave,
Please see my responses in-line:
At 04:30 PM 3/19/98 -0500, David P. Kemp wrote:
From: jsp(_at_)jgvandyke(_dot_)com (John Pawling)
The contentReviewer is only allowed to
include an eSSSecurityLabel authenticated attribute in the signerInfo that
she signs if there was already an eSSSecurityLabel attribute present in the
signerInfo(s) already included in the original signedData object.
John,
It was just an example, but thanks for pointing out the restrictions on
eSSSecurityLabel. I can think of three rebuttals:
1) the above quoted sentence isn't necessarily true in all cases, because
a security gateway could take a message (either signed or plain old email)
and wrap it in a new signedData.
[JSP: I agree that an intermediate entity can encapsulate the original
signedData object within a new outer signedData object. The intermediate
entity can then include the appropriate eSSSecurityLabel attribute, if
required, in the signerInfo within the new outer signedData object. The
intermediate entity's eSSSecurityLabel attribute may be different than that
included in the inner signedData object. IMHO, that is acceptable 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. An important point to note is that the
recipient software makes a separate access control decision for each
signedData object. IMHO, that is the primary difference between processing
eSSSecurityLabels included in layered signedData objects versus those
included in multiple signerInfos included in the same signedData object. In
the latter case, all eSSSecurityLabels included in the various signerInfos
(that are verified) are checked as part of the same cumulative access
control decision process applied to the individual signedData object.
To get back to your original rebuttal, if the intermediate entity adds the
outer signedData, then IMHO it is not a contentReviewer, it is a
contentOriginator because it is creating a new signedData object.
Therefore, I believe that my comment still stands.]
2) eSSSecurityLabel is defined in the ESS document, whereas signaturePurpose
has been proposed for inclusion in CMS. CMS may be used in non-S/MIME
applications which have different compliance requirements than S/MIME and
which do not refer to ESS at all.
[JSP: One of the major goals of ESS is to define standard attributes for use
with CMS. The CMS spec MUST NOT make statements (such as your example IMHO)
that are contradictory to the principles of ESS (which CMS currently does
not). The best strategy would be for CMS not to mention security labels at
all (which it currently does not). Therefore, I recommend that you should
either remove the security label example or move the signaturePurpose
attribute to ESS and discuss eSSSecurityLabels. Furthermore, applications
that use eSSSecurityLabels attributes MUST set the attributes to be critical
so if an application needs to use security labels it would be best if it
were to implement eSSSecurityLabels to avoid interoperability problems with
those applications that are implementing the standard eSSSecurityLabels.]
3) I like the text in ESS as it stands now, but there may be suggestions
to modify the syntax and operation of eSSSecurityLabel to accommodate other
requirements. If ESS were changed, the example might apply.
[JSP: IMHO, the ESS text must stand. Your example is a good reason why it
must stand. If the original signer included an eSSSecurityLabel in the
original signedData object then additional signer's of that original
signedData object MUST not be allowed to include different security labels
in signerInfos within the same signedData object. If that were to be
allowed, 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. Furthermore, if the original signer did not include an
eSSSecurityLabel in the original signedData object, then the original signer
made the decision that the content did not need to be labeled and that
access control is not required to access the content. In all cases, all
intermediate entities MUST respect the original signer's wishes regarding
the eSSSecurityLabel that she included in the signedData that she created or
else she is not receiving the security services that she requested when she
originally signed the content.]
dpk