On Wed, Aug 15, 2018 at 6:33 AM, Dave Crocker <dcroc...@gmail.com> wrote: > > This doesn't sound like compelling benefit, which is why I suggest > removing it. Absent compelling benefit, simpler specifications is to be > preferred, IMO.
Absolutely agreed on simplifying the spec, but the above conversation misses the points in the email I sent an hour or two earlier. In particular, there was a design decision made at the genesis of ARC to store excess trace information that receivers could use to further analyze the Chains on the receipt. This is well documented in 11.3.3, as part of the experiment is looking into what trace information is actually valuable. As I've mentioned previously several times in this thread, without the Seal that affixes cv=fail to the message including all the ARC header fields in its scope, this trace information is no longer authenticatable and therefore cannot be trusted. This is a violation of the explicit design decision this protocol was built up from. But to also reiterate: what is Sealed when cv=fail is attested to (itself, the entire chain, or nothing at all) DOES NOT AFFECT INTEROPERABILITY. What it does effect are preserving trace information and preventing forged data from being reportable. This seems deeply valuable to me.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
