AW: AW: STR-Transform question

Pete,

see some comment inline.

Regards,
Werner

> -----Ursprüngliche Nachricht-----
> Von: Pete Hendry 
> [mailto:peter.hendry-aXhhQsCQISd54TAoqtyWWQ@xxxxxxxxxxxxxxxx] 
> Gesendet: Donnerstag, 22. September 2005 09:27
> An: dims-1oDqGaOF3Lkdnm+yROfE0A@xxxxxxxxxxxxxxxx
> Cc: Dittmann, Werner; wss4j-dev-28n8OjmUYWfNLxjTenLetw@xxxxxxxxxxxxxxxx
> Betreff: Re: AW: STR-Transform question
> 
> 
> I now have all 7 scenarios working between our client and 
> Axis 1.2.1 and 
> WSS4J.
> 
> Some comments and problems:
> 
> 1) The WSS4J server configuration (deploy.wsdd) has the order 
> of steps 
> wrong for
>    scenarios 4, 5, 6 and 7. The Timestamp should be the first 
> step (in 
> the interop docuemnt
>    it appears last in the security header which means it 
> happens first). 
> In the configuration
>    the Timestamp is last and so the tests fail if the 
> Timestamp is added 
> first as per the
>    interop documents.

Werner: True, the interop defines a specific order. However, the
order of actions was not relevant during the interop tests. Also
the WSS spec does not mandate any order, the only thing that should
be (and WSS4J mandates this) that elements that shall be signed
or encrypted must be available before you sign/encrypt them. In other
words if you like to sign (and/or encrypt) a Timestamp then you
must add the Timestamp (using the Timestamp action) before the
Signature/Encrypt actions.

> 
> 2) The WSS4J STRTransform ignores InclusiveNamespaces (it 
> doesn't check 
> for them).
>    This was where my problem lay - I was including them - as 
> they affect 
> what is produced
>    by canonicalization. I removed them from my request and it 
> worked Ok. 
> The fact
>    that WSS4J C14Ns both the input and output has no effect on the 
> output (the input
>    C14N can be removed I believe without affecting the outcome).
> 
> 3) I suspect (but have not tested) that inclusive C14N will not work 
> with the WSS4J
>    STRTransform except for a reference to a 
> BinarySecurityToken and the 
> same for
>    InclusiveNamespaces.
> 
>     I will try to explain... The WSS4J STRTransform class 
> relies on the
>    XMLUtils.circumventBug2650() method having been called before the
>    transform is called. This is necessary so that all the namespace 
> declarations
>    in the context of the STR are copied to it and also to the BST (if 
> there is one).
>    When STR has a refernece to a BST all is well because the 
> BST has all the
>    namespace definitions on it (curtesy of the 
> circumventBug2650 method).
> 
>    This is an important point because when the STRTransform class does
>    C14N of the output it does not do it for the whole 
> document but instead
>    creates a new Element to parent the BST which was copied 
> or created.
>    This new Element is not in the context of the original STR 
> (i.e. it 
> does not
>    share the same ancestor hierarchy) but is instead the root 
> node. This 
> means
>    all the namespace context from the STR would be lost if it had not 
> luckily
>    been copied by circumventBug2650.
> 
>    For the case of the STR being a reference to a BST all is 
> well, even if
>    InclusiveNamespaces were defined I believe this would 
> work. However,
>    if the STR is a KeyIdentifier or IssuerSerial then the BST is 
> created. In
>    this case it does not have all the namespace definitions 
> of the parents
>    of the STR in its context so when inclusive C14N is performed (or
>    exclusive C14N with InclusiveNamespaces defined) the context
>    namespaces are not available to include on the BST node.
> 
> I hope that all makes sense to someone! Inclusive C14N may not be so 
> important (especially since WS-I mandates exclusive only) but 
> InclusiveNamespaces may be more so (since WS-I also mandates them).
> 

Werner: AFAI understand the WSS spec:
- if it is a direct BST - just copy it, but as a "node set of its own",
  that is without the sorrunding original document

- if it is a indirect reference to a token - get the token's raw
  bytes, create a new BST, using the "same namespace prefix" as
  the original STR (I interpret this as using the original STR's 
  element prefix to identify the WSS namespace.) Nothing is said
  about to use additional or other namespaces for this new BST.
  
The only namespace relevant topic I see here is the requirement
to have the empty namespace defined if it was not defined in the
element.

At the last step c14n the resulting BST, then transform into a 
byte stream.  This byte stream is then signed.

I'm not sure if the WS-I InclusiveNamespace stuff also is required
for this Transform algorithm. We did some WS-I InclusiveNamespace 
stuff for other elements (Signature and Encryption) but we hit
sever interop problem. Thus we made this configurable but it
is switched off by default.

> The problem can only really be reliably fixed by inserting 
> the BST into 
> the copy of the document (which has already been made) in 
> place of the 
> STR and then C14Ning the BST in this context.
> 
> The algorithm I have written does not C14N the input (as per 
> the errata) 
> and it still works against WSS4J so that could probably be 
> removed from 
> the WSS4J transform code.
> 
> I hope this is useful (and understandable).
> 
> Pete
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> wss4j-dev-unsubscribe-28n8OjmUYWfNLxjTenLetw@xxxxxxxxxxxxxxxx
> For additional commands, e-mail: 
> wss4j-dev-help-28n8OjmUYWfNLxjTenLetw@xxxxxxxxxxxxxxxx
> 
>