John Pawling wrote:
...........an important point to note is that the recipient software makes
a separate access control decision for each signedData object..........
Question:
In your view, does this mean that if the recipinet does not understand the
policy id in the eSSSecuriltylabel that he may ignore the label in the
access control decision, even though he has verified the signature of the
signedData object to which it relateds?
-----Original Message-----
From: John Pawling <jsp(_at_)jgvandyke(_dot_)com>
To: Bonatti, Chris <bonattic(_at_)ieca(_dot_)com>; ietf-smime(_at_)imc(_dot_)org
<ietf-smime(_at_)imc(_dot_)org>
Date: Thursday, March 26, 1998 6:34 PM
Subject: Re: Signed Label (was RE: 'Signature Purpose' attribute?)
Chris,
I respectfully disagree with your proposal. The two different labels that
you require can be implemented by including each label in a separate
signedData layer of the message. The original signer could include the
"information label" in the original, inner signedData layer. The "system
label" could be included 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 "system" and "information" 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. If
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.
IMHO, the cost in efficiency of requiring nested signedData objects to
convey multiple, different eSSSecurityLabels is well worth the clarity
gained.
In summary, I believe that the ESSSecurityLabel should remain as is.
================================
John Pawling, jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
www.jgvandyke.com
================================
At 11:08 AM 3/26/98 -0500, Bonatti, Chris wrote:
I have some other concerns with the current restrictions on ESS
security label. As long as each instance of the label in the signedData
element must contain the same value, I think there are very important
scenarios that cannot be serviced.
It may be necessary to for the signer to include multiple instances of
the security label using different policy IDs and/or security category
structures for the purpose of satisfying the requirements of multiple
policy
domains. This would require a change to the wording of ESS clause 3.1.1.
For simplistic labeling, this is probably not a concern. However, we don't
have (nor are we likely to soon have) a standard for representing
categories/compartments in varying security domains. As long as this is
the
case, we are going to have variations in the labeling requirements on a
per-policy basis. This will essentially require label conversion (as John
Ross suggests) or multiple signed labels with different values.
There is another circumstance in which it may be necessary to include
either or both of an "information" or "system" security label. If both
labels are present, the information label will convey the "true" label of
the content from the originator to the recipient. The system label will
convey the label of the content to be used for access control purposes.
This split label may, among other things, be used to convey the actual
content classification when used in a system-high environment. Whether
either or both of these labels is present is a function of security policy.
The security policy ID may, in fact, be used to discriminate between these
two. This scenario likewise requires a change to ESS clause 3.1.1.
It should also noted that in cases where multiple labels are provided
by the same signer, it would be VERY inefficient to convey each of these in
a separate signerInfo elements because of the overhead of multiple
signature
operations. Therefore, the implied restriction in 3.1.1 on multiple
instances of the label attribute might not make sense.
I would suggest that a better way to handle this would be to make the
ESS security label attribute internally multivalued and include a mechanism
for identifying the purpose of each instance of the label. For example,
the
ESS label attribute could be changed to the following:
ESSSecurityLabel ::= SEQUENCE OF LabelItem
LabelItem ::= SEQUENCE {
security-label SecurityLabel,
label-purpose LabelPurpose }
LabelPurpose ::= ENUMERATED {
system-label (0),
information-label (1), ... }
SecurityLabel ::= SET {
security-policy-identifier SecurityPolicyIdentifier
OPTIONAL,
security-classification SecurityClassification
OPTIONAL,
privacy-mark ESSPrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL }
This plus some better wording in secution 3 of ESS could open S/MIME up to
support a more complex labeling environment.
Thoughts?
Chris
---------------------------------------------------------------
| International Electronic Communication Analysts, Inc. |
| Christopher D. Bonatti 9010 Edgepark Road |
| Vice-president Vienna, Virginia 22182 |
| bonattic(_at_)ieca(_dot_)com Tel: 301-212-9428 Fax: 703-506-8377 |
---------------------------------------------------------------