RE: [wss] SwA profile

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

Frederic


Before producing a revised draft of the SwA profile, I would appreciate
insight on the following two issues from those concerned with SwA
security support. 

A. Attachment-Complete transform.
We can simplify the profile by removing this. The threat of attachment
modification or deletion can be addressed by referencing each attachment
in a single <ds:Signature> if desired. 

Dale>ok.

The only reason to keep this is to make explicit a processing rule that
all attachments are covered by the signature, addressing attachment
insertion threat. 

DaleMoberg> One governing central principle of XMLDsig is that you trust
only what is signed. If stuff is inserted in such a way as to not
invalidate the signature, it is still not signed, and the XMLDsig user
should be aware that it is not trustworthy. 
In other words, I am not certain that XMLDsig really provides an
approach to signature that is intended to catch insertion 
"in between" ds:Reference'd stuff. I think Rich Salz has mentioned on
this list (or somewhere) that a signed manifest
might be a good way to handle those with security concerns about
detecting reordering or unwanted insertions. I agree with his suggestion
if you decide to support this functionality (that is, add a manifest of
attachments where order is described, and add order check as an added
semantic). 

But, in a way, XMLDsig takes a "don't care" view toward insertions in
"gaps"; a lower layer signature might be a much better way to go for
this functionality IMO.



I believe such an explicit statement is appropriate, so propose keeping
this transform, but maybe there is a better approach.



B. Support for Content-Location
The current draft only supports URL CID-scheme references to attachments
containing Content-Id headers. It is also possible to support
Content-Location references that require a URL resolution mechanism to
relate a URL to a Content-Location header in an attachment.

I think that only CID need be supported since any sender can add a
Content-Id header to attachments as needed. This can make the spec
simpler, and receiver processing simpler, eliminating the URL resolution
requirement. Is there an argument to support Content-Location? 

DaleMoberg> MIME Encapsulation of Aggregate Documents, such as HTML
(MHTML) says

   This standard specifies that body parts to be referenced can be
   identified either by a Content-ID (containing a Message-ID value) or
   by a Content-Location (containing an arbitrary URL). The reason why
   this standard does not only recommend the use of Content-ID-s is that
   it should be possible to forward existing web pages via e-mail
   without having to rewrite the source text of the web pages. Such
   rewriting has several disadvantages, one of them that security
   checksums will probably be invalidated.

That is about the only reason I recall mentioned for content-location
for bodyparts sent in email messages.
(This was in ebXML Messaging at one point.) 

I don't see that this is too relevant for sWa uses myself. It is not
much
of a burden to do both: (googled quote from
http://segate.sunet.se/cgi-bin/wa?A2=ind0203&L=mhtml&F=&S=&P=157)

"They are two ways of doing similar things, but are not
identical. Content-Location matches any URL which can
occur in the web page, while Content-ID only matches
"cid:"-type URLs. One could say that Content-ID is
superflous, since
   "Content-Location: cid:abc@foo.net";
is identical to
   "Content-ID: abc@foo.net"





Note that the attachment decrypt transform material is to be removed
(see previous email).

If there is material missing to address your specific SOAP message level
SwA security requirements, please indicate so.

Thank you

regards, Frederick

Frederick Hirsch
Nokia


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup
.php.