On Mon 25/Jan/2021 22:22:25 +0100 John Levine wrote:
In article <[email protected]> you write:
On Mon 25/Jan/2021 21:07:01 +0100 Michael Thomas wrote:
On 1/25/21 11:53 AM, Alessandro Vesely wrote:
On Sun 24/Jan/2021 19:49:34 +0100 Michael Thomas wrote:
issue #99 needs to be addressed.
Won't we put a DKIM-Signature: in the http: header?
I don't know. That would need to be specified. To me it sounds like a good
reason to not try to specify http especially if there doesn't seem to be any
clear desire for it.
Yes, it needs a spec. It doesn't seem to be overly difficult.
Sheesh. That isn't mission creep, it's mission gallop.
The spec can be commissioned to a narrowly focused WG (like dcrup).
MIME provides for a binary Content-Transfer-Encoding, albeit unused. To sign a
message thus (un)encoded, it is unreal to try and apply a line-oriented
canonicalization. The new spec should just introduce a "binary"
canonicalization, which can only be used for the body. From a software POV, it
is a trivial update, as it's enough to hash the data as-is.
With that addition, DKIM can be used with HTTP transport, which is an
interesting point per se. Meanwhile we can specify that https: SHOULD be DKIM
signed.
If you want a domain identity (even though in this case it provides
nothing useful), what's wrong with a client cert? They exist, they
work, they have software support everywhere.
Even if you can deduce a From: email address after the Subject Alt Name, you
cannot reliably associate it to an organizational domain.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
