At 5:43 PM -0700 4/11/06, Dave Crocker wrote:
Paul Hoffman wrote:
At 7:46 AM -0700 4/11/06, Michael Thomas wrote:
But that's
a much different proposition than saying that they will be able to
validate them whenever they get around to reading them. That is not
the problem we set off trying to solve.
If the WG agrees with that last sentence, then many parts of -base
need to be rewritten. Currently, the protocol document puts no
limit on quickly the recipient is expected to do the validation.
The focus on transit-related validation -- as distinctly different
from open-ended, long-term validation, has been fundamental for the
entire life of this effort.
Then that should be stated in the document, not just in the lore of
the WG. If it is there and I missed it, I apologize, but I don't see
it. Further, nothing in the discussions of MUAs doing validation seem
to talk about the obvious case that an MUA might do first validation
long after "transit".
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 header simply says that the
message was validated. Not that it can be validated at some point
in the future.
There is a huge disconnect here. x= is *not* talking about the
ability to validate at some point in the future; it talks about a
message that is valid at one point becoming invalid at a later point.
The text in draft-kucherawy-sender-auth-header-03, which is a
normative reference from dkim-base, gives the following semantics for
the "pass" label:
sending domain publishes an authentication policy of some kind,
and the message passed the authentication tests
Note the past tense used: "passed the authentication tests". In a
normal environment, that is sufficient for a MUA to give a sensible
notice. But in an environment where a message can be valid at one
moment and invalid at the next, that is not sufficient to tell the
MUA what to display at any particular time.
Is this clearer?
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.
huh? why?
So that the higher level process can determine when the signature on
the message is no longer valid. Think of it this way: Two people look
at a check. One says to you "this check written out to you is for
$100", and the other person says "this check written out to you is
for $100, but it is no longer valid after tomorrow". Both those
statements are true, but the only the second statement is useful in
making a policy decision about what you should do with the check.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html