[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss-comment] Comments on wss-swa-profile-1.0-cd-01
Hi Frederick,
Thank you for your detailed reply. I've responded point-by-point below
using the same numbering scheme (augmented with sub-items) so that we
can more easily track the various issues under discussion and to
facilitate splitting this thread into multiple conversations if
necessary.
(1) You've raised a few points in responding to my overall concern that
this profile violates the fundamental layering architecture proposed in
Section 2 of the draft. I'll address each of these in turn.
(1a) Regarding your first point, I do think this spec needs to at least
give the reader some guidance concerning the relationship between this
proposal and MTOM. Putting my implementer's hat on, when I read a spec
like this I want to understand at least a bit of the motivation behind
it, and why it's necessary to have two specs that appear to do the same
thing in two different ways. Maybe the answer is, "MTOM assumes SOAP
1.2, and this spec only applies to SOAP 1.1. Use this one if you're
running SOAP 1.1 but for SOAP 1.2 and beyond use MTOM." (I don't know
if that's true, but if so it would provide sufficient motivation &
information to an implementer reading this spec.)
The wording in lines 83-87 is really not responsive to the "when should
I use this" question, nor does that paragraph provide any guidance. In
fact, lines 83-87 ducks the question completely. "The existence of this
profile does not preclude using other mechanisms...". Well, OK, so when
should I use this profile, and how should I combine this profile with
the other mechanisms mentioned? Maybe I shouldn't ever use
wss-swa-profile with MTOM, or with XMLDSIG at the app layer, or with
S/MIME. Maybe there's some recommended way I should combine these
technologies if I need a particular set of features not provided
completely by wss-swa-profile. Whatever the answer is, I think you need
to say something more up front in the spec besides the general
disclaimer in 83-87.
(1b) Regarding securing some of the Content-* headers in the MIME parts,
I think you may have a larger problem here than I first thought. I was
initially going to suggest that you flesh out the "common use and risks
associated with inappropriate modification" comment in lines 229-230 and
say specifically why the particular headers you've identified in lines
224-228 need to be secured. However, I'm now really uncomfortable with
this entire approach to securing only a fixed subset of the headers via
wss-swa-profile and punting the rest of the headers to the application
level. 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? With
both (a) & (b) you've future-proofed your own standard against the
introduction of a new meaningful Content-* header. (Of course, you may
end up signing additional headers in the future that aren't meaningful
but at least you'll be erring on the side of caution.) I understand
that you specifically want to allow transfer encodings to change between
intermediate MIME hops, and that's OK since you're signing the
underlying binary data (not the encoded representation), but just
creating exceptions for the types of intermediate transformations you
know are safe seems a better route than trying to specify the headers
which are dangerous to allow to change.
(1c) If proper layering was not an absolute requirement for this spec
then I think you need to reword Section 2 to make that clear. The way
Section 2 reads right now implies that the spec enforces a hard layer
between the SOAP messaging layer and the MIME
serialization/de-serialization layer. Of course that's not what is
actually going on, since what you're really doing is partially creating
the SOAP message, partially forming the MIME multipart out of the SOAP
message and its attachments, creating the XMLDSIG over that partial MIME
serialization, putting the XMLDSIG into the SOAP header (which doesn't
disturb the MIME parts holding the attachments) and then finalizing the
entire MIME message. So I think it would be more appropriate, at a
minimum to say 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.
(1d) I feel compelled to point out that without proper layering it is
unlikely that any of the wss-swa-profile digital signatures can be
persisted over time. That is, once you've validated the signature and
de-MIMEed the SOAP message and attachments you're not going to be able
to re-validate the signature at a later point in time unless you save
the inbound binary MIME stream as well as the SOAP object. One of the
goals of XMLDSIG was to make the signature objects persistable so that a
signature on an XML object could be preserved like a signed receipt for
later auditing and re-verification if necessary. Given the intertwining
of the SOAP and MIME layers in this proposal I don't think that's
possible without saving a copy of the inbound MIME stream and,
essentially, re-processing the entire stream when you want to
re-validate the signature.
(2) We're in agreement on this issue, so no further discussion is
necessary. If you have specific language or editorial edits you'd like
me to look over let me know.
(3) I think we're in agreement on this issue, but just to be clear there
are certainly going to be cases where something like a Base64 transform
is going to show up underneath the transfer-encoding. Now, you've
precluded many of the common cases where I'd need to use an intermediate
transform like a Base64 transform (or an XPath or XSLT transform) by
preventing signatures over portions of attachments (prohibited by lines
169-171 in Section 4), but it's still possible that that one could show
up somewhere.
(3a) Side comment: why did you decide to prohibit signatures over parts
of attachments? That's one of the most useful features of XMLDSIG
(along with detached signatures in general) and I don't see what you
gain by forcing attachment signatures to be all-or-nothing. It doesn't
make your implementation significantly easier since you still have to
support the Reference processing model & Transform chains the way you
have the spec now.
(3b) I missed this the first time through the spec, but the prohibition
against signing parts of attachments in lines 169-171 is a serious one
that needs to be called up front in the spec, ideally in Section 1. (You
could add this to the text I recommended in my (1a) response above.)
This prohibition means, I think, that I can't use this standard in
workflow scenarios that require multiple parallel or cascaded signatures
over parts of attachments. (For example, intermediate SOAP processing
nodes that want to countersign a part of an attachment can't do that --
they must either sign the whole attachment or nothing.) Note: if it was
*not* the intent of the TC to prohibit signatures over parts of
attachments then you need to change lines 169-171.
(4) 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.
(5) OK, so there should be a comment in the spec somewhere that text/xml
is intended to be treated as type text, at least assuming
wss-swa-profile sticks with not requiring true XML canonicalization.
(6) 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.
(6a) Note that if the intent of encrypting "content and headers" was to
encrypt only the five headers specified in lines 224-228 then header
encryption suffers from the same deficiency as header signing that I
discussed in (1b) above. An approach that says that only a fixed set of
headers can be secured using attachment encryption is going to have
problems. 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).
(7) Similar to the point previously discussed in (1a) above, I don't
think this spec can be silent on the interaction with S/MIME issue. 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.
(7a) At a minimum, I think the spec needs to address the interplay
between wss-swa-profile and S/MIME; after all, somewhere you need to say
something about why the standard mechanism for signing & encrypting MIME
messages -- S/MIME -- was insufficient for your scenarios. This
probably becomes part of the introductory material, again similar to my
comments in (1a) above about MTOM.
I hope this helps clarify my earlier comments. Please let me know if
you have any further questions.
--Brian
-----Original Message-----
From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]
Sent: Wednesday, February 16, 2005 1:32 PM
To: Brian LaMacchia; wss-comment@lists.oasis-open.org
Subject: RE: [wss-comment] Comments on wss-swa-profile-1.0-cd-01
Brian
Thank you for reviewing the SwA profile Committee Draft. I'll try to
respond, but there are also others on the list who can add something or
correct me if I've got something wrong.
(1) The primary issue you point out is the layering issue. I think there
are a couple of points to consider here.
First, this profile is intended to address the explicit requirement of
being able to secure attachments when an application deals with
attachments explicitly, using SwA. This does not preclude the use of
MTOM. Which is more elegant or appropriate is out of scope.
Second, it is necessary to secure some MIME headers to secure the
attachment properly. The committee felt that certain MIME headers are
exposed to the application, so may be treated as-if at a different layer
than others which may be changed during message transport at the MIME
layer. Hence the profile attempts to limit which MIME headers may be
secured in an attempt to meet the layering goal. I should point out that
we treated the layering as a "goal" but not an absolute requirement.
Although I sympathize with the layering concern, I think from a
pragmatic view this profile outlines a fairly simple way to secure SwA.
We discussed the possibility of copying headers into the primary soap
envelope (e.g. into a signature object as you suggest) and decided not
to do that. We should list this as an issue from public review and
discuss it.
(2) I believe you are correct, we should state in the profile that the
output of both
Attachment-Content-Only and Attachment-Complete is an octet-stream.
Thanks for pointing this out.
(3) You are entirely correct on transforms, and I think we should change
this. The goal was to clarify the processing and that commonly a base64
transform would not need to be explicitly called out in the transform
chain. Perhaps a non-normative explanation would suffice. Another
potential issue for the TC to discuss.
(4) The goal is to not *require* XML canonicalization of XML attachment
content to enable this SwA profile processing. This does not preclude
attachment XML canonicalization if an application deems it necessary for
processing (e.g. by an intermediary) and this policy is conveyed to the
appropriate parties (as would be necessary in any case). Is this an
issue for a bit of clarifying language that such XML canonicalization
MAY be performed if participants agree, or am I missing a larger issue?
(5) Yes the assumption was that text/xml attachments would be
canonicalized as type text.
(6) Again, the issue of layering for encryption assumed that certain
MIME headers are visible to an application interface so should be
treated as content, while others are not and are not included in the
encryption.
(7) The assumption is that there was no need to discuss interactions
with S/MIME security such secured items can be treated as opaque by this
SOAP Message security - there is no need to go into such attachments to
look at the security mechanisms. The goal here was to use SOAP Message
security with SwA.
Other TC members may have additional comment. Thanks again, you raise
good points.
regards, Frederick
Frederick Hirsch
Nokia
-----Original Message-----
From: ext Brian LaMacchia [mailto:bal@exchange.microsoft.com]
Sent: Friday, February 11, 2005 12:47 PM
To: wss-comment@lists.oasis-open.org
Subject: [wss-comment] Comments on wss-swa-profile-1.0-cd-01
Dear OASIS WSS TC Members,
Here are my comments on wss-swa-profile-1.0-cd-01, the 23 December 2004
Committee Draft 01 version of SOAP Messages with Attachments (SwA)
Profile 1.0. In reading this draft I focused primarily on the
signature-related sections, in particular Section 4.4, and how this
draft uses the W3C XMLDSIG Recommendation (IETF RFC 3275).
1) First, a high-level comment: there's a fundamental conflict in this
spec between the layered processing approach described in Section 2
(MIME Processing) and the detailed signature construction rules in
Section 4.4.4. Section 2 states quite clearly that the goal of this
specification is to define a layering along the lines of:
a) Sender SOAP message signature construction
b) Sender MIME formatting/serialization
c) Message transfer from sender to recipient
d) Recipient MIME de-formatting/de-serialization
e) Recipient SOAP message signature verification
However, the signature construction rules in Section 4.4.4 violate
the ordering of (a) and (b) -- they intermix processing steps from
both the SOAP and MIME worlds. Section 4.4.4 Steps 1 and 2 state
that compliant implementations must first *MIME* canonicalize the
to-be-signed content, then construct the SOAP message, form the SOAP
signature, and then MIME format the message. This violates the basic
layering principle. It would be much better, and in alignment with
the XMLDSIG specification, if instead attachment signatures were
formed as "detached signatures" in accordance with XMLDSIG and then
the detached signature and attachments packages together into a
single MIME multipart package.
[Note: Doing detached signatures & then packaging is completely
straightforward for "Attachment-Content-Only" attachments. For
Attachment-Complete attachments, though, it's not so straightforward
because as defined in the spec signing an Attachment-Complete
attachment explicitly violates the SOAP/MIME layering rules. There
seems to be something deeper going on in Section 4.3.2 because I
don't understand how the MIME headers can have any signficiance if
the layering principle holds true. Either the MIME headers are
strictly a side-effect of the MIME-layer packaging, or they are being
used in this spec to convey important Attachment-related metadata.
If the latter is true, it would be more in line with XMLDSIG to put
this metadata either in the Reference itself or in another XML
structure within Object elements in main the Signature element.]
Section 4.4.5 commits the same layering violation as Section 4.4.4,
but in reverse: after de-MIME'ing the received message the MIME type
information must be maintained so that the received attachments can
be properly MIME-canonicalized before doign XMLDSIG Reference
processing.
In my view, it should be possible to XMLDSIG sign data that will be
transferred in MIME attachments without the XMLDSIG engine needing to
know anything about the MIME transport layer. Similarly, the MIME
transport layer should not need to have any awareness of the SOAP or
XMLDISG-specific nature of the content it (the MIME layer) is
transferring. The only touch points between the two layers need be
the URIs used in References (the cid: URIs).
2) Now for some lower-level comments. SwA defines two new Transforms
for the XMLDSIG Transform processing model (Attachment-Content-Only
and Attachment-Complete). In the XMLDSIG Transform processing model
(see XMlDSIG Section 4.3.2.2), Transforms either accept XML Node-sets
or octet streams; both of these new SwA Transforms appear to be
octet-stream input Transforms (although it's not explicitly stated).
However, the output format of the SwA Tranforms is not defined
because the MIME Content Canonicalization algorithm is not defined
(Section 4.4.2 says it varies by MIME type). Since MIME Header
Canonicalization (Section 4.4.1) outputs a UTF8-formatted octet
stream, I believe the intent is that the output of both
Attachment-Content-Only and Attachment-Complete is an octet-stream.
This needs to be clarified in the specification if it is the intent
of the spec.
3) In Section 4.4.4 (Processing Rules for Attachment Signatures), Step
4, lines 346--348 is confusing. It appears that the intent of this
MUST NOT is to instruct implementers that they should not include any
Transforms in the Transform chain that deal with MIME encodings,
since the MIME encoding/decoding happens at a higher level than the
SOAP processing. That's technically correct, but the current wording
seems to imply that a Base64 Transform could never show up in a
compliant Transform chain, and that's incorrect. After the first
Transform (which has to be one of the two types specified in Section
4.3) any valid Transform could appear in the Transform chain and
process the output of the Attachment-Content-Only or
Attachment-Complete Transform. So, in particular, it's quite
possible that a Base64 Transform could show up somewhere in that
Transform chain.
4) There appears to be a conflict between two parts of Section 3 (XML
Attachments) which is exacerbated by the canonicalization rules (or
lack thereof) for text/xml in Section 4.4.2. Section 3, lines
155--157, state that "Attachments might also be...targeted toward
specific SOAP intermediaries...", which implies that attachments
might have to be processed by intermediaries after the MIME wrapping
is removed. However, the following sentence (lines 158---161) says
that the specification assumes that SOAP attachments need not be
processed as XML, and specifically not XML canonicalized.
Furthermore, in Section 4.4.2 we have explicit statements that XML
attachments do not need to be XML Canonicalized, just "MIME
canonicalized". This restriction means XML attachments must be
treated as binary blobs by intermediaries -- they could not be parsed
and re-assembled because there's no mandatory canonicalization
required for XML content before DigestValue hash generation. (Given
the interpretation in (2) above, a conforming application could
include an explicit C14N Transform in the Transform chain to make up
for this deficiency, but because it's not required for all XML
content no intermediary is going to be able to depend on being able
to parse, process and re-assembly XML attachment content.)
5) As a side note to (4) above, note that RFC 3023, the current RFC
containing the registration for the text/xml MIME type, does not
define a canonical form for text/xml. Presumably, then, the
canonical form for text/xml inherits from the registration for text
as defined in RFC 2046, which only defines canonical CRLF processing
for text types. Given these restrictions, XML attachments by default
must be handled as opaque binary blobs and it'll be impossible for
intermediate nodes to do any processing on them absent specific
indications to the contrary in the Transform chain.
6) I have only read through the XMLENC-related sections briefly, but
they appear to have similar layering problems/violations. In
particular, the fact that MIME headers may be encrypted along with
MIME content for a particular Attachment means the layering principle
is explicitly violated for encryption. (See, e.g., lines 468--469 in
Section 4.5.2.) According to Section 4.5.2, a conforming
implementation would need to SOAP-format (but not encrypt) the
to-be-sent message, then MIME-format the message, then XMLENC-encrypt
soem MIME attachments, then re-format the (now-encrypted) MIME
attachments, then re-format the SOAP message. Again, I would ask why
MIME is bring treated as anything more than a packaging mechanism for
a collection of XML objects that internally have signature &
encryption relationships.
7) There is no discussion in this spec about the relationship between
SwA signatures & encryption and S/MIME signatures & encryption. What
are the processing rules for combining SwA & S/MIME signatures (since
a signed SwA message might be re-signed at the MIME level by a MIME
intermediary)?
In summary, I'd strongly recommend that the WSS TC re-consider the
mixed-mode, cross-layering approach they've used for signature
generation and instead consider a cleaner architecture that performs
SOAP, XMLDSIG & XMLENC processing first, without any reference to the
MIME layer, and then uses the MIME layer strictly for transport.
I'd be happy to answer any further questions the TC has about these
specific comments or the XMLDSIG Recommendation in general.
--Brian LaMacchia
Co-author, XMLDSIG
bal@microsoft.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]