View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006161 | Taler | exchange | public | 2020-04-06 13:19 | 2021-08-24 16:23 |
| Reporter | fefe | Assigned To | Christian Grothoff | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.7.0 | ||||
| Target Version | 0.8 | Fixed in Version | 0.8 | ||
| Summary | 0006161: Suggestion: Do some more signature checks | ||||
| Description | This 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, 87 MHD_HTTP_FORBIDDEN, 88 TALER_EC_DEPOSIT_CONFIRMATION_SIGNATURE_INVALID, 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? | ||||
| Tags | No tags attached. | ||||
|
|
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). |
|
|
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. |
|
|
d8ad5e0..f1ea2a1 documents the configuration options required to give the taler-auditor-httpd access to the exchange DB (with the revocation data). |
| 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 |
