Subject: Re: [ietf-dkim] Introducing myself

From: Eliot Lear <[email-masked]>
Date: Tue, 31 Oct 2006 07:27:14 +0100

Hi Charles, and welcome.  I can't answer many of your questions, but I 
can certainly take a whack at a few.

>> 3.3.3  Other algorithms
>
> Presumably there is nothing to prevent allowing PGP as the signing
> algorithm in the future, if someone makes out a good case for it.
PGP, to the best of my knowledge, is neither a hash nor a cryptographic 
algorithm, but makes use of both.  We should anticipate new algorithms 
for each in the future, but this is not something we want to have a 
plethora of, lest we fragment the installed base.
>
>> 3.4  Canonicalization
>
> In what circumstances is the 'simple' canonicalization inappropriate, and
> why is it the default?
>
> Is it not the case that the "meaning" of a message is, according to RFC
> 2822 etc., unaffected by changes of folding, or of case of header-names,
> or of CTE, or of encodings or re-encodings using RFC 2047 or RFC 2231? 
> And
> hence any canonicalization that preserves "meaning" cannot do any harm?
> Anyway, I shall return to this when I come to section 5.3.
>
>> 3.4.2  The "relaxed" Header Field Canonicalization Algorithm
>
> Is it possible that re-folding a structured header en route will 
> introduce
> a WSP that was not there beforehand, and thus break the signature? I
> avoided this in my own draft by ignoring all WSP in headers, except when
> inside comments and quoted-strings and in structured headers such as
> Subject.
>
>> 3.5  The DKIM-Signature header field
>
> Although your charter forbids you from discussing non-repudiation,
> authorization, and other matters not strictly relevant for DKIM, it is to
> be envisaged that other applications will arise from time to time
> requiring signatures over headers, and it would be unfortunate if each
> such application had to invent Yet-Another-Signing-Protocol when a simple
> adaptation of what you have written would have sufficed. There are 
> already
> too many only-slightly-different-wheels in existence for us to be
> inventing any more.  Surely, a facility for signing headers should be
> described as a tool which can then be used for various applications in
> future, of which DKIM would be just the first? So why was this approach
> not taken?

In fact it is.  The DNS record contains s= for this purpose, and the 
purpose of the signature contained within the message can be inferred by 
the application invoking it ;-)

>
> In fact, you almost made it. The only features which might make it hard
> for future applications that I can see are the appearance of "DKIM" in
> your newly invented "DKIM-Signature" header (it rather needs an
> 'application' tag in the signature to indicate why the signature was
> made), and the insistence that the d= and s= tags, which together 
> identify
> the owner of the key, should be syntactically of the form of domain-names
> (which might be totally inappropriate for those other applications, 
> though
> it should clearly be required when the application is DKIM).
>
> Can the various tags appear in this header in any order? OTOH, why is
> there not an insistence that the b= tag should come last (since it has to
> be easily joined to and separated from the rest)?

I can't speak to anyone's implementation, but general SMTP folding rules 
apply, no?

>
>
>>    v=  Version (MUST be included).
>
> Does the version relate to the version of the algorithm identified by the
> a= tag, or to the version of dkim-base as a whole? IOW, if someone 
> invents
> a new tag, or a new tag-value, that can be safely ignored by existing
> implementations, is it necessary to invent a new version?

Version of DKIM, but I think this is a valid point.
>
>
>>    bh= The hash of the canonicalized body part of the message
>
> Yes, I like this, since it enables some useful information to be 
> recovered
> if the header hash succeeds but the body hash fails.
>
>>    d=  The domain of the signing entity
>
> Is this case-insensitive?
>
>>    h=  Signed header fields
>
> Why MUST NOT this list be empty? Suppose you want to sign the body, but
> not any headers? Unusual, but perhaps sensible for some application. No
> interoperability arises.
>
> I don't understand the remark about "message/rfc822 content types". How
> can this problem arise?
>
>>    i=  Identity of the user or agent
>
> Is this case-insensitive (I might expect a different answer there for the
> <local-part> and the <domain-name>)?
>
> Why MUST the <domain-name> be a subdomain of the d= tag (and why not of
> the s= tag, and what interoperability arises anyway)?
>
> Must this tag, if a <local-part> is present, be a valid working email
> address?
>
>>    l=  Body length count
>
>>            INFORMATIVE IMPLEMENTATION WARNING:
>
> I am very suspicious of the propriety of suggesting, in any IETF 
> standard,
> that it is legitimate to remove text from a message being conveyed
> (certainly without the consent of the recipient). Surely marking it with
> blood-red ink, or warnings in 32pt characters is as far as one should go?

What if it's executable code inserted by an attacker?

>
>
>>    q= A colon-separated list of query methods used to retrieve the
>>       public key
>
> Clearly, the use of DNS or some similar global database is the only
> sensible PKI that is workable for DKIM. But am I right in saying that 
> this
> tag does not preclude the use of other PKIs for other applications (e.g.
> attached certificates, web-of-trust, private agreements between the
> communicating parties, etc.)?
>
> Why MUST signers support "dns/ext" (clearly, verifiers MUST)? Surely a
> signer who, as a matter of policy, always chooses to use some other query
> method, is not obliged to implement something he is never going to use.

You can do what you want between two parties with pre-arrangement, but 
that's not the interesting case DKIM is attempting to solve.  In fact, a 
primary purpose of DKIM is to enable trusted introducers.  And so a 
single common method is needed for interoperability.
>
>>    s=  The Selector subdividing the namespace
>
> Case-insensitive?
>
>>    t=  Signature Timestamp
>
>>        ...  The format is the number of seconds
>>        since 00:00:00 on January 1, 1970 in the UTC time zone. ...
>
> Strictly speaking not true, since the usual UNIX algorithm for 
> calculating
> this quantity takes no account of leap seconds. I presume this is all 
> laid
> down in POSIX somewhere.
>
> And expecting this to work up to AD 200,000 seems an overkill (though
> beyond 2038 would be helpful).

I believe for purposes of this discussion this is not a big deal.

>
>>    z=  Copied header fields
>
>>        Verifiers MUST NOT use the header field names or copied values
>>        for checking the signature in any way.  Copied header field
>>        values are for diagnostic use only.
>
> Why ever not? I can think of examples where a verifier might find it
> exceedingly useful to be aware of the original state of some header which
> might have been changed somewhere en route. And what potential
> interoperability arises if a verifier makes some use of this information?

Because z= field does NOT get rendered to the user, but rather the real 
header fields will.  It makes no sense that the z= field should be 
verified and the others are not.  Allowing otherwise would provide for a 
malicious opportunity.
>
>> 3.6  Key Management and Representation
>
>>    public_key = dkim_find_key(q_val, d_val, s_val)
>
> I do not find the operation 'dkim_find_key' defined or used anywhere else
> in the draft.
>
>> 3.6.1  Textual Representation
>
>>    h=  Acceptable hash algorithms
>
>>        ...  Signers and Verifiers MUST
>>        support the "sha256" hash algorithm.  Verifiers MUST also support
>>        the "sha1" hash algorithm.
>
> Why MUST signers support the "sha256" hash algorithm (clearly, verifiers
> MUST)? Surely a signer who, as a matter of policy, always chooses to use
> sha-1 is not obliged to implement something he is never going to use?

Again, for interoperability.  We picked one.  That was the one.

I'm sorry, but I've run out of time and must be on a plane shortly.  
Perhaps others will pick up the ones I did not answer.

Eliot
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 30 Oct 2006 21:42:21 -0000

Firstly, let me apologise for not appearing on this list earlier, but I
only became aware of this project a little over a week ago, and I have
been studying the documents carefully since then, as time permitted.

I am familiar with the two existing schemes for signing headers of
messages, namely
     PGPVERIFY, for authenticating control messages in Netnews
     PGPMOOSE, for authenticating articles posted to moderated newsgroups
and I have experience of both sending and acting upon PGPVERIFY messages,
and of hacking code to process them.

Moreover, at a time when the ietf-usefor WG was considering a replacement
for PGPVERIFY (which has some technical problems, and it not in a fit
state for standardization as it stands) I wrote a draft for a complete
header signing scheme, although the Usefor WG decided at that time not to
proceed with it as it was having trouble enough dealing with more pressing
issues. It is, in principle, still on the list of future work for that WG.

My draft has long since expired as an ID, but it may still be seen at
     http://www.imc.org/ietf-usefor/drafts/draft-lindsey-usefor-signed-01.txt
and it may be of interest to members of this list. It has many similarities
with the DKIM-base, but also many differences, in particular a somewhat  
more
aggressive canonicalization.

At that time, I tried to interest the ietf-822 mailing list in it, but the
Grandees on that group informed me, in no uncertain terms, that signing of
email headers was a totally unnecessary concept that would never be of any
practical use :-( . Nevertheless, I still took care to ensure that my
draft was workable both for Email and Netnews.

On studying the DKIM-base document, I find many features that are
excellent, a few that are perplexing, and a couple that I consider
downright harmful. But as a newcomer to this list, and particularly AIUI
you are trying to get this proposal finalized as soon as possible, it
would be inappropriate for me to barge in with a long series of problems
and counter-proposals.

So I will, instead, stick to asking questions which I hope some member of
this list will be kind enough to answer, and then some of my perplexities
will hopefully be reduced.

Note that these comments are in terms of the dkim-base-05 draft. I have
looked briefly at draft-06, particularly at its list of changes from
draft-05, but it seems most of what I wanted to say still applies.

> 3.1  Selectors

Is a <selector> case-insensitive as domain-names are? And is it to be
rendered in IDNA if a Non-ASCII charset is involved?

> 3.2  Tag=Value Lists

>       INFORMATIVE IMPLEMENTATION NOTE:  Although the "plain text"
>       defined below (as "tag-value") only includes 7-bit characters, an
>       implementation that wished to anticipate future standards would be
>       advised to not preclude the use of UTF8-encoded text in tag=value
>       lists.

Those future standards are nearer than you think. The currently active
ietf-eai WG is charged with producing an experimental protocol for writing
headers in UTF-8. Would it not be wiser to make support for arbitrary
octets (except those essential for parsing such as ";", CR, LF, etc) a
MUST accept right from the start?

As a matter of interest, why don't <tag>s use the same syntax as <token>s,
which appear in similar contexts in RFC 2045 and other places (but without
any hint of CFWS around them, of course). And are <tag-name>s case
insensitive?

or of CTE, or of encodings or re-encodings using RFC 2047 or RFC 2231? And

> 3.4.2  The "relaxed" Header Field Canonicalization Algorithm

Is it possible that re-folding a structured header en route will introduce
a WSP that was not there beforehand, and thus break the signature? I
avoided this in my own draft by ignoring all WSP in headers, except when
inside comments and quoted-strings and in structured headers such as
Subject.

adaptation of what you have written would have sufficed. There are already

In fact, you almost made it. The only features which might make it hard
for future applications that I can see are the appearance of "DKIM" in
your newly invented "DKIM-Signature" header (it rather needs an
'application' tag in the signature to indicate why the signature was
made), and the insistence that the d= and s= tags, which together identify
the owner of the key, should be syntactically of the form of domain-names
(which might be totally inappropriate for those other applications, though
it should clearly be required when the application is DKIM).

Does the version relate to the version of the algorithm identified by the
a= tag, or to the version of dkim-base as a whole? IOW, if someone invents
a new tag, or a new tag-value, that can be safely ignored by existing
implementations, is it necessary to invent a new version?

>    bh= The hash of the canonicalized body part of the message

Yes, I like this, since it enables some useful information to be recovered
if the header hash succeeds but the body hash fails.

>            INFORMATIVE IMPLEMENTATION WARNING:

I am very suspicious of the propriety of suggesting, in any IETF standard,
that it is legitimate to remove text from a message being conveyed
(certainly without the consent of the recipient). Surely marking it with
blood-red ink, or warnings in 32pt characters is as far as one should go?

sensible PKI that is workable for DKIM. But am I right in saying that this

Case-insensitive?

>        since 00:00:00 on January 1, 1970 in the UTC time zone. ...

Strictly speaking not true, since the usual UNIX algorithm for calculating
this quantity takes no account of leap seconds. I presume this is all laid
down in POSIX somewhere.

>    k=  Key type (plain-text; OPTIONAL, default is "rsa").  Signers and
>        verifiers MUST support the "rsa" key type.

Why MUST signers support the "rsa" key type (clearly, verifiers MUST)?
Surely a signer who, as a matter of policy, always chooses to use some
other key type is not obliged to implement something he is never going to
use?

> 3.7  Computing the Message Hashes

>    ....  The header field MUST be presented to
>    the hash algorithm after the body of the message ...

Does "The header field" mean 'The "DKIM-Signature" header field under
construction'?

> 4.  Semantics of Multiple Signatures

>    Signers should be cognizant that signing DKIM-Signature headers may
>    result in signature failures with intermediaries that do not
>    recognize that DKIM-Signatures are trace headers and unwittingly
>    reorder them.

This method of relying on the order of headers to distinguish between
multiple signatures seems far from robust. I would be happy to describe an
alternative and more reliable method, applicable at least to signing other
signatures, that I have in mind (but I promised to stick to questions for
now :-) ).

>    ...  For
>    example, a verifier that by policy chooses not to accept signatures
>    with deprecated cryptographic algorithms should consider such
>    signatures invalid.  As with messages with a single signature,
>    verifiers are at liberty to use the presence of valid signatures as
>    an input to local policy; ...

Where are "valid" and "invalid" defined, and is "invalid" synonymous with
"failed"? I would hope not, but it is not clear.

> 5.1  Determine if the Email Should be Signed and by Whom

>       INFORMATIVE IMPLEMENTER ADVICE:  SUBMISSION servers should not
>       sign Received header fields if the outgoing gateway MTA obfuscates
>       Received header fields, for example to hide the details of
>       internal topology.

I see several mentions of signing Received headers. Signing of any header
that may occur multiple times in a message is always risky (though I can
see a necessity for it in a few cases). Under what circumstances would
including a Received header within a signature provide a security benefit
(in the sense of countering some scam or threat) commensurate with this
risk?

> 5.3  Normalize the Message to Prevent Transport Conversions

I found this section absolutely astounding.

Message bodies written in Non-ASCII charsets have been commonplace now for
12 or more years, and they are most readily represented as 8-bit. 8BITMIME
has been around for the same length of time and is now almost universally
deployed. 8bit using 8BITMIME has become, or is well on the way to
becoming, the preferred CTE for charsets which will not fit into 7bits.
And yet you are now seriously proposing, for a protocol that needs to be
used in the great majority of future email messages if it is to fulfill
its purpose, to return to encodings that can be squashed into 7bits. That
is one monumental step backwards for the IETF.

Moreover, even as we speak, the ietf-eai WG, which is chartered to bring
in headers using UTF-8 and which can then nearly always be read and
understood by examination of the code as seen on the wire, is advocating
the universal use of 8BITMIME (and more) except when interfacing with
legacy systems which will, hopefully, have faded away by the time the next
12 years or so have elapsed.

And all this is entirely unnecessary. As I have already said, the
"meaning" of any email message is, by definition, independent of the CTE
with which it is transported. All you have to do is to arrange that the
canonicalization decodes any Quoted-Printable or Base64 that is
encountered, and uses the result of that in computing any hash. Was this
option considered and, if so, why was it rejected?

> 5.4  Determine the header fields to Sign

>    The From header field MUST be signed

Why is that? Again, even as we speak, the ietf-eai WG is planning to allow
the From header to be "downgraded" from internationalized to ASCII form
during transport. Whilst just how DKIM is to be incorporated into that
work is far from clear (there are suggestions, but much more investigation
is needed), it is clear that REQUIRING all From headers to be signed will
effectively close off one approach that might otherwise have worked.
"SHOULD be signed" would easily suffice and, in any case, where is the
interoperability that that "MUST" is supposed to prevent?

>       INFORMATIVE OPERATIONS NOTE:  The choice of which header fields to
>       sign is non-obvious.  One strategy is to sign all existing, non-
>       repeatable header fields.  An alternative strategy is to sign only
>       header fields that are likely to be displayed to or otherwise be
>       likely to affect the processing of the message at the receiver.  A
>       third strategy is to sign only "well known" headers.  Note that
>       verifiers may treat unsigned header fields with extreme
>       skepticism, including refusing to display them to the end user or
>       even ignore the signature if it does not cover certain header
>       fields.  For this reason signing fields present in the message
>       such as Date, Subject, Reply-To, Sender, and all MIME headers is
>       highly advised.

Surely the choice of fields to sign should be the minimum that will
provide protection against the scams and threats that you are trying to
combat? If omitting some particular fields opens the way to some known
malpractice, then sign it. If not, then the risk of breaking an otherwise
workable signature will outweigh any small gain in signing it "just in
case".

And is it not somewhat patronizing of the "end user" to refuse to let him
examine some part of a message directed at him? Is he not to be trusted to
make his own judgement on the matter? Suppose, for example, the signer had
omitted to sign the Reply-To (an unwise decision, but such will happen).
The end user will now be unable to reply to the message.

> 6.  Verifier Actions

Adding a header to indicate verification is a splendid idea, particularly
as it may then be signed by subsequent signers to confirm that it verified
OK at that point, even though changes to the message might subsequently
break that signature.

But, in that case, why have you not defined a Verified header, with the
possibility of giving a full report with a known syntax which can then be
used by the MUA to make the final decision, whether by the use of filters
or otherwise?

> 6.1  Extract Signatures from the Message

I had the greatest difficulty in understanding this section. I think,
after about an hour, I managed to work out what you were trying to say,
but noway could I reconcile that with what you had actually said.

>    A verifier SHOULD NOT treat a message that has one or more bad
>    signatures and no good signatures differently from a message with no
>    signature at all; such treatment is a matter of local policy and is
>    beyond the scope of this document.

that seems to be saying that bad signatures cannot be used as a basis for
rejecting messages under that "local policy" unless you plan to reject all
unsigned messages as well.

>    In the following description, text reading "return status
>    (explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL")
>    means that the verifier MUST immediately cease processing that
>    signature.  The verifier SHOULD proceed to the next signature, if any
>    is present, and completely ignore the bad signature.  ...

"MUST immediately cease processing that signature. ...SHOULD ... completely
ignore the bad signature." So I cannot even inform the "local policy" of  
the
failure I have discovered!

And I find it odd that a verifier may return "PERMFAIL" or "TEMPFAIL" for  
some
signature, but there seems to be no mention that it might return "SUCCESS".

I think you need to take a careful look at the wording of that whole
section.

>    ...  The
>    "(explanation)" is not normative text; it is provided solely for
>    clarification.

Why is that? How can a policy module make decisions on the information
returned by the verifier if it does not know the notation being used?

Now maybe you are going to tell me that the mode of communication between
the verifier and the policy module is not "on the wire", and therefore not
the business of any IETF standard. But that is clearly not so, because you
are suggesting that the information in question be bundled up in some
Verified header and passed to some other agent for action, quite possibly
over some "wire" carrying SMTP.

> 6.3  Interpret Results/Apply Local Policy

>    ...  However in terms of presentation to the end
>    user, the result SHOULD be presented as a simple binary result:
>    either the email is verified or it is not.  ...

Again, I detect a patronizing attitude to the end user. Are not users to
be trusted with the full truth, or are they to be treated as second class
citizens who should just "eat your greens because they are good for you,
and do not argue with your betters" :-) ?

> 7.  IANA Considerations

What is the procedure for amending these registers? Does it require a
standards track RFC, or will experimental or informational do? Or can
anyone request it provided a suitable reference is given?

> 8.1.1  Addition of new MIME parts to multipart/*

s/displaying MTA/displaying MUA/
{Sorry, I promised to stick to asking questions, but this one seemed an
obvious typo.}

> 8.2  Misappropriated Private Key

Could ssh-agent be of use to avoid repeated entry of a password without at
the same time leaving it lying around in some file?

> B.6 Third-party Message Transmission (may have been renumbered in  
> draft-06)

>    ...  A verifying MTA could accept this and
>    rewrite the From header field to indicate the address that was
>    verified, i.e., From:  John Doe via [email-masked]
>    <[email-masked]>.  ...

Again, I am very dubious about rewriting any From header. At the very
least, should not the original From be copied into a Reply-To, so that Joe
can write back to accept his 'evitation'?

Sorry to have gone on at such length. But some of these issues seem of
importance, so I hope someone will take the trouble to reply.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jon Callas <[email-masked]>
Date: Tue, 31 Oct 2006 01:26:57 -0800

On 30 Oct 2006, at 1:42 PM, Charles Lindsey wrote:

I'm going to cherry-pick a few things, particularly the ones I think  
I'm best suited to answer.

> MUST accept right from the start?

No, because we want DKIM to work with 7-bit-clean mail. We want  
broad, fast deployment and that means working with old systems.

> algorithm in the future, if someone makes out a good case for it.

As Eliot has noted, PGP isn't a signing algorithm. PGP is a signing  
protocol. Actually, to be even more correct, OpenPGP is a signing  
protocol. PGP is software.

Nonetheless, DKIM is specifically designed to be orthogonal to  
OpenPGP, S/MIME, or anything else. If you want to sign the content of  
a message, they're appropriate for it.

> not any headers? Unusual, but perhaps sensible for some  

Because you have to sign at least one header. Think of DKIM as a  
header-signing system. It signs the body, too, but that's a means to  
an end.

At the risk of using a postal metaphor (since email is surprisingly  
different beast from postal mail), DKIM is an integrity protocol for  
the envelope, not for the letter. Mechanically, it has to sign the  
body, but that's again, not the goal.

> Must this tag, if a <local-part> is present, be a valid working email

No, it can be anything you want. It's really a note from the signing  
domain to itself. Here's a scenario. You ring me up and tell me that  
one of my users is misbehaving in email. You show me the email. I use  
the i= to know whose knuckles to rap. But I may do so in a way that's  
completely opaque to you.

> blood-red ink, or warnings in 32pt characters is as far as one  

The point of body lengths is that many systems add text to the end of  
a message. In fact, the list server that is delivering this to you is  
doing precisely that.

If the signing server (callas.org) sends it to the mailing list  
(mipassoc.org) which then sends it to you, how do you know what the  
mailing list added? That is the length.

The length is the opposite of what you think it is. It is an explicit  
declaration by the responsible domain of what it is responsible for.  
If a spammer adds stuff at the end, it should be removed. It is  
saying that text that the author did not put there is not the  
author's text and thus may be removed. (I'm playing fast and loose a  
bit here, because it's not the author it's the author's exit mail  
server.)

> communicating parties, etc.)?

A couple of comments on this one.

DKIM is not a PKI. It has no trust model. It is a key-centric system.  
There's nothing wrong with embodying those keys in certificates or  
even gaffer tape, but that's not part of DKIM. However, yes, you are  
right, it doesn't preclude using anything else.

Second, PKIs are not distribution mechanisms. DNS is a distribution  
mechanism. Other possible mechanisms include LDAP, HTTP, FTP, Finger,  
Gopher, etc.

> method, is not obliged to implement something he is never going to  

Then they're not doing DKIM. If you're doing DKIM, you MUST do DNS.  
Conceivably, you might implement other mechanisms, too, but DNS is  
the one distribution mechanism everyone has to do.

> beyond 2038 would be helpful).

This is a definition. It has nothing to do with unix.

> sha-1 is not obliged to implement something he is never going to use?

It's for interoperability.

Here's what's going on there. SHA-1 is broken. It isn't so broken  
that we're going to demand that no one use it, but it's broken. We  
*want* you to use SHA-256. However, we are making a concession to  
people who have some need or desire to use SHA-1 and making sure it  
will all still work.

> other key type is not obliged to implement something he is never  

For interoperability. You have to have a key type that *everyone*  
implements. Note that in this standard like many others, mandatory-to- 
implement does not mean mandatory-to-use. It's perfectly fine for a  
user to decide that they're only ever going to use ECDSA, and never  
RSA. But the software that they use has to implement RSA because  
other people are.

> is one monumental step backwards for the IETF.

You're confusing making sure that 7-bit systems don't break with  
encouraging them. We're not encouraging them. But we're being  
realistic and want DKIM to work with existing systems.

> importance, so I hope someone will take the trouble to reply.

It's all right. Sorry for being a bit abrupt, but you need to catch  
up to what we're doing.

Go look at the web site at www.dkim.org, which will have a lot of  
things in it to help you get up to speed. Look at the DKIM WG charter  
at <http://www.ietf.org/html.charters/dkim-charter.html> which has  
pointers to the WG documents.

You especially should look at the DKIM threats RFC, RFC 4686. Also  
after that, look at the DKIM Service Overview. Those should help you  
understand a lot of the mechanism that's in DKIM-base.

	Jon