[xmlsec] Another go on xmlsec perl bindings

[Aleksey Sanin]

Thank you! I will add a pointer to it to the xmlsec website.

Aleksey

On 3/1/20 6:18 PM, Erich Strelow wrote:
> A couple of weeks ago I revisited xmlsec somehow by chance.
> 
> One of our vendors was sending invoices with a faulty xmldsig signature. 
> I used the xmlsec1 command line tool to verify some signatures. As it 
> turned out, the vendor had managed to sign an ISO-8859-1 encoded xml, 
> and then e-mail it using us-ascii 7bit.
> 
> Anyway, I noticed that after 12 years there's still no perl module for 
> xmlsec. I decided to have a go on this. The repository is available at 
> https://github.com/estrelow/Perl-LibXML-Sec.
> 
> This is still a work in progress. So far I've been able to sign a "Hello 
> world" xml document. The module is still useless beyond that.
> 
> Others have tried and failed. I might as well fail.
> 
> use XML::LibXML::xmlsec;
> 
> my $signer=XML::LibXML::xmlsec->new();
> 
> $signer->set_pkey(PEM => 'key.pem', secret => 'the watcher and the tower');
> 
> my $doc=XML::LibXML->load_xml(location => 'hello-ready.xml', 
> load_ext_dtd =>1, complete_attributes=>1,no_network=>1);
> 
> $signer->signdoc($doc, id => "hello", 'id-node' => 'Data', 'id-attr' => 
> 'id');
> 
> Some ideas:
> 
> 1. Design principles.
> 
>     -The module should interact with XML::LibXML, the main libxml2 port 
> under perl. Therefore the targeted module name as XML::LibXML::xmlsec.
> 
>        -This means a XML::LibXML Document handle might be passed to 
> xmlsec and work out.
> 
>        -If the LibXML Document was ill parsed or is ill formed, xmlsec 
> should complain and fail.
> 
>        -This also means a product of xmlsec signing/encryption should be 
> usable by XML::LibXML.
> 
>     -Instead of a full perl binding of xmlsec, the goal is to produce a 
> xmldsig signing/encryption perl toolkit using xmlsec.
> 
>     -The module should have simple verbs, like sign(), verify(), encrypt().
> 
>     -The arguments should be passed using perl name-value pairs to allow 
> different formats and options. i.e., the above code should have been 
> set_pkey(DER => 'key.der').
> 
>     -The module must have a performance at least as good as calling 
> xmlsec command from perl.
> 
> 2. Motivation.
> 
>     -For many years, libxml has been my xml library of choice under perl.
> 
>     -The Chilean tax authority has adopted xmldsig for 20 years now. 
> This means invoices can be exchanged using xmldsig, and even accounting 
> ledgers are to be archived using xmldsig.
> 
>     -I hate calling xmlsec1 from perl. I always feel I'm double parsing 
> everything.
> 
> 3. Simplifications.
> 
>     - So far I'm using XMLSEC_NO_CRYPTO_DYNAMIC_LOADING to reach a 
> workable toolkit.
> 
>     - Still, since allowing different crypto engines is a xmlsec 
> feature, and there might be compliance issues here, at some point I have 
> to let it go.
> 
>     - I'm favoring the "app" versions of xmlsec functions.
> 
> 4. Use case.
> 
>     The sign/encrypt perl script use case should be as follows:
> 
>           +
> 
>           |
> 
>           |
> 
>           v
> 
> +--------+---------+
> 
> |                  |
> 
> |   App layer      |
> 
> |                  |
> 
> +--------+---------+
> 
>           |
> 
>           v
> 
> +--------+---------+
> 
> |                  |
> 
> |    xmlsec        |
> 
> |                  |
> 
> +--------+---------+
> 
>           |
> 
>           v
> 
> +--------+---------+
> 
> |                  |
> 
> |  store or send   |
> 
> |                  |
> 
> +------------------+
> 
> The app layer should build the XML document using perl LibXML, or DBI, 
> or some module to fetch data from a legacy system. Whatever.
> 
> In my case, I connect to SQL server.
> 
> The xmlsec layer will sign and/or encrypt the document. The appropriate 
> key should be selected by any combination of source, target, contents.
> 
> The store/send layer will save the resulting document in some storage, 
> or send it to a receiving party, like a customer, vendor, compliance 
> authority.
> 
> The decrypt/verify perl script would be the opposite:
> 
>            +
> 
>            |
> 
>            v
> 
> +---------+---------------+
> 
> |                         |
> 
> |  receive or retrieve    |
> 
> |                         |
> 
> +---------+---------------+
> 
>            |
> 
>            |
> 
>            v
> 
> +---------+---------------+
> 
> |                         |
> 
> |    xmlsec layer         |
> 
> |                         |
> 
> +---------+---------------+
> 
>            |
> 
>            v
> 
> +---------+---------------+
> 
> |                         |
> 
> |     App layer           |
> 
> |                         |
> 
> +-------------------------+
> 
> A receive/retrieve should fetch a xml document from storage, or maybe be 
> the receiving end in a https POST channel.
> 
> The xmlsec should verify the signature.
> 
> The app layer then can consume the xml data using LibXML.
> 
> Regards.
> 
> Erich.
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
>