On Fri, Jul 27, 2018 at 10:54 AM, Seth Blank <s...@sethblank.com> wrote:
> On Fri, Jul 27, 2018 at 10:39 AM, Murray S. Kucherawy <superu...@gmail.com > > wrote: >> >> But (and I think this proves my point) I don't know if "cv=fail" refers >> to an invalid chain or a failed chain. I have to run the verification to >> figure that out. But you're saying you just stop when you see "cv=fail". >> >> I remain confused.. >> > > I don't understand what you're exploring. The algorithm in > https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-5.2 > is clear and the separate paths you're describing don't factor it. > > On validation, you grab the highest instanced ARC set (step 1), and then > start a process to set the chain validation status of the inbound ARC Chain. > > If the highest instanced ARC Set has cv=fail in it, you're done (step 2). > No cryptographic checks have even been performed at this point, because in > either scenario the chain is dead. If the AS validates and you have > cv=fail, then the chain state is fail. If the AS does not validate, then > the chain state is fail. > > Crypto isn't checked until step 3, and we never get there. If you're doing > analysis and want to understand what caused the chain to fail, you're now > outside of validation and outside of matters that affect interoperability. > And therefore, if I'm a sealer and I've decided I'm going to mark the chain failed, why wouldn't I just do "cv=fail" with a bogus or empty signature? The verifier isn't going to use whatever signature I've put there anyway; as you point out, the verifier sees "cv=fail" and stops. And if that's all correct, then I don't understand why we're talking about what exactly you seal if you're the one attaching "cv=fail", because it's moot. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
