ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Proposal: get rid of x=

2006-04-07 08:23:30
Stephen Farrell wrote:
 > 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.

  I don't think so.

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.

  Right, but the situation here is not even remotely the same.
  We *want* these signatures to stop working after some period.
  We *don't* want them to be valid in perpetuity. That's certainly
  not the case with a phone certificate.

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.

  I think it's recommended to use.

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"?

  You could, but the semantic is more of a "I don't want this
  to be in transit after X". You mentioned NNTP Expires, and
  I think that's a pretty good analogy, though not exact.

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.

  Right. Kerberos and its clock skew woes largely predate easy access to
  [S]NTP. For mail infrastructure -- not MUA's -- I don't think this is
  a terribly hard problem these days, and screwed up clocks on MTA's
  most likely cause all kinds of other problems for admins -- like
  trying to diagnose why mail at X'oclock didn't get through.

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:-)

  Heavens, not again.

                Mike
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html