I know I lost the argument on cv (I think cv is entirely superfluous and there's no point adding/signing a cv=fail header), but it seems the argument for that is more data. That said, this "either or" signing set thing on cv=fail seems pretty cumbersome.
Brandon On Mon, Jul 30, 2018 at 5:42 PM John R Levine <[email protected]> wrote: > > 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, [email protected], Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
