Michael Thomas wrote:
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.
I agree. Does that weaken the argument for keeping "x=" in the
base though? Not sure myself.
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"?
Many ca-certs are set to expire in 20+ years which is nonsense.
You can't (easily) put X.509 certs on phones and similar because
the device might stop doing something if the cert expires. What
would have been better would be to make notAfter optional since
there are situations where you don't have any good value to put
there.
But "x=" is currently RECOMMENDED (I assume it means RECOMMENDED
to use, and not RECOMMENDED to implement?) so we're not as bad as
X.509 here.
> 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.
True. Maybe the wording on "x=" could make that clearer if it
said that the value is "how long I expect the message to be
in transit" rather than "signature expiration"?
> 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 :)
At least the latency on that was less than with pk-init :-)
> ...
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.
True again. But it'll still be a source of validation failure simply
because some verifiers won't have good clocks. I guess its fair to
say that that'll be a small number of badly managed MTAs though.
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.
You're an extremist then:-)
(*) <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?
Hope not. I really do. 'Cause that'd mean I'd have to pay a
license to show someone the factors of a number:-(
S.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html