Explanation of section 4.5 of transform note

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  
<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