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>