> 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
