The way I see it.
There is a requirement to allow for third party signatures to be attached
to a SMIME message. An example of a third party would be a mail guard
stamping its own signature onto the SMIME as it leaves the originators
domain. Please note that during the lifetime of the message more than one
third party may add its signature.
There have been two possible solutions discussed on this list.
1) Nesting: encapsulating the CMS object in an outer signedData object in
which the third party can include its eSSSecuritylabel.
2) No Nesting: Signature is added alongside other signatures. (Daves
Pros and cons:
1) Nothing needs to change.
1) Not sure about this, I'm on shakey ground. Is there a problem if the
message is not processed by any guards before arriving at the recipient?
This would be the case where the recipients security policy is "I don't
care". He would have to work his way down through the nesting until he got
to the level which contained the initial originators message. Would the
recipient actually do this? or would he expect the initial originators
message to be at the top level?
1) Everything is at the top level (easily accessable).
1) Don't know which signature to use. This is why the Signature Purpose
attribute was proposed. With the signatures tied into a purpose it can be
left up to site policy. (Dangerous words I think :-) ).
2) Not compatible with previous drafts.
Additional Pros/Cons welcome.
When I hear nesting I start thinking lots of overhead. All that infomation
just to encapsulate a chunk of data. Whereas "sliding" another signature in
seems a lot neater, though I am curious as to how easy it would be to do this.
Therefore, I'm interested in which option would require least processing
both at the adding the third party signature and at the recipient ends
(assuming third party sigs. have not been stripped off before reaching the
William Ottaway, Tel: +44 (0)1684 894079
DERA Malvern, Fax: +44 (0)1684 896113
St. Andrews Road, email:
Worcs, WR14 3PS