(participating) While generating minutes for IETF 125, which I was not able to attend, two discussed items caught my attention:
One of Richard's slides said the "h" tag on keys suggests hashes that could be used (it's defined as "acceptable hash fields"). My understanding is the inverse: it allows you to announce which hashes are approve for use with that key, so removing a hash from that list invalidates any signature using that hash with that key. It was meant to allow hash rotation. I don't know if this is helpful though, as I don't think there has been more than one opportunity recently to rotate an algorithm in or out. On the discussion of DKIM outputs vs. Authentication-Results status: RFC 6376 references to PERMFAIL being returned for a variety of reasons, and generally in the text there's a "PERMFAIL (reason-text)" sort of presentation. PERMFAIL itself blended all possible failures, while implementation and integration with SMTP needed a more rich response structure. Authentication-Results attempted to make a distinction between PERMFAIL because everything was well formed and the algorithm worked but the crypto failed (a true DKIM failure, which is "fail") versus, say, a PERMFAIL because of a syntax error or some other error preventing DKIM evaluation from completing (which is A-R's "permerror"). I think DKIM2 could do just fine returning a tuple of results matching this previous model. The first element of the tuple can be the same three responses DKIM did, and the second element can include the specific reason when the first element isn't "OK". I don't think we need to be more specific than this, or we might be seen as wandering into API specification which the IETF tends to avoid. -MSK
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
