Thanks to everyone who responded to me, either directly or through the list,
on this.
I concur with the general consensus that ESS wrapping provides the
facilities that I require. I have a mild concern with respect to the
performance of such an approach, but that's an operational, rather than a
protocol, issue.
Thanks again,
Piers
Piers Chivers
Product Architect
Protek Network Security
+44 (0)1270 507800
www.protek.com <http://www.protek.com>
-----Original Message-----
From: Pawling, John [mailto:John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com]
Sent: 21 March 2002 18:01
To: jimsch(_at_)exmsft(_dot_)com; Piers Chivers
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: Labeling and SMIME
All,
I believe that RFC 2630 CMS and RFC 2634 ESS allow sufficient flexibility
regarding the binding of security labels with data. For example, the
original signer of the signedData signerInfo can apply a security label that
is bound with the original encapsulated content. Another entity can
encapsulate the original signedData in an outer signedData in which the
entity can apply a security label that is bound with the outer signedData's
encapsulated content (i.e. the inner signedData). An application can
unambiguously process the nested signedData layers to identify each signer
that created each security label.
I agree with all of Sean Turner's statements.
In summary, I believe that nested signedData layers can be used to meet
Piers' requirements. I do not believe that CMS and ESS should be changed
regarding the creation and use of security labels.
===========================================
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================
-----Original Message-----
From: Jim Schaad [mailto:jimsch(_at_)nwlink(_dot_)com]
Sent: Thursday, March 21, 2002 11:14 AM
To: 'Piers Chivers'
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: Labeling and SMIME
Piers,
There is another way that this can be handled depending on the order of
evalution of security labels by your software. It would be possible to add
a new security label in a wrapping layer which both 1) gave the new label to
be used and 2) overrode the inner label.
This method does have a number of possible pitfalls to be considered, 1) the
label evaluation needs to ensure that the new label applier has the right to
apply the label and 2) the change in label corresponds to some type of
policy. This does mean that a single engine with the ability to save state
needs to be used to evaluate the labels. This is not going to be supported
by some software, and is done purely in the label engine there needs to be a
way of making sure that all of the labels apply to a single message
(inclusion of a message id as a label parameter would be one method).
This allows for the concept of both lowering and upping the security level
needed to view a document.
jim
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]
On Behalf Of Piers Chivers
Sent: Thursday, March 21, 2002 9:11 AM
To: 'Sean P. Turner'
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: Labeling and SMIME
Sean,
Thanks for the response. Whether or not a label is part of a document and
hence changing the label changes the document is a philosophical debate.
Nevertheless, it is an important one. I think that in a business world the
person who signs the content of a document could be different from the
person who labels a document. Business policy should dictate who is allowed
to sign documents. Similarly, policy should dictate who is allowed to set
or change a label. The CMS spec doesn't allow for this.
Further to my earlier suggestion, I would suggest that this should be
addressed at the CMS level. One possibility is a signedMetaAttributes field
in the SignerInfo with a metaSignature field that is a signature of the
signedMetaAttributes. signedMetaAttributes should always contain the
message digest attribute similar to signedAttrs. This way the document and
the label attribute are cryptographically bound.
Piers
Piers Chivers
Product Architect
Protek Network Security
+44 (0)1270 507800
www.protek.com <http://www.protek.com>
-----Original Message-----
From: Sean P. Turner [mailto:turners(_at_)ieca(_dot_)com]
Sent: 20 March 2002 21:22
To: Piers Chivers
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: Labeling and SMIME
Piers,
One way to allow a message to change label values over time would be to have
the message (say it's marked A, where A is higher than B) include not only
the marking A in the security label but also include an indication of when
it should be considered to be marked B. You could do this with a security
category.
To me you always want to link the message/document, label, and signature in
the same blob. Firstly, if you have a document I hope you've got the
marking in the document's contents. Then, if you have to change the
classification you'd also have to change the marking in the document;
thereby, changing the document's contents and the original signature
wouldn't be valid anymore anyway. To me when you change the label's values
you're essentially changing the message/document and hence it ought to be
treated as a new message/document.
spt
Piers Chivers wrote:
Hi,
I think that the current SMIME implementation for labeling is too
inflexible.This is probably because it is modeled on a military world where
a Top Secret message stays Top Secret for ever.However, in the commercial
world a "Commercially Sensitive" document may become "Public" overtime or
because of a change of circumstances (details released to Stock Markets,
document signed off by marketing etc.).
Since, in SMIME, the label of a message is signed with the content of the
document it is impossible for the label to be changed without re-computing a
signature on the content of the document.This is erroneous since the person
changing the label may not be the original creator of the document
contents.Hence the proof-of-origin of the document will be lost.
Have I missed a way to do this in the current CMS/SMIME model? If not, I
would propose a scheme as follows:
a new MIME entity application/pkcs7-labeled that has 2 parts:
application/pkcs7-document that contains the document part of a
multipart/signed entity and
application/pkcs7-label - a MIME entity that contains a signed CMS object
containing the label and the original document's detached signature.The
latter signature is provided by the person who creates the message.The outer
signed CMS object is signed by the labeler of the document.Typically, the
signatories will be the same person.
This approach allows labeled documents to be re-classified over time but
keeps the original document signature.
Any thoughts?
Thanks,
Piers
Piers Chivers
Product Architect
Protek Network Security
+44 (0)1270 507800
www.protek.com <http://www.protek.com>
--------------------------------------------------------------------------------
This message is for the named person's use only. It may contain confidential,
proprietary or legally privileged information. No confidentiality or privilege
is waived or lost by any mistransmission. If you receive this message in
error, please immediately delete it and all copies of it from your system,
destroy any hard copies of it and notify the sender. You must not, directly or
indirectly, use, disclose, distribute, print, or copy any part of this message
if you are not the intended recipient. PROTEK Network Management Group and
each of its subsidiaries reserve the right to monitor all email communications
through its network. Any views expressed in this message are those of the
individual sender, except where the message states otherwise and the sender is
authorised to state them to be the views of any such entity.