[ietf-dkim] RFC4871bis - whether to drop -- k: Key type
barryleiba at computer.org
Tue Jun 9 19:03:10 PDT 2009
> 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
More information about the ietf-dkim