[dmarc-ietf] Clarifying question: AAR coverage by AMS

[Seth Blank <[e-mail]>]

This might be a non-issue, but we're asking this question specifically
because we've run into an implementation issue within openarc that feels
weird and seems like a matter the WG may want to weigh in on.

Our expectation is that, for any given ARC Set n, AMS[n] would cover AAR[n].

Currently in openarc, AMS[n] covers all previous AAR[1..n-1] but *not*
AAR[n] because AAR[n] isn't created until substantially later in the flow.

Technically, this behavior is within spec as defined in
https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-03#section-5.1.2.1.1
:

   Participants may include any other header fields within the scope of
   the ARC-Message-Signature signature except that they MUST NOT include
   ARC-Seal headers fields.  In particular, including all DKIM-Signature
   header fields and all ARC-Authentication-Results header fields is
   RECOMMENDED.

Is it worth guaranteeing that, if signing AARs, AMS[n] must cover AAR[n]?

Or is this irrelevant because AS[n] is required to cover AMS[n] and AAR[n]?
But if so, why recommend the AAR be covered by the AMS at all in the first
place?

While the differences between these two assertions appear to be benign
(AAR[n] is always signed by AS[n], so whether or not it is in AMS[n]
shouldn't matter), the spec leaves room for confusion about the right thing
to do.

What was the original intention here and does this need clarification?

-- 

[image: logo for sig file.png]

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols
[e-mail]
[phone] <415-894-2724>