Barry,
I don't recall the reason for them in the base spec, but as I recall
there were exchanges to explore the compatibility idea via policy. The
I-D policy proposal (DSAP)l I wrote was based on these discussions:
http://tools.ietf.org/html/draft-santos-dkim-dsap-00#page-15
The main purpose of the a= tag is to allow domain signers the design
and implementation opportunity to determine the highest strength
possible by a particular target verifier by looking the DSAP DNS
record for the target recipient domain host. If this query results
with no a= tag information, the default should be rsa-sha1 is the
highest strength possible.
Essentially, this is a negotiation and backward compatibility
concept. It is quite possible earlier pre-standard DKIM
implementations supporting only rsa-sha1 may still exist. The domain
DKIM message signer's desire is to achieve the highest protection
possible. Instead of signing mail with a particular algorithm and
hoping for the best, the signer can predetermine what the receiving
system can handle in terms of hashing strength.
and I believe Doug's own proposal also touched base with it.
But as I recall, the push back was that it was would another lookup
which to me is a non-issue for domains who will be thinking to maximize
secure exchanges knowing 100% that any strength upgrade will put them
into a compatibility problem. So if they really wanted to see if an
important target domain supported XYZ, they can lookup it up.
==
Barry Leiba wrote:
Help me understand. Describe the use case where someone will use it.
Here's what I remember from the original discussion of h= and k= in
the key record.
First, part of the idea was to have them both there, to make things
parallel: "This key is used for this crypto suite."
Now, as I remember -- and it's been a long time, and I've killed many
brain cells since then -- at least one scenario we discussed was this:
1. Crypto suite X had been seriously cracked, such that an attacker
could, at least in some cases, create a valid suite-X signature on his
own. Perhaps there was a badly broken hash algorithm, perhaps there
was a way to reverse-engineer it from a bunch of collected real
signatures, or whatever.
2. Signer A, knowing that, will never, ever sign with suite X, and
exclusively uses suite Y. Smart signer.
3. Verifier B, however, continues to support suite X. Maybe they're
not as smart, or maybe they just want to keep verifying the suite-X
signatures from less-smart signers.
4. An attacker fakes a suite-X signature from signer A, and sends it
to verifier B.
The argument I remember was that if signer A had a way to say "This
key is only used with suite Y," then verifier B would know that the
signature was bogus. Lacking that statement, the signature will
verify and appear fine, even though it came from an attacker.
That could provide a transition period, until "all" verifiers had
stopped accepting suite-X sigs.
Does anyone else remember anything vaguely similar to what I've said?
(Note that I'm not arguing to keep h= and k=, here... I'm just trying
to recall the discussion that led to their inclusion in the first
place.)
Barry
_______________________________________________
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