Re: [ietf-dkim] Eat all CR/LF - STRIP Canonicalization Method

2006-07-24 Thread Mark Delany
On Tue, Jul 25, 2006 at 01:02:05AM -0400, Hector Santos allegedly wrote: > > For example: > > > > --pWyiEgJYm5f9v55/ > > Content-Type: image/jpeg > > Content-Transfer-Encoding: base64 > > > > can get turned into this: > > > > --pWyiEgJYm5f9v55/ > > Content-Type: image/jpegContent-Transfer-Encoding:

RE: [ietf-dkim] The URL to my paper describing the DKIM policy options

2006-07-24 Thread Patrick Peterson
> - Original Message - > From: "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> > To: "IETF-DKIM" > Sent: Wednesday, July 12, 2006 2:05 PM > Subject: [ietf-dkim] The URL to my paper describing the DKIM > policy options > > > I submitted the draft in both pdf and txt. Only the txt is > shown

Re: [ietf-dkim] Eat all CR/LF - STRIP Canonicalization Method

2006-07-24 Thread Hector Santos
- Original Message - From: "Mark Delany" <[EMAIL PROTECTED]> To: Sent: Monday, July 24, 2006 11:36 PM Subject: Re: [ietf-dkim] Eat all CR/LF - STRIP Canonicalization Method > Well, one of the earlier DKIM nofws variants was nixed because it had > something similar. One of the concerns

Re: [ietf-dkim] Eat all CR/LF - STRIP Canonicalization Method

2006-07-24 Thread Mark Delany
On Mon, Jul 24, 2006 at 10:21:51PM -0400, Hector Santos allegedly wrote: > > - Original Message - > From: "Stephen Farrell" <[EMAIL PROTECTED]> > To: "Hector Santos" <[EMAIL PROTECTED]> > > >> This can produce an interesting result with the DKIM signature > >> calculated as valid but with

[ietf-dkim] Eat all CR/LF - STRIP Canonicalization Method

2006-07-24 Thread Hector Santos
- Original Message - From: "Stephen Farrell" <[EMAIL PROTECTED]> To: "Hector Santos" <[EMAIL PROTECTED]> >> This can produce an interesting result with the DKIM signature >> calculated as valid but with feedback that the originality of >> the message has change. > > Given our current defi

Re: [ietf-dkim] 822/2822 or just 2822

2006-07-24 Thread Hector Santos
- Original Message - From: "Stephen Farrell" <[EMAIL PROTECTED]> To: "Hector Santos" <[EMAIL PROTECTED]> > Hi Hector, > > Not that I follow this entire thread (anyone like to summarise?) >From my perspective, I can summarized it as a debate on the essential question: Does the System

Re: [ietf-dkim] Document Action: 'Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)' to Informational RFC

2006-07-24 Thread Stephen Farrell
Dave Crocker wrote: The IESG wrote: The IESG has approved the following document: - 'Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) ' as an Informational RFC This document is the product of the Domain Keys Identified Mail Working Group. yay! Indeed. Well done to a

Re: [ietf-dkim] Document Action: 'Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)' to Informational RFC

2006-07-24 Thread Dave Crocker
The IESG wrote: > The IESG has approved the following document: > > - 'Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) ' > as an Informational RFC > > This document is the product of the Domain Keys Identified Mail Working > Group. yay! d/ -- Dave Crocker Branden

[ietf-dkim] Document Action: 'Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)' to Informational RFC

2006-07-24 Thread The IESG
The IESG has approved the following document: - 'Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) ' as an Informational RFC This document is the product of the Domain Keys Identified Mail Working Group. The IESG contact persons are Russ Housley and Sam Hartman. A URL of thi

Re: [ietf-dkim] 822/2822 or just 2822

2006-07-24 Thread John Levine
>I also think that the putative "eat all CR/LF" c14n might be >hard to get approved, given the obvious vulnerabilities it'd >create. It's come up before, and did not get any traction. In the spirit of rough consensus and running code, it seems to me that people who want a new c14n scheme should i

Re: [ietf-dkim] 822/2822 or just 2822

2006-07-24 Thread ned+dkim
> On Sun, 2006-07-23 at 11:53 -0700, [EMAIL PROTECTED] wrote: > > > > My view is that DKIM is designed to provide a boundary service between > > administrative domains. (I suppose we could up with a different term > > than administative domain here, but since the two will align more > > often than

Re: [ietf-dkim] 822/2822 or just 2822

2006-07-24 Thread Hector Santos
- Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: Sent: Monday, July 24, 2006 9:07 AM Subject: RE: [ietf-dkim] 822/2822 or just 2822 > On the face of this it looks like a third party is molesting the message > after signing but before delive

Re: [ietf-dkim] 822/2822 or just 2822

2006-07-24 Thread Hector Santos
- Original Message - From: "Douglas Otis" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> > Striving to allow the message to be verified at the MUA increases the > possible success of DKIM in offering the desired assurance. While there > may be problems in some cases, many of these cases cou

Re: [ietf-dkim] 822/2822 or just 2822

2006-07-24 Thread Stephen Farrell
Hi Hector, Not that I follow this entire thread (anyone like to summarise?) but just on this point: Hector Santos wrote: Question: If it not possible to have a complete stripping of the CR/LF for hashing purposes? That would address this particular mixed bag EOL issue for both the signer an

Re: [ietf-dkim] 822/2822 or just 2822

2006-07-24 Thread Eliot Lear
Douglas Otis wrote: > On Sun, 2006-07-23 at 11:53 -0700, [EMAIL PROTECTED] wrote: > > Striving to allow the message to be verified at the MUA increases the > possible success of DKIM in offering the desired assurance. While there > may be problems in some cases, many of these cases could be avo

Re: [ietf-dkim] 822/2822 or just 2822

2006-07-24 Thread Douglas Otis
On Sun, 2006-07-23 at 11:53 -0700, [EMAIL PROTECTED] wrote: > > My view is that DKIM is designed to provide a boundary service between > administrative domains. (I suppose we could up with a different term > than administative domain here, but since the two will align more > often than not I prefer

RE: [ietf-dkim] 822/2822 or just 2822

2006-07-24 Thread Bill.Oxley
On the face of this it looks like a third party is molesting the message after signing but before delivery. If the third party does not currently do DKIM then the signature will result in failure. If the third party is DKIM aware then it could verify the signature, make needed changes then re-sign