On Wed, Mar 17, 1999 at 11:54:40AM -0500,
Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
I know in mail the Received header gets simply done multiple times. Is
there any feeling each way?
Definitely the latter.
There is no need to "sign" a "signed" header. Can you tell me why you
would want to do this? A "signed" header (and any certificate) is
verifiable on its own when paired with the signed headers and body. I
I'm in the office, and my copy of Schneieder's "Applied Cruptography" is
at home, but I do seem to recall there being a discussion of signing of
signatures being important for notary services and non-repudiation schemes.
Basically, you're signing with *your* key, and your key has some sort
of chain of trust attached to it so the recipient can verify it was indeed
your key. However, for timestamping services and the like, you need to
get a *second* trusted signature to verify that it was, in fact, done
at the actual time it claims, and so on.
No, the standard proposed a complex mechanism of self-signing parts of
the signed header (a canonicalized expansion of the header list, and
all the other parts except the signature)
This turns out to be not needed. You don't have to sign any relevant
part of the Signed header yourself, since any attempt to modify it will
invalidate the signature. Unless you have things like comments in the
header, which could be modified without invalidating. However, the ability
to protect comments is not worth the complexity of self-signing.
I strongly advocate a much much simpler canonicalization algorithm along
the lines I outlined. Take the header list, canonicalize only the
FWS, sort, and concat to hash.
You are referring above to having a certificate, which is where
somebody *else* signs your key and attributes about your key, and that is
of course important.