On 10 Jul 2020, at 16:54, Matt Corallo via mailop wrote:
Replies inline.
On 7/10/20 7:50 PM, Brian Toresdahl wrote:
Your approach and goals don't seem to make sense to me.
TL;DR: The customer is always right, and the customer sees DKIM being
used regularly to authenticate leaked emails - if
old not-in-use keys are public, anyone can sign anything they want,
and suddenly you can't authenticate mail with them,
at least after-delivery, that is.
Not sure I understand your customer's use case completely, but DKIM is
meant to verify the signature upon delivery. You can certainly try and
verify again at a later time.
You do not need to have a _small_ number of public keys published. You
can have a very large pool of them, and theoretically use them to sign a
single message when sending. A while after delivering the message, you
can remove and destroy the key material – DNS public key and private
key – to prevent its reuse.
This could be an interesting project – which would be stretching the
intended use case for DKIM IMO :-)
DKIM works (I'm summarizing a lot) by signing mail, and the
public key to check that signature is placed in a "selector"
record in DNS (selector1._domainkeys.example.com
<http://domainkeys.example.com>). If you want to rotate DKIM keys,
you
can immediately start signing new mail with with another selector
(selector2._...), keeping the selector1 around long
enough for the old mail to be delivered and checked. Are you asking
how long selector1 needs to stay around? For some
sort of 95th percentile, probably less that an hour.
Yes, that was my question, thanks :). Sadly, I don't think and hour
would work - plenty of time to timestamp the emails
in question and suddenly the email is non-reputably signed again. Back
to the drawing board, I suppose.
I was lost by the end of this paragraph.
The goal is to actually publish the private key, no need to wait for
someone to brute-force it :)
Are you sure you're not better using S/MIME or GPG to produce _signed_
email payloads?
-lem
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
