|
|
|
|
|
by LeonM
997 days ago
|
|
There lies the problem IMO. The publication date of the DKIM record will be _after_ the email has been sent. Obviously there is no real way to 'prove' the publication date of a DNS record, other than asking the DNS service provider for the logs maybe. So IANAL, but I'd say the lack of provability of the publication date of the key makes it unsuitable for deniability. Just because the DKIM public key is currently public, does not prove in any way that it was already public when the email was sent. |
|
So to check if the property holds, the question is not: can you prove the key was public when the email was sent, it is a) can the adversary prove when the email was sent, and b) can the adversary prove that the key was not public at that timestamp?
On a), the adversary cannot just rely on Date: headers if those headers are signed by a public key, and the private key is now public - someone faking an email could just back-date the Date header to a date when the private key was not available, and hence an argument by the adversary that 'the Date header says it was sent at timestamp TS1, and at TS1, the key wasn't public, so therefore the email can't be repudiated' is not sound.
If the recipient of the email cooperates (or anyone who gets access to the email before the private key is published), they could, for example, hash all their emails, and then hash the list of hashes on a regular basis, and put that hash in a busy public blockchain. That would provide an upper bound on the email send timestamp, and, combined with a well-defined private key publication timeframe, provide non-repudiation.