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
( 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'] = '';

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,

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 ( 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).


Reply via email to