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 [email protected] http://www.aleksey.com/mailman/listinfo/xmlsec
