On Thu, 2006-06-08 at 09:08 -0400, Bill(_dot_)Oxley(_at_)cox(_dot_)com wrote:
Doug,
You are dictating what a sender and verifier must do. If I have a faulty
algorithm and change my keys to reflect the new ones I may not be
interesting in signing with what I consider a depreciated key. I signed
my mail, published a key and sent my mail. A receiver who gets old mail
that does not verify can use local policy to determine what to do.
The signing domain free to not sign with what they consider to be
unacceptable. The added text does not prevent that at all, nor does it
require any special action in that case. It only says that if you
"mark" a signature and key as deprecated, the signing domain must
include a signature and key that is not marked as deprecated. This is
the _only_ added requirement for the signing domain.
The text was changed to call an unacceptable signature version obsolete
rather than deprecated, as deprecated implies soon to be obsolete. The
verifier should use a signatures not marked as deprecated from the same
domain when possible, however the verifying domain may still consider
this remaining signature obsolete based upon their policy.
Spammers recognizing a key change may flood the market with spuriously
signed messages purporting to be from me for a brief period of time but
I would expect that from non-depreciated key holders as well.
This is what the change prevents. By brief, this could take years. Mark
the key you want to retire soon as deprecated, but this must accompany a
signature from the same domain not marked as deprecated. This assumes
the damage caused by an erratic exploit is less than what you have just
described. You have underestimated what is implied by brief.
Your purported solution doesn't solve this.
Oh but it does. This change requires that a message must include at
least one signature not marked as deprecated from the same domain. This
assumes the deprecated signature has not suffered a complete failure,
otherwise a disruption can not be avoided anyway.
I could publish 7 keys 6 that are depreciated and spammers will still
send out badly signed email, it still resolves to local verification
policy and all the headers in the world wont change that.
The requirement that a non-deprecated signature must be included means
that once the verifier becomes upgraded, an erratic exploit is
prevented. This can happen much sooner than expecting all to upgrade.
The difficult case is dealing with something that is not completely
broken. Your car is sputtering, but rather than calling for a tow truck
and a cab, you continue driving until you make it to a garage that can
make the repair. An abrupt change in signatures would be like calling a
tow truck every time the engine sputtered. That action will likely
astonish your recipients who will likely consider this a poor choice
when a less disruptive solution was available (or at least could be
available by making a minor change to the version ABNF in the base).
Definitions:
Deprecated - Will be made invalid or obsolete in the future.
Obsolete - Is currently invalid.
Change to:
: When evaluating a message with multiple signatures,
: a receiver should evaluate signatures by different
: signing domains independently. A receiver,
: that by policy considers a crypto algorithm or
: service to be obsolete, should ignore the signature
: and consider it invalid. Multiple signatures by the
: same domain must include at least one signature
: version that has not been marked as deprecated.
: When an alternative version of a signature is
: from the same domain is supported, this signature
: should be used in preference to a signature marked
: as deprecated. As with messages with a single
: signature, receivers are at liberty to use the
: presence of valid signatures as an input to local
: policy; likewise, the interpretation of multiple
: valid signatures in combination is a local policy
: decision of the receiver.
: v=
: Version (MUST be included). This tag defines
: the version of this specification that applies
: to the sign
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.htmlature record. It MUST have the
: numeric value 0.2. The signing domain may
: mark the signature as deprecated by appending
: a "d" character to the version value.
:
: ABNF:
:
: dkim-sv = "0.2"
: sig-v-tag = %x76 [FWS] "=" [FWS] dkim-v ["d"]
:
: v=
: Version of the DKIM key record (plain-text;
: RECOMMENDED, default is "DKIM1"). If specified,
: this tag MUST be set to "DKIM1" (without the quotes).
: This tag MUST be the first tag in the response.
: Responses beginning with a "v=" tag with any other
: numeric value MUST be discarded. The signing domain
: may mark the key as deprecated by appending
: a "d" character to the version value. When the
: DKIM-Signature version is marked as deprecated,
: the DKIM-Key version MUST BE included and marked as
: deprecated.
:
: ABNF:
:
: dkim-kv = "1"
: key-v-tag = %x76 [FWS] "=" [FWS] "DKIM" dkim-kv ["d"]
: INFORMATIVE IMPLEMENTATION NOTE: The DKIM Signature and
: Key versions will both have the numeric value "1" in the
: final draft.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html