Hi All, I'm currently working on a test suite for ARC, and have run into a few areas in the draft that could use some clarification, mostly with regards to section 5.2.1, which seems like it needs a non-trivial update. I've run into the following issues:
- Can messages with violations in their ARC sets(duplicate/malformed i= values, etc), still be considered valid, assuming they pass the chain validation algorithm under the given ordering? - Similarly, can messages with completely duplicate ARC sets still be considered valid? One might expect that these gross violations of the protocol would cause chain validation to fail regardless, however the language 5.2.1. Handling Violations in the ARC Sets > > ....... > > numbers), such header field set(s) MUST be ordered as follows when > > analyzing for *validity* or subsequent signing: > > > seems to imply otherwise. - when implementing the ordering in [5.2.1] for signing, do we include ARC header fields with invalid or non-existent values of i=? missing, i=;, i=-1;, i=string; are all cases that need to be addressed. Easiest would be just to not include them. - Section [5.2.1] says to remove fully duplicate sets, but doesn't mention fully duplicate instances, that dont form a complete set. Is there any reason we're not removing those as well? That seems easier. - Say we're computing AS(2), and are provided with AS(1), AS(1), AMS(1), AAR(1), where we have duplicated i=1 Arc-Seals. It's not entirely clear where the duplicate AS(1) is ordered in the signing process. The relative ordering of the two AS(1)'s is specified in the draft, but is it the case that within an arc set, all AS's are signed before all AMS's? I would assume that the ordering is as I've specified above, but that ordering vs say AS(1), AMS(1), AAR(1), AS(1) isn't entirely clarified. Aside from this family of issues, I've also come across a few other issues that I could use a a bit of clarification on for my work on the test suite. - Arc-Seals are explicitly forbidden for inclusion in Arc-Message-Signatures, but there is no mention of possibly including previous Arc-Message-Signatures in newer signatures, despite the fact it's fairly pointless. Is this intentional? - For both seal & message signatures computation, the spec explicitly states that relaxed header canonicalization is to be used, but for makes no comment about body canonicalization for AMS. Is simple a valid option? It may be worth explicitly noting this. Any thoughts/feedback/clarifications with respect to these issues would be greatly appreciated. Regards, =Gene
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
