View Issue Details

IDProjectCategoryView StatusLast Update
0006161Talerexchangepublic2020-04-07 06:18
ReporterfefeAssigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status confirmedResolutionopen 
Product Version0.7.0 
Target Version0.9Fixed in Version 
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,
 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?
TagsNo tags attached.

Activities

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

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