From: SM <sm...@re...> - 2004-07-26 22:45:10
|
Hello, The current version of DK inserts a signature at the outgoing border MTA and verifies the signature at the receiving MTA. If there is any MTA in between that inserts a header, the signature verification fails. What if only the following headers were signed: Received: (the first received inserted at the sending stage) Date: From: To: Subject: together with the message body. This would allow mail to be forwarded or to go through several MTAs before the signature is verified. The signature verification would still break with this mailing list for example as the message body is modified. The subject line may sometimes be modified by content filters or by mailing lists. I have included the subject line in the list of headers as it may contain meaningful information. The MTA at the receiving end can always verify the signature before performing any subject rewriting. MUAs unfortunately do not display the List-ID: to the user. I suggest using DK as a start to sign one-to-one communication where we can verify whether the "visible" information originated from the domain. My suggestion is similar to a post by Jose-Marcio to this list. In the above, the signature would not fail if headers are added. Regards, -sm |
From: Jim F. <jf...@bl...> - 2004-07-27 05:14:33
|
You're on the right track; to this list I would add the Sender header as it might be used to re-sign a message that goes through a mailing list. I'm concerned about the Received header though, since there are usually several and header ordering can't be guaranteed. Is it important to sign any of the Received headers at all? -Jim On Mon, 2004-07-26 at 15:44, SM wrote: > Hello, > > The current version of DK inserts a signature at the outgoing border MTA > and verifies the signature at the receiving MTA. If there is any MTA in > between that inserts a header, the signature verification fails. > > What if only the following headers were signed: > > Received: (the first received inserted at the sending stage) > Date: > From: > To: > Subject: > > together with the message body. This would allow mail to be forwarded or > to go through several MTAs before the signature is verified. The signature > verification would still break with this mailing list for example as the > message body is modified. > > The subject line may sometimes be modified by content filters or by mailing > lists. I have included the subject line in the list of headers as it may > contain meaningful information. The MTA at the receiving end can always > verify the signature before performing any subject rewriting. > > MUAs unfortunately do not display the List-ID: to the user. I suggest > using DK as a start to sign one-to-one communication where we can verify > whether the "visible" information originated from the domain. > > My suggestion is similar to a post by Jose-Marcio to this list. In the > above, the signature would not fail if headers are added. > > Regards, > -sm > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > dk-milter-discuss mailing list > dk-...@li... > https://lists.sourceforge.net/lists/listinfo/dk-milter-discuss |
From: SM <sm...@re...> - 2004-07-27 18:04:45
|
Hi Jim, At 22:14 26-07-2004, Jim Fenton wrote: >You're on the right track; to this list I would add the Sender header as >it might be used to re-sign a message that goes through a mailing list. Should we say the Sender header where sender is Return-path? Mailing lists should resign a message before sending a message if we include that field. As I see it, the Return-path may be changes with rewrites. >I'm concerned about the Received header though, since there are usually >several and header ordering can't be guaranteed. Is it important to >sign any of the Received headers at all? I included the first received so that the message can be tracked at the sender's end. If this makes the task of signing more complicated, then I suggest leaving out Received headers altogether. Regards, -sm |
From: Murray S. K. <ms...@se...> - 2004-07-27 06:21:50
|
On Mon, 26 Jul 2004, SM wrote: > The current version of DK inserts a signature at the outgoing border MTA > and verifies the signature at the receiving MTA. If there is any MTA in > between that inserts a header, the signature verification fails. > > What if only the following headers were signed: > > Received: (the first received inserted at the sending stage) > Date: > From: > To: > Subject: > > together with the message body. This would allow mail to be forwarded or > to go through several MTAs before the signature is verified. The signature > verification would still break with this mailing list for example as the > message body is modified. > [...] dk-milter 0.1.15 has a canonicalization method that enumerates which headers were included in the canonicalization. Order of headers is recorded, so canonicalization is symmetric on both sides even if the signed headers get reordered or headers get appended. The method is called "headerlist" and is based on discussions going on on the "dsig" mailing list. We're discussing some revisions to it, but it's pretty close to where we appear to be converging on the list. Some of the discussion at the moment involves whether or not Bcc: should be included since it can be altered or even removed enroute, and whether or not either From: or Sender: should be a required header. The first Received: header may not be available, so I'm not sure it would be possible to include it. No canonicalization can really deal with modifications to the body. S/MIME has the same problems with MLMs that tack on headers and footers without doing proper MIME wrapping. |
From: Jose M. M. da C. <Jos...@en...> - 2004-07-27 08:23:56
|
Murray S. Kucherawy wrote: > On Mon, 26 Jul 2004, SM wrote: > > dk-milter 0.1.15 has a canonicalization method that enumerates which > headers were included in the canonicalization. Order of headers is > recorded, so canonicalization is symmetric on both sides even if the > signed headers get reordered or headers get appended. The method is > called "headerlist" and is based on discussions going on on the "dsig" > mailing list. We're discussing some revisions to it, but it's pretty > close to where we appear to be converging on the list. > > Some of the discussion at the moment involves whether or not Bcc: should > be included since it can be altered or even removed enroute, and whether > or not either From: or Sender: should be a required header. .. > > No canonicalization can really deal with modifications to the body. > S/MIME has the same problems with MLMs that tack on headers and footers > without doing proper MIME wrapping. I agree. If DomainKeys is accepted as a standard or become an RFC, other packages shall be aware of that. So, if some network node changes the body or some header included on the body, signature is broken and shall be resigned. DomainKeys have a big advantage over S/MIME as DomainKeys also sign some headers. Signing the headers prevents replaying the message and repudiation, as From header is included. You can't have the best of all worlds without imposing some restriction on how message is handled by all intermediate MTAs, MLMs, MUAs... I think we're on the right way. But maybe some thing which could be included is the signature timestamp. But this should be included in a header in the canonicalization process (before signing) to avoid being modified. This is interesting, but not absolutely necessary. -- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ Tel. :(33) 01.40.51.93.41 Ecole des Mines de Paris http://j-chkmail.ensmp.fr 60, bd Saint Michel http://www.ensmp.fr/~martins 75272 - PARIS CEDEX 06 mailto:Jos...@en... |
From: SM <sm...@re...> - 2004-07-27 19:28:44
|
Hi Jose Marcio, At 01:23 27-07-2004, Jose Marcio Martins da Cruz wrote: >DomainKeys have a big advantage over S/MIME as DomainKeys also sign some >headers. Signing the headers prevents replaying the message and >repudiation, as From header is included. As I mentioned before, it would be good if we could ensure that the visible headers are genuine. The MAIL FROM: is not as important as the From: headers from a recipient's point of view. The average user "trusts" what he/she sees in the MUA and assumes that the From: is the sender of the message. >You can't have the best of all worlds without imposing some restriction on >how message is handled by all intermediate MTAs, MLMs, MUAs... The only restriction is that the intermediate stages should leave that headerlist and the message body unchanged. They can add Received: headers and X- headers without affecting the signature verification. >But maybe some thing which could be included is the signature timestamp. >But this should be included in a header in the canonicalization process >(before signing) to avoid being modified. This is interesting, but not >absolutely necessary. There is already the Date: header. If the time is incorrect, blame the sender. :) I think that it is best to keep the headers as lean as possible. Regards, -sm |
From: SM <sm...@re...> - 2004-07-27 19:10:21
|
Hi Murray, At 23:21 26-07-2004, Murray S. Kucherawy wrote: >dk-milter 0.1.15 has a canonicalization method that enumerates which >headers were included in the canonicalization. Order of headers is >recorded, so canonicalization is symmetric on both sides even if the >signed headers get reordered or headers get appended. The method is >called "headerlist" and is based on discussions going on on the "dsig" >mailing list. We're discussing some revisions to it, but it's pretty >close to where we appear to be converging on the list. I don't see any reason to record the order of the headers. If there is an agreement about the order of the headers, then we can assume that the headers will be signed and verified in the same order. >Some of the discussion at the moment involves whether or not Bcc: should >be included since it can be altered or even removed enroute, and whether >or not either From: or Sender: should be a required header. Bcc: may be removed. That header is not meaningful as the receiver will not see the email addresses which were Bcced. I commented on Sender in my previous email. >The first Received: header may not be available, so I'm not sure it would >be possible to include it. Then it is better to ignore the Received lines altogether. >No canonicalization can really deal with modifications to the body. >S/MIME has the same problems with MLMs that tack on headers and footers >without doing proper MIME wrapping. If a MLM adds footers, then it should sign the message. The aim of the signature change I suggested is to verify that the visible header information and the body was not altered in between the sending and receiving MTAs. Regards, -sm |
From: Murray S. K. <ms...@se...> - 2004-07-27 19:49:35
|
On Tue, 27 Jul 2004, SM wrote: > I don't see any reason to record the order of the headers. If there is > an agreement about the order of the headers, then we can assume that the > headers will be signed and verified in the same order. What if they get reordered? How does the verifying end know what order to use? |
From: SM <sm...@re...> - 2004-07-27 20:08:46
|
Hi Murray, At 12:49 27-07-2004, Murray S. Kucherawy wrote: >What if they get reordered? How does the verifying end know what order to >use? If there is a standard for the order in which the headers are signed, then the verifying end already knows in which order to use the headers. I forgot to mention the case where there a header occurs more than once. The sending side should consider the message as incorrectly formatted. On the receiving side, it should be considered as incorrectly formatted too if the "error" is detected at that end. The aim is to avoid fixing broken stuff. We don't know which From: header the MUA will display if there are more than one. Regards, -sm |
From: Murray S. K. <ms...@se...> - 2004-07-27 20:17:30
|
On Tue, 27 Jul 2004, SM wrote: > Hi Murray, > At 12:49 27-07-2004, Murray S. Kucherawy wrote: > >What if they get reordered? How does the verifying end know what order to > >use? > > If there is a standard for the order in which the headers are signed, then > the verifying end already knows in which order to use the headers. That's certainly one approach. Is there a reason to do it that way rather than just list the order that was used by the signing side? Another possible approach is to sort the headers alphabetically with order otherwise preserved. Then the order in which they're represented in the h= portion of the signature header doesn't matter other than to indicate which headers should be included (and thus which were added later). > I forgot to mention the case where there a header occurs more than once. > The sending side should consider the message as incorrectly formatted. > On the receiving side, it should be considered as incorrectly formatted > too if the "error" is detected at that end. The aim is to avoid fixing > broken stuff. We don't know which From: header the MUA will display if > there are more than one. MARID decided that such a message (one with multiple From: headers) cannot be validated, and that fact should be reported back to the agent doing the validation. We could certainly make the same call. The implementation of "headerlist" deals with multiple instances by canonicalizing them all together. So for example if you got h=received:from:to:subject:date, with an input order below DomainKey-Signature: of: Received: Date: Received: From: Subject: To: List-Id: Sender: ...they would be canonicalized on both ends as: Received: Received: From: To: Subject: Date: The other headers would be excluded. |
From: Jose M. M. da C. <Jos...@en...> - 2004-07-27 20:38:21
|
Murray S. Kucherawy wrote: >On Tue, 27 Jul 2004, SM wrote: > ... >>If there is a standard for the order in which the headers are signed, then >>the verifying end already knows in which order to use the headers. >> I don't know about a standard on this. But when you read what other people say in other groups (ASRG, e.g.), sometimes you may think that there are many people thinking that the best way to add new headers to a message is at beginning. If necessary, for the user confort, MUAs may reorder them before visually present them to the user. > > > >>I forgot to mention the case where there a header occurs more than once. >>The sending side should consider the message as incorrectly formatted. >>On the receiving side, it should be considered as incorrectly formatted >>too if the "error" is detected at that end. The aim is to avoid fixing >>broken stuff. We don't know which From: header the MUA will display if >>there are more than one. >> RFC 2822 says there shall be ONE and ONLY ONE - not ZERO - From headers. So, messages without From or with multiple From headers don't conform to RFC 2822. That's the same for "To", "Date" and some other headers... -- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ Tel. :(33) 01.40.51.93.41 Ecole des Mines de Paris http://j-chkmail.ensmp.fr 60, bd Saint Michel http://www.ensmp.fr/~martins 75272 - PARIS CEDEX 06 mailto:Jos...@en... |
From: Murray S. K. <ms...@se...> - 2004-07-27 20:40:54
|
On Tue, 27 Jul 2004, Jose Marcio Martins da Cruz wrote: > RFC 2822 says there shall be ONE and ONLY ONE - not ZERO - From headers. > So, messages without From or with multiple From headers don't conform to > RFC 2822. > > That's the same for "To", "Date" and some other headers... That doesn't mean we won't see them, unfortunately. The question then is: Do we sign the first one? The last one? A random one? Not sign at all? Some will argue we should try to do the "right" thing, whatever that may be. Others will argue that we should try to do the "safe" thing and not sign the message. |
From: Jose M. M. da C. <Jos...@en...> - 2004-07-27 21:15:27
|
Murray S. Kucherawy wrote: >On Tue, 27 Jul 2004, Jose Marcio Martins da Cruz wrote: > > >>RFC 2822 says there shall be ONE and ONLY ONE - not ZERO - From headers. >>So, messages without From or with multiple From headers don't conform to >>RFC 2822. >> >>That's the same for "To", "Date" and some other headers... >> >> > >That doesn't mean we won't see them, unfortunately. The question then is: >Do we sign the first one? The last one? A random one? Not sign at all? > >Some will argue we should try to do the "right" thing, whatever that may >be. Others will argue that we should try to do the "safe" thing and not >sign the message. > When somebody write some lines of code of the kind (e.g.) : char *c; if (c > 0) *c = 150; and ask you to put your name on it as co-author, what do you do ? What I'm trying to say is the following : Some RFC says you shall be strict on what you send, but very receptive on what you receive. This may work for many things, but this shall not be a general rule on some security issues. So, if the message is wrongly composed, don't sign it. -- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ Tel. :(33) 01.40.51.93.41 Ecole des Mines de Paris http://j-chkmail.ensmp.fr 60, bd Saint Michel http://www.ensmp.fr/~martins 75272 - PARIS CEDEX 06 mailto:Jos...@en... |
From: Murray S. K. <ms...@se...> - 2004-07-27 21:47:52
|
On Tue, 27 Jul 2004, Jose Marcio Martins da Cruz wrote: > Some RFC says you shall be strict on what you send, but very receptive > on what you receive. This may work for many things, but this shall not > be a general rule on some security issues. > > So, if the message is wrongly composed, don't sign it. You might want to open a bug or RFE about this then, because right now I sign on the first From: header, and do not check to see whether or not there are additional ones present. If there are other headers that should be unique, you should mention them too although they probably matter a lot less than From: and Sender: do since they'll be carried through to the destination. What gets presented to the user in that case won't matter with or without the signature. However, From: and Sender: govern which domain is queried for the public keys, so they're more critical. |
From: SM <sm...@re...> - 2004-07-28 04:50:17
|
Hi Jose Marcio, At 14:10 27-07-2004, Jose Marcio Martins da Cruz wrote: >When somebody write some lines of code of the kind (e.g.) : > > char *c; > if (c > 0) > *c = 150; > >and ask you to put your name on it as co-author, what do you do ? I get a baseball bat. :) >What I'm trying to say is the following : > >Some RFC says you shall be strict on what you send, but very receptive >on what you receive. This may work for many things, but this shall not >be a general rule on some security issues. > >So, if the message is wrongly composed, don't sign it. Nowadays, people are very receptive to what they send and strict on what they accept. It is better to be strict at both ends to reduce security issues. Regards, -sm |
From: Jose M. M. da C. <Jos...@en...> - 2004-07-28 07:40:26
|
Hi, SM wrote: > Hi Jose Marcio, > At 14:10 27-07-2004, Jose Marcio Martins da Cruz wrote: ... > > Nowadays, people are very receptive to what they send and strict on what > they accept. It is better to be strict at both ends to reduce security > issues. This serious 8-) Not really ! People are very receptive on what they send, as *they know*, people on the other side SHALL (as defined by RFCs) be very receptive on what they receives. And this is the reason form many security issues on Internet, including SPAM and viruses. That's why I think, DomainKeys shall be as strict as he can, on what he signs. Regards, Best, Joe > > Regards, > -sm > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > dk-milter-discuss mailing list > dk-...@li... > https://lists.sourceforge.net/lists/listinfo/dk-milter-discuss > > -- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ Tel. :(33) 01.40.51.93.41 Ecole des Mines de Paris http://j-chkmail.ensmp.fr 60, bd Saint Michel http://www.ensmp.fr/~martins 75272 - PARIS CEDEX 06 mailto:Jos...@en... |
From: SM <sm...@re...> - 2004-07-28 04:50:08
|
Hi Murray, At 13:40 27-07-2004, Murray S. Kucherawy wrote: >That doesn't mean we won't see them, unfortunately. The question then is: >Do we sign the first one? The last one? A random one? Not sign at all? I prefer not at all. >Some will argue we should try to do the "right" thing, whatever that may >be. Others will argue that we should try to do the "safe" thing and not >sign the message. I prefer to err on the safe side. To put the question in context, what From: header is displayed in MUA? Will it be the first one or the last one? We cannot tell as there are so many MUAs with different implementations. Let's not leave a gap for more social engineering. Regards, -sm |
From: SM <sm...@re...> - 2004-07-28 04:50:07
|
Hi Jose Marcio, At 13:33 27-07-2004, Jose Marcio Martins da Cruz wrote: >I don't know about a standard on this. But when you read what other people >say in other groups (ASRG, e.g.), sometimes you may think that there are >many people thinking that the best way to add new headers to a message is >at beginning. We only need a standard to determine how to process the header at the verification stage and what headers who be taken into account. >If necessary, for the user confort, MUAs may reorder them before visually >present them to the user. Yes and if we have a standard, that will not cause any problems for verification. >RFC 2822 says there shall be ONE and ONLY ONE - not ZERO - From headers. >So, messages without From or with multiple From headers don't conform to >RFC 2822. > >That's the same for "To", "Date" and some other headers... And as such they should not be signed by DK. :) Regards, -sm |
From: Graham M. <gr...@we...> - 2004-07-28 06:57:00
|
SM <sm...@re...> writes: > Then it is better to ignore the Received lines altogether. I have found another reason to ignore (or at least handle differently) Received lines. When sending a mail from 'localhost' the mail first goes to the MSA and then to the 'normal' sendmail. When signing the Received header generated by the MSA is included, but when verifying the Received header between the MSA and the 'normal' Sendmail is also included in the process - which makes it fail. Here is an example (snipped after the Received lines) from outputs when DKDEBUG=c. [Sender] Received:(fromgraham@localhost) byhome.gmurray.org.uk(8.13.0/8.13.0/Submit)idi6RJtYEL013123; Tue,27Jul200420:55:34+0100 X-Authentication-Warning:home.gmurray.org.uk:gra...@gm...using-f [Receiver] Received:fromhome.gmurray.org.uk(graham@localhost[127.0.0.1]) byhome.gmurray.org.uk(8.13.0/8.13.0)withESMTPidi6RJtYwh013124 (version=TLSv1/SSLv3cipher=DHE-RSA-AES256-SHAbits=256verify=NO) for<gr...@we...>;Tue,27Jul200420:55:36+0100 Received:(fromgraham@localhost) byhome.gmurray.org.uk(8.13.0/8.13.0/Submit)idi6RJtYEL013123; Tue,27Jul200420:55:34+0100 X-Authentication-Warning:home.gmurray.org.uk:gra...@gm...using-f |
From: Jose M. M. da C. <Jos...@en...> - 2004-07-27 20:29:29
|
Hi SM, SM wrote: > Hi Jose Marcio, ... >> But maybe some thing which could be included is the signature timestamp. >> But this should be included in a header in the canonicalization process >> (before signing) to avoid being modified. This is interesting, but >> not absolutely necessary. > > > There is already the Date: header. If the time is incorrect, blame > the sender. :) I think that it is best to keep the headers as lean as > possible. Yes, but I'm talking about the moment the message was signed. When you endorse some paper wroten by some one other than you, you usually sign it and write the date you signed it. Am I wrong ? Joe -- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ Tel. :(33) 01.40.51.93.41 Ecole des Mines de Paris http://j-chkmail.ensmp.fr 60, bd Saint Michel http://www.ensmp.fr/~martins 75272 - PARIS CEDEX 06 mailto:Jos...@en... |
From: Murray S. K. <ms...@se...> - 2004-07-27 20:32:56
|
On Tue, 27 Jul 2004, Jose Marcio Martins da Cruz wrote: > > There is already the Date: header. If the time is incorrect, blame > > the sender. :) I think that it is best to keep the headers as lean as > > possible. > > Yes, but I'm talking about the moment the message was signed. When you > endorse some paper wroten by some one other than you, you usually sign > it and write the date you signed it. Am I wrong ? Is that really meaningful though? What if clocks are out-of-sync? Or is the point here to just inject some random data into the data set being signed? |
From: SM <sm...@re...> - 2004-07-28 04:25:45
|
Hi Jose Marcio, At 13:24 27-07-2004, Jose Marcio Martins da Cruz wrote: >Yes, but I'm talking about the moment the message was signed. When you >endorse some paper wroten by some one other than you, you usually sign it >and write the date you signed it. Am I wrong ? You are not endorsing a paper here. You are only adding a key to validate whether the email from the domain listed in the From: header can be trusted as coming from a MTA for that domain. If you want to track the time, you can always refer to the Received: header. However, that timestamp may be inaccurate if the clock of the sending MTA is not in sync. If we use the endorsement analogy, then we also have to authenticate the username part of the email address. Do we want to get into that too? :) Regards, -sm |
From: Jose M. M. da C. <Jos...@en...> - 2004-07-27 20:48:09
|
Murray S. Kucherawy wrote: >On Tue, 27 Jul 2004, Jose Marcio Martins da Cruz wrote: > > >>>There is already the Date: header. If the time is incorrect, blame >>>the sender. :) I think that it is best to keep the headers as lean as >>>possible. >>> >>> >>Yes, but I'm talking about the moment the message was signed. When you >>endorse some paper wroten by some one other than you, you usually sign >>it and write the date you signed it. Am I wrong ? >> >> > >Is that really meaningful though? What if clocks are out-of-sync? > I was comparing this with real life. Clocks out-of-sync... We shall suppose that some day at least MTAs will be on phase... >Or is the point here to just inject some random data into the data set >being signed? > No, in real life this happens. Surely, as you told some time before, we can't really trust on signing MTAs, but surely more trust can be put on some data written by the signer than the original sender. Signature date has surely more value than some other headers, like Received from and even the original Date header. So, this may be more valuable to detect incoherences. I read some posts on the filtering sub group from ASRG about the date to be put on some wanted "Filtered-by" header, but I surely don't remember what they said. At those days I hadn't enough time to read all posts. For people who don't followed discussion on that group, their goal is to write a draft about this header. Best Jose-Marcio Jose-Marcio -- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ Tel. :(33) 01.40.51.93.41 Ecole des Mines de Paris http://j-chkmail.ensmp.fr 60, bd Saint Michel http://www.ensmp.fr/~martins 75272 - PARIS CEDEX 06 mailto:Jos...@en... |
From: SM <sm...@re...> - 2004-07-28 04:50:10
|
Hi Jose Marcio, At 13:43 27-07-2004, Jose Marcio Martins da Cruz wrote: >I was comparing this with real life. Clocks out-of-sync... We shall >suppose that some day at least MTAs will be on phase... This is wishful thinking. :) >Surely, as you told some time before, we can't really trust on signing >MTAs, but surely more trust can be put on some data written by the signer >than the original sender. We trust the signing MTA for the domain it signs for. This does not mean that we trust the domain. The signer is responsible for original sender. Do we want to trust more than the domain? No, because there is no way to ensure that the timestamp is correct. >Signature date has surely more value than some other headers, like >Received from and even the original Date header. So, this may be more >valuable to detect incoherences. Why not put more value in the Date: header then as that is what the recipient sees? Regards, -sm |
From: SM <sm...@re...> - 2004-07-28 03:50:15
|
Hi Murray, At 13:17 27-07-2004, Murray S. Kucherawy wrote: >That's certainly one approach. Is there a reason to do it that way rather >than just list the order that was used by the signing side? Headers are becoming unreadable with all the X- and other headers being inserted in an email nowadays. Listing the headers also means more parsing. That can be avoided by having a "standard" for ordering the list. >Another possible approach is to sort the headers alphabetically with order >otherwise preserved. Then the order in which they're represented in the >h= portion of the signature header doesn't matter other than to indicate >which headers should be included (and thus which were added later). My suggestion is not even to have the h= portion which lists the headers used for signing. A set of ordered headers is defined at implementation. >MARID decided that such a message (one with multiple From: headers) cannot >be validated, and that fact should be reported back to the agent doing the >validation. We could certainly make the same call. The same should be applied to the other headers used for signing. If there is more than one, then tell the agent that validation cannot be performed on that message. >The implementation of "headerlist" deals with multiple instances by >canonicalizing them all together. So for example if you got >h=received:from:to:subject:date, with an input order below >DomainKey-Signature: of: > > Received: > Date: > Received: > From: > Subject: > To: > List-Id: > Sender: > >...they would be canonicalized on both ends as: > > Received: > Received: > From: > To: > Subject: > Date: > >The other headers would be excluded. If we have a c=std for example, then the above header example would be canonicalized as: Date: From: Subject: To: Regards, -sm |