On Sun, 2006-01-22 at 18:46 +0000, Stephen Farrell wrote:
Douglas Otis wrote:
The signature header is not removed,
just the 'b=base64' is obfuscated with a result indicating whether the
MDA verified the signature upon acceptance.
I hate to do this yet again, but the term obfuscation is taken,
and not for what you mean, which confuses me at least. Quoting
[1] for example:
obfuscation - technology to shroud the context and contents of code.
Obfuscated applications function properly, yet confuse human
observers and decompilers.
Would the term signature-overlay or perhaps signature-masking be okay?
The MDA 'w=' parameter ensures this signature will not be
accepted by any other AdmD.
Ok, so you mean something like having an MDA sign in order to
attest that the message arrived with status <foo>. Our charter
has a stretch goal for that specifically not to be done without
a recharter:
Once the primary goals are met, the DKIM working group may also study
whether to adopt a work item for specifying a common mechanism to
communicate the results of message verification to the message
recipient. The generation of a standards-track specification on this
topic will require an update to the DKIM working group charter.
What is being proposed is _not_ a new header or a fundamental change to
the DKIM signature. This proposal involves an introduction of a single
character 'w=' parameter added to the signature. The 'w' parameter
defines which essential elements isolate the source of the message, as
well as the role of the signer. In the case of the MDA signature, the
dkim-options draft defines the MDA (MDA AdmD) role represented as
'w=X'.
The current base DKIM draft does not define how multiple signatures are
handled, how mediators are recognized, or how replay abuse can be
prevented. The rather simple 'w=' parameter adds to the DKIM signature
a basis for solutions for resolving these open issues. This simple
option should not demand a recharter in order to resolve some rather
basic issues, some of which were raised in the initial review conducted
by Russ. This option is also upwardly compatible with the current
implementations.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org