Stephen Farrell wrote:
Paul Hoffman wrote:
Note that the informative note only says what x= is not. Leaving x=
in can also lead to silly states.
What states might those be?
I was also wondering about that. I guess that "x=" is a way to make
it crystal clear that this signature is (probably, potentially)
totally worthless in some court case in 5 years time - a v. good
feature (*). It would also help if someone wanted to auto-generate
new signing key-pairs at about the latency with which their DNS
stuff becomes available (but I don't know if that info's available
to the verifier via DNS - is it?).
> Were we to ask verifiers to
interpret "x=" as guidance, and not as a way in which it MUST
fail a signature, then its optional inclusion may well help some
layer above DKIM.
I've struggled with that too... for DKIM purposes, it really does
fail to "verify", but so do other situations where you could conceivably
apply some heuristics to glean interesting information despite
"failure". As with the last round, I don't think they belong in the
spec though -- it's not our job to discover or even evangelize
these uses, especially at this point. If we were ever to say anything
about these kinds of things, I'd think that it ought to be part
of a BCP after we've had a fair amount of experience and evidence.
However, on Paul's side of the argument, it is true that many, if
not most, people recognize that insisting upon X.509 certificates
having to have a notAfter date was a mistake. So, there is a bit of
prima-fasciae evidence that signed-things-with-stupid-expiry-values
are problematic in some cases, though that analogy really holds much
better against the key record and not the signature.
Can you expand here? And espcially as it relates to DKIM? And
"stupid"?
> To be concrete
about problems-ensuing: I guess if an MUA were DKIM-aware then "x="
creates a dilemma for the MUA programmer in cases where the mail
isn't read until after the relevant time.
Yes, but this was a non-goal. We've said all along that it could
be done in an MUA, but not that it was generally a good idea to
put in an MUA since DKIM is intended to have a transport lifetime
relevance. This is just as true with removing selectors. The right
thing here is for a transport agent of some kind to verify the
signatures on the MUA's behalf at transport time and annotate the
message for later MUA rendering operations (hi Murray!).
> I also remember trying
to shoe-horn a Kerberos thing into being usable on an extranet - the
clock skew was such a killer that we had to open the window to
ridiculous levels.
As the author of rfc 4430, I'm well aware of skew :) What seems
different here is that the affects of opening the window so to speak
don't really seem all that bad. It's not like we're trying to achieve
tight windows so that you can limit your inability to expicitly revoke
(as with Kerberos). Indeed, we already have that ability modulo DNS
TTL's. So the skew only needs to hit the broad side of a barn -- if
you want 2 weeks, then set it to 4 weeks. The gaol here is to not
accrete entropy.
But, facts outweigh opinions: are there specific verifier uses
cases that act upon the "x=" value?
My software checks the x= value and treats an expired message
as a verification failure... nothing complicated.
(*) <rant now="y"> If "x=" survives and becomes practically used
by verifiers then I would encourage DKIM implementers who *really*
want their signatures to be worthless at some point in the future
to agree to publish their old private keys a little while after they
are finished with using those private keys. Giving everyone the
means to repudiate old transactions is IMO an excellent way to
prevent a lawyer/<<thing>> from pretending that you meant a
signature to be some kind of pseudo-non-repudiable thing!
</rant>
Isn't this approach patented though?
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html