View Issue Details

IDProjectCategoryView StatusLast Update
0006161Talerexchangepublic2021-08-24 16:23
Reporterfefe Assigned ToChristian Grothoff  
Status closedResolutionfixed 
Product Version0.7.0 
Target Version0.8Fixed in Version0.8 
Summary0006161: Suggestion: Do some more signature checks
DescriptionThis is for exchange/src/auditor/taler-auditor-httpd_deposit-confirmation.c

 80 now = GNUNET_TIME_absolute_get ();
 81 if ( (es->ep_start.abs_value_us > now.abs_value_us) ||
 82 (es->ep_expire.abs_value_us < now.abs_value_us) )
 83 {
 84 /* Signing key expired */
 85 TALER_LOG_WARNING ("Expired exchange signing key\n");
 86 return TALER_MHD_reply_with_error (connection,
 89 "master_sig (expired)");
 90 }

This looks good and is technically sufficient, but maybe we could add some additional sanity checks?
For example that the signature was not valid for longer than a year?

Maybe add a way to revoke the key?
TagsNo tags attached.


Christian Grothoff

2020-04-06 13:29

manager   ~0015535

Validity lifetime: the specification doesn't set a limit on signing key lifetimes so far, hence the auditor cannot check for one. We can consider to impose an upper bound (1 year seems reasonable), but then this needs to be implemented/enforced also on the exchange side.

Revocation: I agree we probably would want to check for revocations here. That said, I think the entity that should sign off on these revocations actually probably is the auditor, and that is not implemented. Right now, 'revocation' of these keys is basically the exchange stops using them and uses something else -- usually after the auditor in the very code you are reading detected a key compromise. So yeah, I guess we should add a "revoke this key" tool/program to the auditor, and should henceforth ignore further reports involving the now revoked key. We'd also need to expand the exchange's /keys API to return the revocation signatures (possibly multiple per key, as we may have multiple auditors per exchange).

Christian Grothoff

2020-12-26 15:56

manager   ~0017239

I've thought more about the lifetime limit, and I think any such bound is likely to cause more trouble than it is worth: imagine having to debug the case where an exchange operator configured a 2 year lifetime and then this fails at the auditor (possibly much later). What do you do then? The offline signature affirming the 2 year validity was already made. Big trouble. And keeping such constraints (especially across re-implementations) will also just make the specification more complicated. In general, we assume that exchange operators are able to pick sane key lengths and lifetimes everywhere else. Why not so here? The default configuration comes with sane default values already. That should be enough. If an operator truly wants the keys to be for valid longer, what is inherently wrong with that?

Checking for revocation of the online signing key (via the synchronized exchange database) is implemented as per 32da8154..57c90547.

Christian Grothoff

2020-12-26 16:00

manager   ~0017240

d8ad5e0..f1ea2a1 documents the configuration options required to give the taler-auditor-httpd access to the exchange DB (with the revocation data).

Issue History

Date Modified Username Field Change
2020-04-06 13:19 fefe New Issue
2020-04-06 13:19 fefe Status new => assigned
2020-04-06 13:19 fefe Assigned To => Christian Grothoff
2020-04-06 13:29 Christian Grothoff Note Added: 0015535
2020-04-06 13:30 Christian Grothoff Assigned To Christian Grothoff =>
2020-04-06 13:30 Christian Grothoff Status assigned => confirmed
2020-04-06 13:30 Christian Grothoff Target Version => 0.9
2020-07-16 15:18 Christian Grothoff Assigned To => Christian Grothoff
2020-07-16 15:18 Christian Grothoff Status confirmed => assigned
2020-10-11 21:02 Christian Grothoff Target Version 0.9 => 0.9.1
2020-10-11 21:03 Christian Grothoff Assigned To Christian Grothoff =>
2020-10-11 21:03 Christian Grothoff Status assigned => confirmed
2020-10-25 23:18 Christian Grothoff Assigned To => Christian Grothoff
2020-10-25 23:18 Christian Grothoff Status confirmed => assigned
2020-12-26 15:56 Christian Grothoff Note Added: 0017239
2020-12-26 16:00 Christian Grothoff Note Added: 0017240
2020-12-26 16:00 Christian Grothoff Status assigned => resolved
2020-12-26 16:00 Christian Grothoff Resolution open => fixed
2020-12-26 16:00 Christian Grothoff Fixed in Version => 0.9
2020-12-26 16:01 Christian Grothoff Target Version 0.9.1 => 0.9
2021-07-30 13:57 Christian Grothoff Fixed in Version 0.9 => 0.8.1
2021-07-30 13:59 Christian Grothoff Target Version 0.9 => 0.8.1
2021-07-30 14:02 Christian Grothoff Fixed in Version 0.8.1 => 0.8
2021-07-30 14:02 Christian Grothoff Target Version 0.8.1 => 0.8
2021-08-24 16:23 Christian Grothoff Status resolved => closed