On August 5, 2005 at 00:26, "william(at)elan.net" wrote:
Perhaps as a diagnostic, a simple checksum of the body could
be placed within the signature to confirm the body has been altered
"l" field is also this kind of diagnostic tool. Actually that is exactly
what Content-Digest draft says in regards to its "s" parameter:
The l= tag is a major security problem if ever used for verification.
It must only be used for diagnostic purposes, or it should be dropped
entirely.
could be a reason the signature has failed. I like the idea of dropping th
e
body hash into the signature header, but this seems to demand two separate
signatures and this would be bad.
It does not demand separate signature. Properly it should be done with
separate header field (which is NOT same as separate signature field).
This is in fact good as for example when message is resigned this field
is reused and in such a way referenced by multiple signatures which saves
space in header and verifier system processing time.
Meta-Signatures does use a separate field to represent just the
hash of data. However, from a DKIM perspective, the hash could
be placed in the DKIM-Signature field (base64 encoded of course).
From a design perspective, I like the meta-signature approach of
making the digest/hash generation a separate component, allowing
for reusability for different applications. However, some may not
like the idea of a separate header (which has been discussed before)
for DKIM, so placing it in DKIM-Signature should be sufficient.
Normally DKIM does not confirm the local-part of an email address. DKIM
verifies a domain that could be compared against various mailbox-domains.
I think this is bad. I believe the system should specify exactly which
mailbox address field it is authorizing and furthermore the signing system
if it received message from authenticated user should indicate that (in
such a way while you do not have direct authentication of the email address,
you have indirect one from the signing system).
SSP has ties into user-based policies. These ties are essential if
spoofing is to be avoided, something that DKIM proposes to address.
--ewh