The working group considered cv=invalid last year, but there was strong consensus was against it. The guidance for Sealing cv=invalid Chains somehow made it into this draft applied to all cv=fail Chains. All Chains should be Sealed in the same fashion (your AS covers the ARC Set you've added and all previous ARC Sets), unless the Chain is invalid in which case you only Seal your own ARC Set.
Ah. Perhaps reword 5.1.1 like this: The signature of an AS header field signs a specific canonicalized form of the ARC Set header values, when all of the previous ARC sets are valid. In that case, the ARC set header values are supplied to the hash function in increasing instance order, starting at 1, and include the ARC Set being added at the time of Sealing the message. If any of the existing sets are invalid, the AS header field only signs its own ARC Set. Within an ARC Set, header fields are supplied to the hash function in the following order: 1. ARC-Authentication-Results 2. ARC-Message-Signature 3. ARC-Seal The ARC-Seal is generated in a manner similar to when DKIM-Signatures are added to messages ([RFC6376], section 3.7). In 5.1.2: In the case of a failed Authenticated Received Chain, the header fields included in the signature scope of the AS header field b= value MUST only include the ARC Set headers in the newly created set, as if this newest ARC Set was the only set present. In 5.2, oldest pass is confusing, since it doesn't tell you whether the validation succeeds or not. I would take out steps 5-7 and add something to the INFORMATIONAL at the end like "A validator can check the AMS headers to estimate when in a chain of forwards the message was modified." Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
