[xmlsec] Another go on xmlsec perl bindings

[Erich Strelow]

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aleksey.com/pipermail/xmlsec/attachments/20200302/e53de6f3/attachment-0001.htm>