On Thu, 14 Jul 2005, Earl Hood wrote:
I was refering more to a CA-type system, so those that implement DKIM
can also be "certified" by a CA. DKIM does not directly provide
a trust model, so anyone who owns a domain can sign outgoing mail,
even mail considered spam.
Spam is variable term. As you probably can guess the purpose of this
group is not to find solution to spam but to develop system for
automaticly signing email messages in transit and spammers are more
then welcome to use it as well.
I'm not of aware of any security-related reasons to keep it all
in one field either.
Well, one obvious way to do it would be to use two fields with the same
name.
Preservation of order of same-named fields seems to be nearly universal.
Nice idea that takes advantage of how software generally deals
with duplicate non-trace fields.
Generally or always?
- For the "t=" tag, why not use ISO date/time format. For example:
20050714T045532
A reference to RFC 3339 would seem to be in order here.
The RFC definitely gives weight to use the format.
Note, Meta-Signatures has adopted a slight variant where the "T"
is dropped. Apparently, there is a desire to have the date to
be only an integer, but I am not clear on the full reasons for this.
First I'd like to note that in Content-Digest-Edigest the "t" is
an optional compoment that is simply specified as a number. That it
is recommended to be a timestamp is not part of normative spec.
The reason for doing it as a number though has to do with Saved fields.
Their ABNF is something like:
"Saved" [ "-" 1*(digit)] "-" original-header-field
Those digits are there to provide unique reference to Saved header field
if necessary and I want to make certain that "Saved" prefix with that
reference number can be uniquely identified from the actual original
header field and as part of that use that there are currently no header
fields which name consists entirely of numbers - but there are header
fields which include both numbers and digits in their name.
Going back to the date/time representation, the Saved field could be:
Saved-20050714045532-Sender: bob(_at_)example(_dot_)com
And I want to use field name both as unique id and way to identify when
it was added and way to link it to META-Signature header field. Edigest
fields can also optionally be identified as having been added by the
system adding some META-Signature field in the similar way.
The DKIM spec in the security section mentions private keys on a
per-user level. If this is the case, the authors envisioned a usage
model where the end-user (maybe via their MUA) signs the message.
This allows a end-user to have more control over the process and
delegates private key management from ISPs to end users: ISPs do not
have to maintain private keys for each of its customers (a costly
proposition) or rely on a shared signing private key for many users
(revocation difficulties).
Multi-user keys and signing is difficult and private key distribution
is indeed seems somethat that is rather difficult to implement on shared
MTA system.
There should be some way to indicate that a key has been revoked.
It seems right now, revocation is indirect, by removing the appropriate
DNS entry. However, a verifier does not know if the key was revoked,
temporarily unavailable, or never existed.
Of course, for DNS-based key publication, limits may be okay and
uncertainty of why a key is not present is acceptable. As noted by
Mr. Hallam-Baker, more complex key management systems can be hooked in.
(Note, the Meta Signatures draft covers what I am asking for in DKIM.)
META-Signatures is designed to be flexible with ability to easily add
multiple authorization methods and deploy them together. That point was
basis of all my work starting from MTA Signatures.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net