Dear piler-users,
I'd like to introduce a fresh feature: rfc3161 timestamping. In certain
environments to you need some extra to verify the authenticity of the
messages: timestamps from a trusted external 3rd party.
To enable the feature you need the latest master branch from bitbucket
(https://bitbucket.org/jsuto/piler/get/master.tar.gz). Be sure to review
and apply the database schema changes (see
util/db-upgrade-1.1.0-vs-1.2.0.sql)
Then edit config-site.php, and add the following new variables:
$config['TSA_PUBLIC_KEY_FILE'] = '/path/to/tsa.public.key';
$config['TSA_START_ID'] = 0;
$config['TSA_STAMP_REQUEST_UNIT_SIZE'] = 10000;
$config['TSA_URL'] = 'http://zeitstempel.dfn.de';
DFN is a test service only, you may use it to build a proof of concept,
but don't rely on it,, and don't use it in production.
You need the public key of the TSA service provider to verify the
timestamps,
TSA_URL parameter is self-explaining. The unit size defines how many
messages
the signing utility will collect, and send for timestamping.
The actual timestamping is done by util/sign.php, put it to piler's
crontab,
eg.
1 * * * * /usr/bin/php /usr/local/libexec/piler/sign.php --webui
/var/www/piler --mode unit
The signing utility has two modes: time and unit (default). If you
specify 'unit' as mode
then sign tries to collect TSA_STAMP_REQUEST_UNIT_SIZE messages. In case
of 'time' mode
it collects new messages (archived since the last stamping), and if
there's at least 1
message, it will be stamped. Since each timestamp costs money, pick a
strategy.
When the timestamp is returned from TSA provider, it stores the response
in timestamp
sql table.
The verification works as follows. Decide which timestamp refers to the
actual message,
then compute the aggregated sha1 hash for the related messages, compare
it to the stored
value, and finally verifying it using the public key of the TSA.
There's an unpolished aspect of the feature: if you apply the feature to
an existing archive,
you'll get a verification error for messages before the introduction of
the feature.
The TSA_START_ID tells sign.php to sign messages after this serial id
(=metadata.id). The
previous issue could be mitigated by considering this value, and
skipping the tsa verification.
However I'm not sure if it's the proper way to handle it.
Anyway please test the feature (I suggest to set TSA_START_ID to current
id value in the metadata
table), and comment it. You may use the DFN service (for testing).
Janos
