[Top] [All Lists]

Re: Signed Label (was RE: 'Signature Purpose' attribute?)

1998-04-27 10:12:22

I disagree with Chris' proposal because there is no reason to include
different semantically-equivalent eSSSecurityLabels in a single signedData
object because the originator and each recipient can locally translate the
"identical" eSSSecurityLabel to a specific security policy, if required.
Furthermore, ESS MUST prohibit semantically different eSSSecurityLabels from
being included in a single signedData because that creates a significant
possiblity that there will be contradictions between the semantically
different labels that would lead to errorneous or inconsistent access
control decisions applied to a content.  

John Pawling, jsp(_at_)jgvandyke(_dot_)com                             
J.G. Van Dyke & Associates, Inc.         

At 10:43 PM 4/25/98 -0400, Bonatti, Chris wrote:
   This seems to have wound down, but not truly concluded.  While I agree
with David that further discussion of the "multiple labels" question seems
fruitless, I raised a slightly different point in my earlier posting which
has gotten lost amongst the many salvos exchanged.

   In one of my earlier postings, I noted the scenario in which the
originator includes 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.  In this case, both labels are provided simultaneously by
the same signer, but convey a deliberately different semantic.

   I would like to come to a conclusion that has ESS describe how to
provide this dual-marking.

   In my mind, it would be unnecessarily inefficient to convey each of
these in a separate signerInfo elements since they are both generated by the
same signer.  However, it would be reasonable to use a different attribute
ID for the information label and simply exempt it from ACDF processing
(which is semantically consistent anyway).  What I proposed in my original
post was somewhat more efficient, but separate attributes would keep us off
any slippery slopes.



|  International Electronic Communication Analysts, Inc.      |
|  Christopher D. Bonatti                 9010 Edgepark Road  |
|  Principal Engineer                 Vienna, Virginia 22182  |
|  bonattic(_at_)ieca(_dot_)com   Tel: 301-212-9428   Fax: 703-506-8377  |