I thought this was resolved via an expiration date x= flag. With this
flag set a mua could certainly know whether a signature was still valid
before attempting to verify it.
Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Douglas Otis
Sent: Friday, January 19, 2007 12:59 PM
To: Stephen Farrell
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] draft-ietf-dkim-base-08 submitted
On Jan 19, 2007, at 3:57 AM, Stephen Farrell wrote:
Thanks Eric,
Eric Allman wrote:
I have submitted draft-ietf-dkim-base-08 for publication. This
has some
significant changes requested by the IESG. Probably the most
significant is the addition of section 5.4.1, "Recommended Signature
Content". The changes are summarized in Appendix F.1.
6. Verifier Actions
Since a signer MAY remove or revoke a public key at any time, it is
recommended that verification occur in a timely manner. In many
configurations, the most timely place is during acceptance by the
border MTA or shortly thereafter. [In particular, deferring
verification until the message is accessed by the end user is
discouraged.]
This precaution should be removed!! When the public key record is
revoked due to abuse, then not immediately verifying a message offers
what might be valuable time. It is also likely the _only_ sure means
to protect recipients from spoofing is through annotations applied by
the MUA based upon recipient trusted email-addresses. Do not forget
about the EAI changes and the vast range of resulting look-alike
attacks made possible.
While trust might be established between the MDA and MUA, DKIM does
not provide a means for making that determination. Without the
ability of the MUA to also validate signatures, then any annotations
applied based upon assumed trust in the MDA and some headers that may
or may not be added imperils the recipient. Don't make the mistake
that sender policy offers a reasonable solution either. Annotation
based upon added headers or assumed application of sender policy
reduces security. Rather than discouraging deferred verification,
discourage the rapid removal of keys! There is an expiry that can be
applied in lieu of key removal which can be compared against when the
message was delivered. There is no valid reason to rapidly remove
valid keys.
One of the benefits of DKIM is that annotation does not need to rely
upon headers that may or may not be added by the MDA, which of course
may or may not be also signed (and for how long?).
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html