On July 14, 2005 at 16:39, Ned Freed wrote:
I'm not sure what form this "support for trusted third parties" would
take. My
major concern in this area isn't really a technical/specificaiton issue,
but
rather regarding the form an actual service using this specification would
take. In particular, one sort of trusted third party setup I definitely
want to see is one where service providers sign outgoing mail and verify
incoming mail.
Is this what you're asking for?
I think Mr. Hallam-Baker provided a good answer.
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.
Is there any reason that tag=value syntax does follow the
parameter=value
syntax defined in RFC-2045? I.e. Are implementors required to
implement another "tag" parsing scheme?
Indeed. We really don't need another of these if we can avoid it, but I'm
not
sure we can avoid it...
Due to political or technical reasons? :-)
It may also be worth noting why something like RFC-2184 was not
adopted.
I believe you meant RFC 2231.
You are correct. I did not realize 2184 got updated. I need
to go update my MIME page :-)
I'm dubious about it being appropriate to apply here. I think RFC 2231
goes too
far and is too difficult to implement.
I agree with the implementation comment. I've always been curious
of what softare actually supports it. I wrote Perl code years
ago to parse RFC-2184 parameter extensions, but never incorporated
it into anything since I have never seen its use in the wild.
Note, quoted-printable tends to have a bad (mostly undeserved)
reputation, so it may help to avoid using it, especially when its
use has never been applied to header data (at least to my knowledge).
A variant of QP is in fact used in RFC 2047 encoded words, so it has been
used
in headers before and has proved to be quite popular in that context.
Yep, but encoded words were mainly in the context of supporting
non-ASCII characters in headers. I think DKIM (according to this
draft) is using QP for characters in the ASCII range.
I do
note that it is a variant, not regular QP. Given that the RFC 2047
variant was
specifically designed for use in headers, a fair question would be why it
wasn't chosen for use here.
You touch upon the reason you co-authored RFC-2231. RFC-2047 does
not cover parameter value cases. Even though I have seen cases
where mail software will actually use 2047 encoded words in
a parameter value (e.g. filename parameter in Content-Disposition),
this is non-standard.
- I find it odd that the header field that will contain the
signature (DKIM-Signature) must also be included in the
signing/verification process.
I find it odd as well, but maybe there's a security-related reason for
it I'm not seeing.
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.
- 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.
- "z=" is a mess, and can eventually lead a DKIM field that is
longer than 988 octets (RFC-2822 limit).
...
Well, I like the implicatio nthat the sending MTA should do it. However,
exactly when that MTA should do it is going to be a tricky matter. I for
one am
mulling this one over big-time in considering how I'm going to implement
it.
I am not convinced (yet) that signing must be done at the border MTA.
I'm sorry, but I stop short of this. We need to look at the 95% case and
not
let ourselves get distracted by the allure of an all-inclusive perfect
scheme
that is so complex nobody can implement it.
I'm not sure there is really much more complexity. The only practical
"gotcha" is in the address re-write rule case that MTAs may perform,
which leads into the saved header concept.
Also, restricting things to the border MTA limits potential business
applications of DKIM (in the context of CA-type usage) and the power
dynamic of ISP and their customers.
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).
We need to face the facts of life here, and rewriting is one of those
facts.
I also don't think the complexity of saved headers is worth it, and that
means MUA-level signing is simply not going to work in many cases.
I think such a policy can cause a power-shift in the Internet. Now,
there are some practical things ISPs can do so MUA-based signing is
not a problem. For example, when a customer submits a message for
delivery (and it is signed), the ISP knows to not apply any re-write
rules or other modifications that can invalidate the signature.
For organizations that like to normalize all addresses
(e.g. earl(AT)machine.earlhood.com => earl(AT)earlhood.com),
they can implement policies for their users that signing is done
at the MTA level, or do other software configurations to miminze
re-writing.
I definitely see a day that if signing of email is a requirement
for message delivery, the signing process should not be in the
control of a few large, powerful entities.
Maybe my concerns are unwarrented, but I think we should still
entertain flexibility in when signing can be done until it is
definitive that some signing scenarios are too difficult, or costly,
to support.
- The need key revocation policies is implied here, which is
touched upon in Section 9.6. Key management is critical for
the system to be secure and trusted by users, therefore, it
definitely should be spelled out, potentially in a separate
specification.
I'm unsure that such facilites are really needed here, and would like to
hear more about the pros and cons.
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.)
--ewh