Frank Ellermann wrote:
If it's not verifiable, it's not a signature. (The same applies
to "invalid signature", of course).
Probably Charles means "unverifiable == verifier doesn't know how
to check it (it could be valid or invalid otherwise)", and uses
"invalid" for "it's definitely wrong with the specified algorithm".
The point is that this is a only a reason for the invalid state. There
could be many reasons:
- key is missing (i.e, DNS failed)
- expired
- body hash failed (pieces are available, it just fails)
- signature failed (pieces are available, it just fails), and
- unknown hash
etc. What needs to be done is a guideline for verifier handling for a
list of very possible and probable encounters.
The specification solution today is what I call FSUSP (Failed Signature
Unsigned Status Promotion) and my point FSUSP is not the same as a real
NO SIGNATURE message.
To me, a NO SIGNATURE should have one trigger - check the SSP to see if
its has to be signed.
To me, FSUSP concerns me a lot and I believe it can be very damaging to
DKIM adoption if FSUSP creates avalance of mail abuse.
The folks supporting to list used algorithms in the SSP apparently
think that receivers could care about this nuance. And the folks
opposing that idea note that spammers would try to abuse this info.
Any advertised information can be exploited, but if it is or not
advertised, for the VERIFIER (and SIGNER) the problem will still exist.
To me, the VERIFICATION process is the most important part, yet, I am
not interested in making it very heavy loaded with useless processing.
Yet we need to understand what are the short circuits of the protocol.
To find them, you list your possible error conditions (or conditions
that create a valid/invalid state) and find how to eliminate the obvious
- Query Dissemination process.
In this case, the most probable scenario is a signature that validates
which means the key existed. If the signer did not want that, I can't
see any other way but to nullify the key.
I can't see how the verifier can make an "exception" to the scenario
where the signer has a NEW method (advertised or not) but the current
message has some other older method and the key was pulled. If it was
not pulled, well, there is really nothing you can do about that.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html