In article <363edd8b-2654-4d81-ad41-d355599d3...@att.com> you write:
>-=-=-=-=-=-
>Right now we require support for two types of keys: a weak one (sha1) and a
>strong one (sha256).
True, but it's important to note that we don't require anyone to sign
with weak keys. A key record in the DNS can
>Maybe we can build timelines into the updates. By Jan 1, 2019, receivers
>SHOULD (MUST?) no longer support the
>following key sizes or algorithms. That way, if anyone complains that a
>particular DKIM-signature is not
>considered valid, we can always say it’s RFC non-compliant.
The IETF
>If you believe sha256/rsa1024 are forever, there is no actual need for
>draft-srose-dkim-ecc-00.txt. The problem is, this need may arrive at
>some time, and this time is hardly predictable. There is also possible
>there may be the need to roll back ECC and mark it as insecure at some
>point of
If you believe sha256/rsa1024 are forever, there is no actual need for
draft-srose-dkim-ecc-00.txt. The problem is, this need may arrive at
some time, and this time is hardly predictable. There is also possible
there may be the need to roll back ECC and mark it as insecure at some
point of time.
Without marking the published key as obsolete, downgrade attack is
possible, because attacker can still use a weaker key to spoof
signature.
If you know how to spoof a sha256/rsa1024 signature, I know a lot of
people who would like to talk to you.
Other than that, please review RFC 6376.
