Re: cryptographically verifiable fields
2004-01-18 13:40:38
That, and there is a semantic difference between a signed message and
a cryptographically verifiable trace field in a message.
Could somebody outline a process whereby a single field or group of
fields in a
message could be signed, with the following conditions:
1. the mechanism is robust w.r.t. common types of message munging
(reordered fields,
possible dropping of fields (obviously, let's assume that the field
that is signed isn't
dropped), addition of trailing whitespace, etc.)
- You only include specific fields in the hash, fields that are likely
to be maintained end-to-end.
- You hash the fields in a predetermined order.
- Before hashing each of those fields, you delete preceding and
trailing whitespace, and you replace all internal whitespace (including
CRLF-space) with a single space. you canonicalize the field-name (say,
all lower case letters).
- Some fields might have specific rules for canonicalization before
hashing. e.g. For fields containing addresses you would remove all
phrases and comments, leaving only the addresses; you would then
canonicalize each of the addresses (e.g. any local part that isn't a
quoted string would be enclosed in double quotes, contents of all local
parts would be lower-cased, all domains would be lower-cased; < and >
enclosing addresses would be removed); the resulting addresses would be
sorted; and any white space next to a special would be removed. (I'm
not sure yet whether I think address fields should be included in the
hash, but this is how you might do it if such fields were included)
I don't think it would be easy to work out the details; but I do
believe it's feasible.
A few systems would still mung headers to the point that the
originator-id verification would fail. The consequences would mostly
be these: For systems that munged outgoing mail, their recipients' mail
would not be verifiable. For systems munging incoming mail, their
recipients would not be able to verify originator-ids on mail that they
received or on mail that they forwarded to other systems. In either
case there would be an incentive to fix the implementations that munged
mail.
it might also be desirable to impose some constraints on messages that
are originated with an originator-id, such as limiting the permissible
variation on the format of address fields, date fields, etc.
Note again, the purpose isn't to prove that the sender sent the exact
message that the recipient received. The purpose is to make it
difficult for the sender to credibly say the "I didn't send anything
resembling that message" for large numbers of messages. A sender
should not be penalized for a small number of messages considered
offensive to recipients regardless of whether the sender claims that he
didn't send them.
2. the mechanism is not subject to replay attacks (e.g. copying the
signed field from one
message to another)
You include the message-id and/or the message body in the fields to be
hashed.
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: making mail traceable, (continued)
- Re: making mail traceable, James M Galvin
- some message bullet-proofing, Dave Crocker
- Re: making mail traceable, Keith Moore
- Re: making mail traceable, James M Galvin
- Re: making mail traceable, Keith Moore
- cryptographically verifiable fields, Bruce Lilly
- Re: cryptographically verifiable fields,
Keith Moore <=
- Re: cryptographically verifiable fields, Bruce Lilly
- Re: cryptographically verifiable fields, Charles Lindsey
- Re: cryptographically verifiable fields, James M Galvin
- Re: cryptographically verifiable fields, Bruce Lilly
- Re: cryptographically verifiable fields, James M Galvin
- Re: cryptographically verifiable fields, Bruce Lilly
- Re: cryptographically verifiable fields, Bruce Lilly
- Re: making mail traceable, James M Galvin
- Re: making mail traceable, Keith Moore
- Re: making mail traceable, Markus Stumpf
|
|
|