At 9:12 PM -0700 4/11/06, Dave Crocker 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 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.
It should talk about being able to conduct a validation within a
window of time, and not being able to do it after the window closes.
If that's what the WG wants, great. But that is *not* what the document says:
Signature expiration in seconds-since-1970 format
as an absolute date, not as a time delta from the signing
timestamp. Signatures MUST NOT be considered valid if the
current time at the verifier is past the expiration date.
This is not about a "contract signature" becoming invalid.
"MUST NOT be considered valid" sure sounds like "becoming invalid" to me.
It is more like a traffic light changing. Transit is ephemeral,
so it should not be surprising that a mechanism related to transit
is ephemeral.
This is a good analogy, one that it seems many people in the WG want.
But it is not what is in the document.
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?
"passed the authentication tests" is an accurate description of what
took place. "Message valid at one moment and not at the next" is
not.
We disagree, then. If the verifier checks the validity and it passes,
and later checks the validity and it fails because of x=, then
"Message valid at one moment and not at the next" seems to be a
reasonable technical description of what happened.
A DKIM signature says that someone asserts that they are accountable
for message transit.
And here we are fully agreeing again, although no such simple
statement exists in the document. (Hint: search for the word
"responsible".)
You are confusing limitations in the ability to perform a validation
check, with the continuation of the assertion's validity.
No, I'm not. x= says *nothing* about "limitations in the ability to
perform a validation check"; it *does* talk about "continuation of
the assertion's validity".
If you go through an intersection when the light is green (for your
direction) it was valid for you to proceed. The light changes. The
validity of your having transited the intersection does not.
And, again, we fully agree.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html