ietf-822
[Top] [All Lists]

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.