----- Original Message -----
From: "Mark Delany" <MarkD+dkim(_at_)yahoo-inc(_dot_)com>
x= is needed to offer a major DKIM verifier optimization to
address expiring or revoked keys.
This is surely an edge case that Knuth warns us about.
-10
You got to be kidding me? :-)
Besides, you mean Hoare and this has to do with premature optimization in
software engineering where you don't have a clue about the design,
especially when you don't have a handle on your performance bottlenecks or
tradeoffs. Knuth simply repeated what Hoare wrote about approaching
optimization with caution which is basically related to a management
principle based on Pareto.
Paul likes to repeat how the semantics is currently written:
"Signatures MUST NOT be considered valid if
the current time at the verifier is past the expiration date."
The x=tag has a specific meaning from the signer and if it clearly says that
the signature is not valid; the implicit semantic is that there is no need
to do an DNS lookup.
DNS lookups is a source of performance bottlenecks. That is a sound
concept and not premature. Experienced software developers and engineers
will understand this and immediately apply it. No need to wait "until
later" to "find out" if any of this is true. It is not difficult to
realized where performance issues may take take. This is a clear
optimization concept.
Now if you want to explain how this optimization is premature I would gladly
love to discuss it.
I can see how it could be premature... iff we change the semantics: If we
defined the x= tag as x=T2:
The time that the signature may verify but no longer consider
valid. i.e. The key is stale but still valid for signature
verification.
In this case, the optimization is lost because now you have to give
verifiers the option to verify the signature, even if stale. Do we want to
change the semantics to something that allows a stale key to persist?
Also, in section 6.2 Get the Public Key, it has for step 2:
2. If the query for the public key fails to respond, the verifier
SHOULD defer acceptance of this email (normally this will be
achieved with a 451/4.7.5 SMTP reply code).
If there is no x= tag, then the verifier has no choice but to send this
temporary response code (451). However, if the x=tag is present and
expired, then this response code can change to a permanent negative response
code (551).
Therefore, step #2 would have to change to:
2. If the query for the public key fails to respond, and no x= tag
is defined, the verifier SHOULD defer acceptance of this email
(normally this will be achieved with a 451/4.7.5 SMTP reply code).
If the query for the public key fails to respond, and the x=tag
shows an expired time, the verifier SHOULD permanently reject
this email (normally this will be achieved with a 551/5.7.5 SMTP
reply code). This condition is met when the selected has been
removed from DNS.
So in this case, optimization is lost too, but the expiration tag is still
a necessary concept It serves to improve the technical specification for
the SMTP response codes for NXDOMAIN results.
But if we keep the semantics as it is written today, it is an optimization
concept because it doesn't require the overhead in DNS lookup or the payload
hashing overhead.
Look, I am trying to look for a solution here. I'm trying to present all
the issues. If you guys want to remove the x=tag, you will have to address
all the issues with this deprecation, including the high potential for
failed DNS lookups. I failed to see why we would want to limit signers to
expose this important possible key 'event'. I see negatives. No positives
in it.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html