-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <[email protected]
il.com>, Murray S. Kucherawy <[email protected]> writes
>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.
Apologies if I misled ... anyway, if people want to change hash in DKIM2
then they need to specify that in the header fields (and of course
choose something which is specified to be valid). Thus, discovering that
the hash does not match when you have fetched the key is not especially
helpful. As such I think we should continue to document how this tag
works with DKIM1 but explicitly state (in Wei's draft) that DKIM2 will
ignore it.
>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.
There is a considerable appetite amongst email senders for email
receivers to be much more consistent in how they report errors (and I
would suggest that should trump concerns about "specifying APIs" which
is not quite what we are doing.
That is why the current draft (draft-ietf-dkim-dkim2-spec) goes to some
lengths to spell out some exemplar text for reporting validation
failures.
As such distinguishing between FAIL and PERMERROR is straightforward and
I see no reason not to do require that.
- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBagHpD2HfC/FfW545EQIFtQCeIWYr6vOYjpfRw1N+0Iqg52kGqXYAoIs4
6CnnROOHI0d67EIoZwF8lmmb
=u1eT
-----END PGP SIGNATURE-----
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
