RE: Are XML Attachments Opaque or Not?

["Blake Dournaee" <blake@sarvega.com>]

Frederick -

I am thinking of it from an implementation and use-case point of view. I
believe there is significant value in the ability to sign or encrypt a
subdocument of a SOAP attachment where the attachment is XML. The case I am
thinking of is where the attachment is a long piece of XML with only some
private portions.

That being said, if we are not addressing (providing) a way to perform this
type of action explicitly in the profile at this time, we should make a
stand in the profile and say that we are not defining this mechanism. Like
you said, you may be able to do it, but it may not be interoperable. A
future version of the SwA profile may address this.

All I want is some clarity, and this means a sentence like the following:

"This profile does not consider further XML Security mechanisms within an
XML attachment, such as encryption, signing, or other operations like
Canonical XML. This profile considers all attachments as opaque whether they
are XML or some other content type. It is the sole responsibility of the
application to perform further interpretation of attachments that happen to
be XML."

Right now it feels like we're leaving an option here that may be bad for
interoperability unless we define exactly how such a mechanism would work.

Blake Dournaee
Senior Security Architect
Sarvega, Inc.





-----Original Message-----
From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com] 
Sent: Wednesday, September 01, 2004 12:01 PM
To: blake@sarvega.com; wss@lists.oasis-open.org
Subject: RE: Are XML Attachments Opaque or Not?

Blake

Version 8 of the SwA profile refers to canonical xml differently than
before. Now it says you MAY include those transforms in a ds:Reference
if you want, but it is not required. It allows users to add additional
transforms as they see appropriate.

Thus attachments are treated as opaque, but hey, if you have a use case
where you want to canonicalize them as XML, then you can do it.

There has been no official decision to reverse the previous discussion.
Thus if you strongly believe we should disallow additional reference
transforms and disallow references into attachments, I have no
objections.

What do others think?

Regards, Frederick 

Frederick Hirsch
Nokia

-----Original Message-----
From: ext Blake Dournaee [mailto:blake@sarvega.com] 
Sent: Monday, August 30, 2004 6:41 PM
To: Hirsch Frederick (Nokia-TP/Boston); wss@lists.oasis-open.org
Subject: Are XML Attachments Opaque or Not?

Frederick, All -

It looks like this latest revision (8) of the WSS SwA profile is still
making references to Canonical XML as applied to XML attachments (Lines
284, Lines 254-257, 159-160).

What this is telling me is that the SwA profile isn't considering XML
documents that happen to be attachments as opaque, but allowing further
"reach" of this profile into these node sets. At least we're not being
clear about where the profile stops.

Please correct me if I am wrong, but I had thought we agreed that the
profile *would* indeed consider XML that happens to be an attachment as
opaque and not allow further reach into these XML documents.

My real question here is regarding those implementations and use cases
that which to sign a *subdocument* of an attachment that happens to be
XML. We should either disallow this or allow it and profile it.

Below is the trail that I started a month or so ago on this issue.

Please let me know what everything thinks, perhaps the decision was
reversed and I missed it.

Blake Dournaee
Sarvega, Inc.

-----Original Message-----
From: Blake Dournaee [mailto:blake@sarvega.com]
Sent: Tuesday, July 13, 2004 9:06 AM
To: 'Jerry Schwarz'; wss@lists.oasis-open.org
Subject: RE: [wss] More SwA Comments

Jerry,

I agree with you on the attachment being opaque, this makes things much
simpler.

I do have a further question about SOAP versioning. The SwA document is
quite dated (2000), and it sounds like MTOM has superseded the SOAP
Attachment Feature (although this is not explicit in the MTOM
specification).

Supporting the SwA W3C Note is simple, but what changes have to be made
to support SOAP v1.2? Do any changes need to be made to our SwA profile?

I am concerned that the SwA profile that we (read: Frederick!) are
writing is only going to be seen as narrowly applicable due to its
emphasis on SwA and not the Attachment Feature or MTOM.

Thanks,

Blake Dournaee
Senior Security Architect
Sarvega, Inc.



-----Original Message-----
From: Jerry Schwarz [mailto:jerry.schwarz@oracle.com]
Sent: Tuesday, July 13, 2004 8:18 AM
To: Blake Dournaee; wss@lists.oasis-open.org
Subject: Re: [wss] More SwA Comments

At 01:04 PM 7/12/2004, Blake Dournaee wrote:
....

>2. While we mostly think of attachments as opaque binary blobs, I have 
>seen several cases where the attachments are XML. Should we make the 
>statement that this SwA profile views any XML attachments as opaque? 
>This would limit the applicability of the profile in cases where we are

>targeting an XML sub-document within an attachment. That is, signing 
>some child element buried in some XML that happens to be an attachment.

I think we should continue to consider the attachment as opaque. If the
application wanted to treat the attachment as part of the body they
could have.  I worry that if we start creating mechanisms to look into
the XML in an attachment we'll be inventing mechanisms for treating the
attachment as a part of the SOAP Envelope which is beyond what we should
be doing.


>I believe that for the sake of clarity we should make statement about 
>this use-case. If we want to allow visibility into XML documents that 
>happen to be attachments (by visibility, I mean signing), we should add

>a clarifying remark about how to go about this somewhere around line 
>203. E.G. Use XML Signature transforms/filters to select the element(s)
to sign.
>
>3. Line 108, we should define MTOM.
>
>4. Line 133 still refers to Content-Location
>
>5. Line 160 we should make a clarification regarding "canonicalization"

>so readers don't' confuse this with Canonical XML. We should make a 
>statement about how an attachment is to be canonicalized when it is XML

>(if it is opaque, we don't want implementers running it through C14N
mistakenly).
>
>Regards,
>
>Blake Dournaee
>Senior Security Architect
>Sarvega, Inc.
>
>
>
>
>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_workgrou
>p.ph
p.