Douglas Otis wrote:
While not currently part of the DKIM draft, this threat review
neglects the possible use of an opaque-identifier associated with
accounts providing server access, and the self-listing of revoked
opaque-identifiers described within:
The threat analysis is really a requirements document. It neither rules
in or rules out the use of things not currently in the DKIM
specification, such as revocation identifiers or SSP alternatives,
because these are choices that might be made in the design phase.
Neither does it discuss other design choices, such as canonicalization
algorithms and header signing alternatives.
Actually this document goes somewhat beyond a pure requirements document
because it does discuss the effectiveness of a particular existing
design, dkim-base-00 and dkim-ssp-00, in responding to these threats.
This is intended to illustrate the approximate effectiveness of
something that approximates DKIM, to show (hopefully) that it does
something useful and is worthy of the formation of a working group. It
is not intended to preclude further improvement of the specifications.
ietf-dkim mailing list