[xmlsec] Signing over multiple files

[Mike Peat]

Thanks for that Aleksey

Initially I thought I had found a work-around, but I am now back looking 
at the problem from square one again.  Let me explain...

Another customer of the organisation I am communicating with was using 
xmlsec at the command-line to do this, which is what led me down this 
route initially.

It turns out that if the document (file) referred to in the <Reference> 
URI attribute is in the _same directory_ as the SOAP document being 
signed, xmlsec actually picks it up OK and includes its hash-value in 
the <Reference> -> <DigestValue> element... problem solved! 
(Apparently...) However, life is not so simple.

They are working on a Linux system, while I am cursed with being in 
Windows.  :-(

They are thus able to have files named "cid:/xxxxxxx/", while I am not 
(no colons allowed in file-names in Windows!).  So I changed the URI 
attribute in my Reference element to just contain a file-name with no 
"cid:" prefix, and that got things working as far as digitally signing 
the whole thing with xmlsec was concerned.  However now I am getting 
messages through to the other party's back-end system, which are being 
rejected because now _it_ can't identify the referred to document: it 
seems that it insists on using that "cid:" scheme.

So...

I need to persuade xmlsec to recognise that "cid:" prefix and, in 
effect, ignore it (if the referred-to file-name starts with "cid:", 
replace that with nothing prior to trying to open the file).

I have got the xmlsec source, but up until now have just been using Igor 
Zlatkovic's Windows binaries.

I need to (a) get xmlsec to compile in a Win32 environment and (b) know 
where to make the changes in xmlsec (or perhaps one of its libraries) in 
order to create a version which will do what I need.

I am not really a C/C++ programmer, but I can usually get by in pretty 
much anything (I have been programming since about 1972 - Oh Lord! 
That's 40 years! I'm getting too old for this!).

What compiler will I need and where do I find the code I will need to 
change?  And what build process do I need to go through?  Is there a 
make file or something similar?

Alternatively... what would it take to get somebody who actually knows 
what (s)he is doing to do this for us? We don't have much in the way of 
budget, but this is stopping a project that has months of work in it 
dead in its tracks right now, so...

TIA

Mike Peat

On 14/09/2012 16:57, Aleksey Sanin wrote:
> Mike,
>
> You will probably need to write code to support "cid" URL scheme
> and resolve references correctly to the MIME attachments:
>
> http://www.aleksey.com/xmlsec/api/xmlsec-io.html
>
> Aleksey
>
> On 9/14/12 7:50 AM, Mike Peat wrote:
>> Hi
>>
>> I am using xmlsec at the command line in an ebXML application.  As you
>> probably know, ebXML uses SOAP-with-attachments (over HTTP) to send its
>> messages.  The message thus consists of multipart-MIME content in the
>> HTTP body: the first part being a SOAP document containing (among other
>> things) the Signature stuff and the second being an XML document which
>> is the business payload.
>>
>> The Signature->SignedInfo in the SOAP document needs to contain two
>> <Reference> elements: one for the SOAP document itself (URI="") and one
>> for the payload XML (URI="cid:xxxxxxxx", where "xxxxxxxx" is the content
>> ID of the second MIME part).
>>
>> I am managing to successfully sign simple SOAP messages with no payload
>> (and hence no second <Reference> element), but I just can't work out how
>> to get xmlsec to sign both documents together.  I have tried many
>> different ways, but to no avail.  I am sure I am missing something
>> simple, but...  :-(
>>
>> Any help would be very much appreciated - I've been banging my head off
>> this brick wall for a week... and it is starting to really hurt!  :-(
>> (That takes a while, because my brain is so dense, but even it starts
>> gets sore eventually!)
>>
>> TIA
>>
>> Mike Peat _______________________________________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec
> .
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20120920/1a1d9bca/attachment.html>