On July 15, 2005 at 04:51, "william(at)elan.net" wrote:
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).
There is a variation of quoted-printable used primarily with Subject
header field (mostly internationalization support), but its not the
same as what is introduced in dkim.
Your refering to non-ASCII encoded words as defined in RFC-2047.
I consider it a separate beast since it deals with non-ASCII
based character encodings for supporting non-English languages.
As I said before, I believe this all to be unnecessary and over complicating
the signature header. If you want to copy some other header field data -
then just go ahead and copy that field and include it in email with new
name being variation of old one (I chose Saved-).
Agreed.
If the digest will include the combination of header fields and
message body (or message body parts), a CRLF must be included
between each component during digest calculation.
I happen to not entirely agree. There is already CRLF at the end of
any header field, so adding extra CRLF seems unnecessary (although
this does exist in email message itself, but this is not email).
I maybe persuaded to change this position with good arguments.
The double CRLF sequence provides a clear separation for header
data from body data. For example, if the body started with:
Hello: World
It would appear to header data if only a single CRLF is used.
Plus any canonicalization processing is a lot less computationally intense
then actual cryptography.
Agreed.
- I find it odd that the header field that will contain the
signature (DKIM-Signature) must also be included in the
signing/verification process.
This has been discussed on this mail list briefly before and was fist
introduced in META-Signature specs (which originally did it on per-tag
basis where each such tag had to be opted-in to be included with "+="
instead of "="; latest spec is closer to DKIM where its done on
per-segment basis with all but 'sig' segment being included by default).
The reasons for including data from signature header itself is to make
it less useful for replay attacks, for example an attacker could take a
signature and replace some of its key parts (like change expiration,
change signer name and domain, etc) and then introduce it as his own.
By including key data tags, the range of replay attacks is reduced.
I am not saying that the information in DKIM-Signature should not be
part of the digest, just that the signature is in a separate field.
For example, the "DKIM-Spec" field (or whatever its name would be)
would be included in the digest computation to protect it from
unintentional or malicious modification.
It causes no change in the risk of replay attacks.
What I'm slightly concerned however is that DKIM says that all tags
are to be included (except 'b') but there maybe reasons to introduce
extensions as new tags with data that is not to be included so I think
opt-out option for unknown tags should be made available.
Do not see the reason, or more appropiately, the usefulness to support
such behavior. If extension tags are supported, they should be
part of the digest.
I am speculating that the rational to put everything in one field
is to make multiple DKIM-Signature fields possible without
the problem of knowing with signature applies to which DKIM-Spec
field. I think this problem is solvable.
With new fields introduced into email you never know if they could be in
some way repositioned by some "smart" (=stupid) software. I ended up using
"t" as unique identifier for multiple META field (0.18 and below spec) so
as to make it possible to reconstruct things if it goes bad.
I think header reordering is not too common, but it does it happen.
Ned suggested that if the field names are the same, header order
is preserved. I defer to his experience that this is a common
behavior.
However, if reordering is done even on same-named header fields,
it worth knowing how common it is, and if not common, it may
be an acceptable risk. It would also spur mail administrators
to upgrade old systems or developers to not do reordering in
their software.
- For greatest flexible, the digest should be separated out, and
it, along with meta-information is what is signed. Meta-Signatures
takes this approach.
Yes, separate content digest data makes signature system a lot more
flexible and allows signer better options to make certain his/her
content survives and is verifiable (or at least its key parts). This
also makes it possible to reference retrievable content data in the
appropriate way.
I view it from the flexbility of having different parties performing
different roles in the process. I.e. There are potential applications
of DKIM/Meta-Sig where the digest of the email message data is a
separate component that is included in the "Spec" field. Then, only
the "Spec" field is signed vs the email message data entirely. This
still protects the integrity of the message data along with clearly
defining the separate roles of the author and the signing agent.
For example, the author computes the digest and then hands it off
(along with "Spec" info) to the signing agent to create the signature.
This way, the signing agent does not need to know what the actual
content of the email message is (for privacy reasons).
The signing agent may be a service that is provided to multiple
users/customers, and the signing agent does not need to have a complete
copy of the email message to create the signature.
There is no procedure in RFC282[1/2] to introduce new trace fields so
basically any software that does not know about new trace fields will
treat them as regular unknown fields which is not the same as trace.
The procedure is to propose a new standard defining any new
trace fields and what their ordering restriction are :)
If you mean there is no way to indicate in a message header which
fields are trace fields, you are correct. Also, the restrictions
on the Received header field is described in RFC-2821 vs some
"markup" in the header indicating the restriction.
I also think that having "v" tag is better - after all we do have it
always as mime-version and nobody is complaining even though its mostly
still just "1.0". Almost every application I know includes version for
its data format even if that version is just "1.0".
I find it to be good practice to be explicit when possible. Implicit
can lead to more ambiguity and can make diagnosing problems more
difficult.
--ewh