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