Re: Explanation of section 4.5 of transform note

Pratik

Thanks for this write up. I think it is helpful and should be added to  
the document.

Regarding the SOAP with Attachments, I would suggest that the  
Attachment Complete Transform could almost be viewed as a binary  
transform of a special type for a mime part. Note that not all mime  
headers are included etc. The complexity is due to mime part  
considerations...

In general if you have a structured (but not only XML) content type it  
might not neatly fit into a single selection + canonicalization model?  
Perhaps there are other cases like this (a file directory + files etc)?

regards, Frederick

Frederick Hirsch
Nokia



On Mar 19, 2009, at 1:56 PM, ext Pratik Datta wrote:

> Trying to clarify section 4.5 of the transform note
> http://www.w3.org/2008/xmlsec/Drafts/transform-note/Overview.html#extensibility
>
>
> We are proposing a new transform model, which is a radical departure  
> from the current model, and it doesn't have the current concept of a  
> "transform".  (With the exception of XSLT and decrypt transform,  
> that we reluctantly added back).  Instead it has separate   
> <Selection> and <Canonicalization> elements which achieve the same  
> thing as transforms but in a more restricted and declarative way.
>
> With the current transform model, people are free to define new  
> transforms, and they have. In this section I have taken two such  
> transforms from WS-Security spec and attempted to map them to the  
> new transform model.  This is just an exercise to validate the new  
> model; the WS-* specs are frozen and not expected to change.
>
> "STR-Transform"
> See http://www.oasis-open.org/committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf 
>    Section 8.3
> This transform is way to sign tokens that are not part of the  
> message. Suppose a signature is signed with a X509 cert , and the  
> KeyInfo contains only the IssuerSerial of the certificate. Now if  
> you include a Reference to the KeyInfo in your signature, you are  
> only signing the IssueSerial of the cert, not the actual cert. This  
> is where an STR-Transform comes in - it is a transform that  
> "resolves" token references and replaces them with actual tokens,  
> i.e. it will replace the IssuserSerial with the actual cert; so now  
> your signature is signing the actual cert even though you don't have  
> the actual cert in the message.
>
> In my mind an STR-Transform is like combo transform - a) it replaces  
> references by actual tokens  b) it canonicalizes
>
> To map the STR-Transform to the new model, we need to split it up -  
> part of it will go into the <Selection> element, and part into the  
> <Canonicalization> element. The Selection part can be represented by  
> a new attribute (assuming we go with attribute extensibility)  
> replaceSTwithSTR="true/false". The canonicalization part is standard.
>
> This splitting up the STR-Transform gives a big benefit. One of the  
> goals of the new transform model is to accurately determine what is  
> signed, and the current STR-Transform does not let you do that  
> easily because it combines and replacement and canonicalization into  
> one step, so it is very hard for an application to stop the STR- 
> Transform in the middle and get the value of the replaced tokens.  
> But with the new model, an application can just execute the  
> <Selection> step and get the value of the replaced tokens, and check  
> the policy to determine if the tokens that were supposed to be  
> signed, and really signed.
>
>
> "Attachment-Content transform"  and "Attachment complete transform"
> See http://www.oasis-open.org/committees/download.php/16672/wss-v1.1-spec-os-SwAProfile.pdf 
>   Section 5.3.1 and 5.3.2
> The Attachment complete transform is used when signing SOAP  
> attachments.
> Normally the input to a transform is an "octet stream" or a  
> "nodeset".  But a SOAP attachment doesn't fit into these two  
> categories because  it has a two parts - mime headers and body.  The  
> "Attachment content" transform is simpler because it ignores the  
> mime headers, and only signs the body which is just an octet stream.  
> but the "Attachment Complete transform" signs both the parts.  To do  
> this is canonicalizes the Mime headers and canonicalizes the body  
> and then combines them into one octet stream. Body canonicalization  
> depends on the the content-type of the attachment - xml attachments  
> use exclusive canonicalization, text attachments use a special line  
> ending normalization, other attachments are not canonicalized. Mime  
> Headers are canonicalized in a complex way - see the 19 step process  
> in the Section 5.4.1 of that spec.
>
> This is again a very complex transform to map to the new transform  
> model.  First lets try to map the "Attachment Content transform"  
> which only does the body. We can use the type/subtype attributes to  
> indicate whether it is a xml, binary or text data.  Then we can use  
> the regular <Canonicalization> section to canonicalize xml data. We  
> also need to define a variant of <Canonicalization> for  
> canonicalizing text data.
>
> I can't think of an easy way to map the Attachment Complete  
> transform. This is really signing two separate pieces of data - so  
> maybe it should be represented as two separate references - the  
> first reference will select the mime headers, and the second  
> reference will select the body. And we would also need to define a  
> <Canonicalization> variant for signing mime headers.
>
> ----------------------
>
> If this explanation makes is clearer, I can update the note with  
> this content.
>
> Pratik
>
>
>
>
>
>
>
>
>
>

Received on Friday, 20 March 2009 13:46:01 UTC