[Top] [All Lists]

RE: Labeling and SMIME

2002-03-21 11:01:09
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
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

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.
-----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 
Sent: Thursday, March 21, 2002 9:11 AM
To: 'Sean P. Turner'
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: Labeling and SMIME

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 Chivers
Product Architect
Protek Network Security
+44 (0)1270 507800
-----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
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. 
Piers Chivers wrote: 
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? 
Piers Chivers 
Product Architect 
Protek Network Security 
+44 (0)1270 507800 
<Prev in Thread] Current Thread [Next in Thread>