Hello, This is something of a continuation of my other email wrt section [5.2.1] of the draft. I've discovered an even larger range of indeterminate cases wrt to this section, and any attempt to rectify this within the given framework seems to get fairly messy. Basically, there is a large class of input headers that aren't covered by the current language, and cant be signed.
The basic problem is that for a large range of invalid messages, the notion of arc set is not well defined. The standard notion of arc set is all fields with identical i= tag. This notion breaks down when you have violations such as duplicate i= values. The only way we can recover our notion of arc sets at this point is to define arc sets *logically* as contiguous blocks of arc headers(AS, AMS, AAR) in the input emails. Section [5.2.1] seems to be operating tacitly under this revised definition, and given that the ordering it specifies makes sense. However if we have further degeneracy wherein we can no longer logically form arc sets, either because of missing or invalid i= values, or intermixed/incomplete sets, the ordering in section is no longer applicable, and we're left with a huge gap. I think its clear that we fail all of these messages. But for signing, we need to specify an ordering on these pathological arc headers, as section [5.2.1] only applies when you can logically define arc sets. We also probably need this ordering to downgrade to that in section [5.2.1] when applicable, and to the defacto ordering in the standard case. The obvious solution here is to simply sign *all *arc headers under all sealing/validation operations in a bottom up order, regardless of the validity/ordering of the headers in the email. Reasons that this is good: - This is the simplest language - This probably has the simplest implementations - Assuming validly signed inputs this defaults to the ordering in section [5.1.1.3] - This also defaults to section [5.2.1], in the slightly less valid, but still broken state, apart from the alphabetical ordering clause - I think this is basically what's implicitly intended throughout the draft. The only other way I can see to approach this issue is to continue down the path of [5.2.1] and define an additional ordering on these pathological cases. It seems wrong to me to force implementors to provide whatever weird sorting functionality this would be, just for the sake of signing pathological examples, so I recommend against this approach. So I think the universal bottom up ordering is the way to go. Anybody have any opinions here? I'm happy to take the lead on proposing changes to the draft. Regards, =Gene
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
