On Wed, May 31, 2017 at 6:40 PM, Kurt Andersen (b) <[email protected]> wrote:
> If a verifier decides an ARC is invalid, it's supposed to set >> "cv=invalid", when generating its own ARC-Seal. This seems odd; we're >> cryptographically signing a chain that is known to be broken, meaning the >> next handler might not even be able to get as far as consuming the "cv=" >> value we're putting there because the chain can't be validated in the first >> place. >> > > Since looking at the ARC-Seal is the very first step in evaluating the > chain, I'm not sure why a handler would have a problem unless the ARC-Seal > is subsequently mangled beyond recognition (a situation which is covered > elsewhere). Signing the chain documents its state at the time of processing > and the AAR that is covered by the AS tells the next recipient where that > broken chain came from. > So if on doing that very first step and evaluating the chain, I determine that it's mangled and unparseable, I'm now supposed to add my own seal including "cv=invalid" and somehow canonicalize the mangled thing that's there already. I don't think I understand how that's possible; the canonicalized form that is hashed and encrypted to become the AS signature has to include something deterministic. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
