On Wed, Jul 25, 2018 at 2:34 PM, Seth Blank <s...@sethblank.com> wrote:
> When we introduced the concept of cv=invalid last year, the advice was to > only sign your own ARC Set, because there was no deterministic way to know > which header fields to sign when those ARC header fields were not properly > intact (the definition of invalid). We then decided to abandon the > cv=invalid path and only have cv=fail. > > Somehow, in the current doc this advice for invalid chains now applies to > all chain failures. Section 5.1.2's title even mentions it is for the > invalid case, but the text as written applies to all failed chains. > > Without the ARC Seal covering the ARC header fields in the failing chain, > all the data in the failed chain can be modified as it is not covered under > the latest signature. > > The proper guidance should be that the ARC-Seal MUST sign the ARC Chain in > its entirety, unless that is structurally impossible, in which case it > should only sign itself. > > I believe the proper text for this section (replacing the first paragraph > for 5.1.2 in its entirety) should be: > > In the event that it is not possible to generate a deterministic list > of previous > ARC Sets to sign (such as when the chain undergoing validation > is structurally invalid), the signature scope of the AS header field b= > value MUST only include the latest ARC Set headers as if this newest ARC > Set was the only set present. > I think it's weird that the body of content that gets hashed by the sealer in this case varies from what would normally happen. A verifier might have to try two different verification algorithms if, for example, it doesn't determine that the chain is structurally invalid. If I receive a chain that was apparently valid at the last sealer and determine that it is no longer so, could we simply decline to re-seal it at all? -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
