Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

[Alessandro Vesely <[e-mail]>]

On Mon 25/Jan/2021 22:22:25 +0100 John Levine wrote:
> In article <[e-mail]> 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
--