[xmlsec] Another go on xmlsec perl bindings
Erich Strelow
esf at moller.cl
Fri Mar 6 09:01:51 PST 2020
I'm keeping up with the perl project.
I started linking with a private xmlsec version 1.2.29. Then I switched to whatever xmlsec-devel package was available in my linux distro. It's 1.2.20. The perl glue worked well either way.
I added a XmlSecVersion perl method that points to the XMLSEC_VERSION macro.
I almost gave up on the KeyManager. An initial idea of setting up a KeyManager helper object at perl level was discarded. And for some time I thought of narrowing keys to a one-shot only mention on some function arguments. Finally, the main xmlsec perl object is indeed the basic KeyManager itself and I included a KeysStoreSave method that maps to xmlSecCryptoAppDefaultKeysMngrSave.
Regards.
Erich.
-----Mensaje original-----
De: xmlsec <xmlsec-bounces at aleksey.com> En nombre de Aleksey Sanin
Enviado el: lunes, 2 de marzo de 2020 14:38
Para: xmlsec at aleksey.com
Asunto: Re: [xmlsec] Another go on xmlsec perl bindings
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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Festrelow%2FPerl-LibXML-Sec&data=02%7C01%7Cesf%40moller.cl%7C82c50fe4a19c445f141d08d7bed09a33%7Ca68cc54667a34b1387f4414e9e0b94ef%7C1%7C1%7C637187675470190957&sdata=%2BDqnLW9ZDbgvHP6PNENUCsiFfvRWZCUlvo5MYdPusFk%3D&reserved=0.
>
> 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
> https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.a
> leksey.com%2Fmailman%2Flistinfo%2Fxmlsec&data=02%7C01%7Cesf%40moll
> er.cl%7C82c50fe4a19c445f141d08d7bed09a33%7Ca68cc54667a34b1387f4414e9e0
> b94ef%7C1%7C1%7C637187675470190957&sdata=8cBLwH41cIPwnzDiLHYFwUuI2
> JeaStTBAF7MxdPFpyw%3D&reserved=0
>
_______________________________________________
xmlsec mailing list
xmlsec at aleksey.com
https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.aleksey.com%2Fmailman%2Flistinfo%2Fxmlsec&data=02%7C01%7Cesf%40moller.cl%7C82c50fe4a19c445f141d08d7bed09a33%7Ca68cc54667a34b1387f4414e9e0b94ef%7C1%7C1%7C637187675470190957&sdata=8cBLwH41cIPwnzDiLHYFwUuI2JeaStTBAF7MxdPFpyw%3D&reserved=0
More information about the xmlsec
mailing list