At 4:13 PM -0700 4/11/06, Michael Thomas wrote:
Paul Hoffman wrote:
At 7:46 AM -0700 4/11/06, Michael Thomas wrote:
Further, section 6.4 makes no sense and has to be eliminated or
seriously re-written. You can't put a header in a message for a
fact that will become untrue in the future. The semantics of such a
header will need to be changed to "This signature is valid when
this header was created, but will become invalid at time xyz".
I'm having a hard time understanding the hand wringing here. This
can happen at _any_ time if you remove the selector from the DNS
too. So what?
That is simply not true. If you don't have restrictions on how long a
signature is valid, once it has been validated, it never expires. The
fact that you cannot re-validate at some point in the future is
completely unrelated to its validity.
Saying that a signature becomes invalid when the DNS record is
removed is like saying that a paper contract becomes invalid when the
person signing it becomes unavailable to sign again to prove the
signature.
As far as I can tell, the only thing that needs to be "rewritten"
is to mention x= in the step-by-step.
It needs more than a "mention". For example:
Once the signature has been verified, that information MUST be
conveyed to higher level systems (such as explicit allow/white lists
and reputation systems) and/or to the end user.
With x= in the equation, that changes to:
Once the signature has been verified, that information MUST be
conveyed to higher level systems (such as explicit allow/white lists
and reputation systems) and/or to the end user, and MUST include
the validity period of the signature so that the higher level
systems can change their actions based on the current time.
And so on.
Further, section 6.5 will have to be re-written as well to say that
when passing the signature validation information to higher-level
processes, they will need to come with the time after which the
signature is no longer valid.
Section 6.5 says in its entirety:
"verifiers MUST consult the Sender Signing Policy as described in [ID-
DKIM-SSP] and act accordingly. The range of possibilities is up to
the verifier, but it MAY include rejecting the email."
My copy of 6.5 is much longer than that.
If there's a problem here it's that it doesn't enumerate all of the
outputs of the verification process. x= is only a small part of
those outputs.
x= is the only "feature" so far that changes the validity of the
signature based on the time, and is thus the only one that affects
the verification process at a time other than at the moment the
verification happens.
There are probably more silly states related to x= in the document
as well. They will need to be fixed before the document can be
considered to be finished.
If there are "silly states", they apply equally to removing a selector
from the DNS. So removing x= from the spec does not relieve us of that
exercise.
Again, that is completely, and demonstratively, wrong. If you remove
the selector from the DNS, verification fails predictably at the time
the recipient tries. The x= semantics say that a signature can be
valid at one moment and invalid at the next. Note the difference
between those two.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html