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
