John,
Your requirements can be met be including the various differing
eSSecurityLabels in nested signedData objects. The original signer could
include her eSSSecurityLabel in the original, inner signedData layer. The
international/boundary gateway could include its eSSSecuritylabel in an
outer signedData layer that encapsulates the original, inner signedData
layer. This preserves the originator's signature and eSSSecurityLabel
end-to-end. Furthermore, this stratgey allows the gateway to include its
mapped eSSSecurityLabel in the outer signedData layer without corrupting the
original signer's eSSecurityLabel in the inner signedData layer. It is
imperative that the original signer's eSSSecurityLabel must not be
corrupted. If that is allowed to happen, then the original signer is not
being provided with the security services that she requested.
I respectfully disagree with your statement that "there is a problem with
the outer-signature (double wrapping) proposal and the current S/MIME access
control rules." ESS does not dictate how access control is to be performed.
ESS does not dictate the application's actions if the access control fails.
ESS makes statements like "the application SHOULD..." and "the receiving
agent MUST warn the user of this condition". ESS does NOT state "The
application MUST reject the message if access control fails." This is a
matter of local policy.
All that I am trying to state in my series of rebuttals is that we should
simplify the access control decision process by requiring all
eSSSecurityLabels included in a single signedData object to be identical.
If differing eSSSecurityLabels are allowed in the same signerInfo or same
signedData, then there will be room for confusion and 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 differing
eSSSecurityLabels included in the same signerInfo or same signedData.
In summary, I believe that the ESSSecurityLabel strategy should remain as is.
================================
John Pawling, jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
www.jgvandyke.com
================================
At 11:13 AM 3/25/98 -0800, John Ross wrote:
Russ,
The problem with your proposal of removing the originator signature an
replace it with a new signature, is that many international/boundary
gateways may want to perform label mapping and still require the originators
signatures to go end to end (i.e pass through gateways unaltered).
I also I think there is a problem with the outer-signature (double
wrapping) proposal and the current S/MIME access control rules. Under the
double wrapping proposals, an international/boundary gateway will need to
generate an outer-signature which would includes the national/domain
specific eSSSecuritylabel, this may be in addition to (and different from)
the eSSSecuritylabel in the originators signature. However, if I understand
the current access control rules of s/mime correctly, it is mandatory that
both the originators eSSSecuritylabel, and the outer wrapped gateway
eSSSecuritylabel shall be processed by the recipient. (i.e. local recipient
access control must be based on all labels). The problem is that, the inner
eSSSecuritylabel may have no semantics in the recipients environment. So
the access control decision can only be based on the outer eSSSecuritylabel
which as generated by the gateway.
Thus I think, the access control rules in s/mime need to be made dependant
on the security policy identifier (which is part of the eSSSecuritylabel).
This would allow the access control decision to be made based on all
eSSSecuritylabel were the policy identifier is understood and supported by
the recipient. Any eSSSecuritylabel present at any level (originators,
wrapped or triple wrapped) may be ignore (as to the enforcement of access
control rules) if the policy identifier is not understood or supported
I think the above rule, must still be subject to the criticality rules. The
implementation implications of both rules would be to enforce correctly
process the policy identifier and hence determine if the eSSSecuritylabel
was applicable or not for local access control processing.
John Ross
-----Original Message-----
From: Russ Housley [SMTP:housley(_at_)spyrus(_dot_)com]
Sent: Tuesday, March 24, 1998 11:21 AM
To: Tim Dean
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: 'Signature Purpose' attribute?
Tim:
If a security authority wants to change the label, then it must remove the
originator signature an replace it with a new signature.
User agent processing will become overly complex if we allow there to be
multiple labels on a content.
Russ
At 11:48 AM 3/23/98 +0000, Tim Dean wrote:
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