SwA public review issues [Long]

[<Frederick.Hirsch@nokia.com>]

Here is a draft summary of the public review issues raised in [1] and
[2] by Brian LaMacchia, to be used to update the WSS issue list. Please
send any corrections or additions to the WSS mailing list. These are not
in any particular order. (Quotes are from Brian):
 
Issue 1 - Clarify Goals and non-goals
 
Document needs clarification of goals and non-goals
 
Issue 2 - Add additional clarification of relationship to other work,
particularly MTOM and S/MIME
 
Possibly give guidance on when to use, versus MTOM, maybe citing
relationship of technologies to SOAP 1.1/1.2. Clarify relationship in
introductory sections.
 
Issue 3 - Layering Issue - MIME and SOAP processing are intermixed
 
Consequence of signing/encrypting MIME headers in Attachment-Complete.
Re-word section 2 to clarify that layering is not absolute, but that 
 
"wss-swa-profile defines a merged SOAP-MIME processing layer that allows
some MIME-only tweaking (e.g. transfer encoding format changes) at
intermediate MIME hops"
 
Issue 4 - Clarify that Attachment-Content-Only/Attachment-Complete
Signature Transform inputs are octet-streams
 
Issue 5 - Allow ds:Reference transform chain (section 4.4.4)  to allow
additional transforms including base64, while clarifying typically not
needed.
 
(I think this means re-phrasing the last sentence in item #4 to say that
a base64 transform isn't usually necessary as a signature transform for
MIME transfer encoding due to the layering model).
 
Issue 6 - Can XML attachments be XML canonicalized and used in
conjunction with SwA profile?
 
Proposal: Require canonicalization of XML type attachments to be XML
canonicalization rather than text canonicalization.  Retain value of XML
processing (e.g. intermediaries), can  outweigh efficiency. XML can be
passed in other format if not to be processed (e.g. zip, text)
 
"I think there's a bit of a larger issue here regarding treating
text/xml attachments as binary blobs instead of XML.  The way the spec
is today I can never create an intermediate node that shreds &
re-processes an XML attachment unless I keep the original binary stream
around that I parsed to get the XML.  Compare this to the intermediate
MIME processing nodes which can, for example, change the transfer
encoding on an attachment whenever they way.  Given the way you've
constructed this profile MIME transfer encoding changes are transparent
to the digital signatures because the signature is always over the
underlying binary representation.  In normal XMLDSIG usage the signature
is over the canonicalized form of the signed XML, which means the XML
can change in semantically-neutral ways while traveling from source to
destination and the signature will still hold.  I don't understand the
why you'd choose in this spec to do a bunch of work to enable MIME
transfer-encoding rewriting while, at the same time, removing the
ability that exists in the underlying XMLDSIG to perform
semantically-neutral XML-rewriting."
 
Issue 7 - Clarify relationship to S/MIME, including how S/MIME
attachments are handled and of possible interactions in signature
processing.
 
Issue 8 - Review MIME headers that are included in signature, make
extensible (future-proof)
 
"Since the set of meaningful headers that may appear in a MIME
part is not fixed it's possible that in the future a header will be
defined that should be secured at the wss-swa-profile level but will
have been precluded from being so.  Wouldn't it be safer and more robust
to either (a) make Attachment-Complete protect *all* the Content-*
headers, or (b) make Attachment-Complete specifically *not* protect a
fixed set of headers that you know don't need to be protected?"

(Did not want to include Content-Transfer-Encoding, but maybe Content-*
is ok. What do people think?)
 
Issue 9 - Can SwA signatures be persisted?
 
Issue 10 - Signatures over portions of attachments precluded
 
Is this an issue or should this be viewed as an application signature
out of SwA profile scope. If not supported (the current case) clarify in
section 1.
 
Issue 11 - Clarify which MIME headers are encrypted with "content and
headers" encryption
 
" Regarding encryption of attachments, the spec is not clear as to
which headers are encrypted when "content and headers" encryption is
specified for an attachment.  Assume that I've specified a Type
attribute of Attachment-Complete (lined 475-476) for an encrypted
attachment.  Line 469 says I should have encrypted "the attachment
including content and *selected* MIME headers" (emphasis added), but
there's no way to select which headers are to be encrypted. Similarly,
when decrypting lines 514-515 state that if the Type attribute indicates
that selected MIME headers were encrypted then the decrypted selected
headers must replace the post-encryption headers.  Is the intent that
there be a mechanism for selecting which headers are going to be
protected by the encryption?  Or was it expected that only the headers
identified in lines 224-228 would be encrypted (the same set that is
deemed worthy of protection when signing)? The spec needs to provide
more clarity on exactly which headers are supposed to be encrypted"
 
The intent was that it would be the same headers identified in 224-228 -
need to add clarification.
 
" It would be better to choose either to encrypt all headers,
or all minus some set that you explicitly want to allow to change
(Content-Transfer-Encoding, perhaps)."
 
Open issue beyond clarification.
 
Issue 12: Add processing rules/guidance for SOAP and MIME intermediaries
 
How should various sorts of intermediaries behave (SOAP, MIME) with
regards to SwA profile.
 
" My concern is primarily with what intermediate MIME processing nodes
are
allowed to do in the S/MIME space.  Clearly you want to allow some
intermediate MIME processing (e.g. transfer encoding format
transcoding), so what's OK for an intermediate node to do?  Can an
intermediate node add an S/MIME signature to a MIME message post
wss-swa-profile processing?  Does that signature have to be removed by a
receiving node before wss-swa-profile processing?  What about
intermediate S/MIME encryption?  That obviously has to be removed before
wss-swa-profile processing, but I haven't had a chance to think through
whether any irreversible header munging could occur in that scenario, or
if there's some other way that an S/MIME operation could interfere with
a wss-swa-profile operation."
 
-----

regards, Frederick

Frederick Hirsch
Nokia 

[1]
http://lists.oasis-open.org/archives/wss-comment/200502/msg00004.html
 
[2]
http://lists.oasis-open.org/archives/wss-comment/200502/msg00006.html