Re: [ietf-dkim] z= question with X headers

You can not avoid such ambiguities unless you can specifically reference the copied data as part of signed header field listing. That is why I went with copying to make new header field and referencing that in my design. On Thu, 27 Apr 2006, Tony Hansen wrote: I also read it the same way Arv

Re: [ietf-dkim] z= question with X headers

Tony Hansen wrote: I also read it the same way Arvel did. Huh. Ok, then Arvel's clarification seems reasonable. Also, if it isn't interpreted that way, you get ambiguities when multiple instances of a particular header are listed and only some of the values are presented in z=. In particular

Re: [ietf-dkim] When i= domain != d= domain

> It seems defining the state of the signature rather than possible > remedies would be more useful. This makes sense to me as well. -- Arvel ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] r= for instilling good domain-name practices

A major objective of DKIM is to uncover spoofed messages. Often the well-known domain-name establishes trust in messages. Atlas, not all messages from well-known domain-names are always fully vetted, and currently DKIM offers _no_ information on the level of vetting used by the well-known

Re: [ietf-dkim] z= question with X headers

Perhaps: "A vertical-bar-separated list of select header field names and copies of header field values that identify the header fields present when the message was signed. It is not required to include all header field names and values." I've added essentially this wording. Sorry for the conf

Re: [ietf-dkim] z= question with X headers

- Original Message - From: "Eric Allman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: Sent: Friday, April 28, 2006 3:34 PM Subject: Re: [ietf-dkim] z= question with X headers > > Perhaps: > > > > "A vertical-bar-separated list of select header field names and > > copies of header fie

Re: [ietf-dkim] z= question with X headers

// Hash Headers hash = empty; for each hdr in (dkim_h_list) do s = mail_headers[hdr]; sz = dkim_z_list[hdr]; // see is copy is available if (s != sz) { WHAT? INVALID? Should they be the same? What can cause this? Mailing list? } if

Re: [ietf-dkim] When i= domain != d= domain

> It seems defining the state of the signature rather than possible > remedies would be more useful. phoffman> Fully agree. arvel> This makes sense to me as well. So is there consensus that this change belongs in -02? eric ___ NOTE WELL: This lis

Re: [ietf-dkim] Body Length mechanism rejections

| 3.4.5 Body Length Limits | ... | Note that verifiers MAY choose to reject or truncate messages | that have body content beyond that specified by the body length | count. change to: : Note that verifiers MAY choose to truncate messages that have : body content beyond that specified by the body

Re: [ietf-dkim] z= question with X headers

On Fri, 28 Apr 2006, Eric Allman wrote: The z= tag is only supposed to be used for "diagnostic purposes", not for computing the hash. Changing that would have major implications that we would have to examine very carefully. So if mail list changed Subject header field (and for purposes of t

Re: [ietf-dkim] z= question with X headers

The z= tag is only supposed to be used for "diagnostic purposes", not for computing the hash. Changing that would have major implications that we would have to examine very carefully. So if mail list changed Subject header field (and for purposes of this question did not add other fields or c

Re: [ietf-dkim] When i= domain != d= domain

Eric Allman wrote: > It seems defining the state of the signature rather than possible > remedies would be more useful. phoffman> Fully agree. arvel> This makes sense to me as well. So is there consensus that this change belongs in -02? sounds good to me. Mike ___

Re: [ietf-dkim] When i= domain != d= domain

Eric Allman wrote: >> > It seems defining the state of the signature rather than possible >> > remedies would be more useful. > > phoffman> Fully agree. > > arvel> This makes sense to me as well. > > So is there consensus that this change belongs in -02? I agree with the change suggested by Doug'

Re: [ietf-dkim] z= question with X headers

On Fri, 28 Apr 2006, Eric Allman wrote: The z= tag is only supposed to be used for "diagnostic purposes", not for computing the hash. Changing that would have major implications that we would have to examine very carefully. So if mail list changed Subject header field (and for purposes of

Re: [ietf-dkim] Body Length mechanism rejections

Eric Allman wrote: | 3.4.5 Body Length Limits | ... | Note that verifiers MAY choose to reject or truncate messages | that have body content beyond that specified by the body length | count. change to: : Note that verifiers MAY choose to truncate messages that have : body content beyond that

Re: [ietf-dkim] Body Length mechanism rejections

I suggest we step back, for a moment, and think about this some more. I do not have a clever or clean alternative to suggest, but it strikes me that specifying modification to message content (by truncating it) is pretty extraordinary and likely to be problematic in terms of the originators an

Re: [ietf-dkim] z= question with X headers

The pseudo code ignores the case where multiple existences of a header field name may exist in either/both of the h= and z= values. Tony Hector Santos wrote: > - Original Message - > From: "Eric Allman" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: > Sent: Friday, April 28,

Re: [ietf-dkim] z= question with X headers

The revised wording ignores the case where multiple existences of a header field name may exist in either/both of the h= and z= values. It's still ambiguous. Tony Hansen [EMAIL PROTECTED] Eric Allman wrote: >> Perhaps: >> >> "A vertical-bar-separated list of select header field na

Re: [ietf-dkim] When i= domain != d= domain

Arvel Hathcock wrote: > It seems defining the state of the signature rather than possible > remedies would be more useful. This makes sense to me as well. +1 d/ -- Dave Crocker Brandenburg InternetWorking ___ NOTE WELL: This li

Re: [ietf-dkim] Body Length mechanism rejections

On Fri, Apr 28, 2006 at 01:25:53PM -0700, Michael Thomas allegedly wrote: > Eric Allman wrote: > > | 3.4.5 Body Length Limits > | ... > | Note that verifiers MAY choose to reject or truncate messages > | that have body content beyond that specified by the body length > | count

Re: [ietf-dkim] z= question with X headers

I agree. I highlighted the ambiguity for the issues list. But I wanted to point out even without multiple signatures, what to do when a header is missing or changed. I believe what came out of the little discussions was that in the end, it (z=) is totally useless information for verifiers. It is

Re: [ietf-dkim] When i= domain != d= domain

I think the rules say that only a WG Chair can declare consensus, but it sure sounds to me like we have it. I'll make the change as soon as I'm given the go. eric ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rule

Re: [ietf-dkim] z= question with X headers

william(at)elan.net wrote: On Fri, 28 Apr 2006, Eric Allman wrote: The z= tag is only supposed to be used for "diagnostic purposes", not for computing the hash. Changing that would have major implications that we would have to examine very carefully. So if mail list changed Subject heade

Re: [ietf-dkim] When i= domain != d= domain

Eric Allman wrote: I think the rules say that only a WG Chair can declare consensus, but it sure sounds to me like we have it. I'll make the change as soon as I'm given the go. Sorry folks, I've been mega-swamped this week so don't have the context. I didn't notice objections so it seems li

Re: [ietf-dkim] Body Length mechanism rejections

On Apr 28, 2006, at 2:02 PM, Mark Delany wrote: ,--- |3.4.5 Body Length Limits |... | Note that verifiers MAY choose to reject or truncate messages that | have body content beyond that specified by the body length count. '___ change to: : Note that verifiers MAY choose to truncate messages t

Re: [ietf-dkim] Body Length mechanism rejections

- Original Message - From: "Douglas Otis" <[EMAIL PROTECTED]> To: "Mark Delany" <[EMAIL PROTECTED]> > >> That seems like something rather hard to enforce. > > In some cases the message will be verified at the MUA where rejection > is impractical. When the message is rejected, will an err

[ietf-dkim] dkim-base-01 nits and semi-nits

Here are some things that I noticed on a pass through dkim-base-01. Some of these are clearly nits and for others it's less clear, but I have tried to steer clear of things that I know will be controversial. Feel free to comment on any of these if appropriate. Apologies to any whose comments I m

[ietf-dkim] Re: dkim-base-01 nits and semi-nits

Jim, thanks for the comments. Section 1.1 paragraph 1 is now different from the overview in -threats. We were trying to keep the top-level description consistent between the drafts; was this a conscious change? I don't remember exactly how this came about. I'm happy with changing it back f

Re: [ietf-dkim] Body Length mechanism rejections

On Apr 28, 2006, at 4:13 PM, Hector Santos wrote: There seems to be a "battle" of where DKIM is going to be implemented. DKIM can be more rapidly deployed when verification is allowed to take place at both the MTA and MUA. There should be no reason for these goals to be in conflict. Th

Re: [ietf-dkim] Re: dkim-base-01 nits and semi-nits

On Apr 28, 2006, at 5:18 PM, Eric Allman wrote: Section 1.1 paragraph 1 is now different from the overview in -threats. We were trying to keep the top-level description consistent between the drafts; was this a conscious change? I don't remember exactly how this came about. I'm happy wit

Re: [ietf-dkim] r= for instilling good domain-name practices

On 2006-04-28 10:10, Douglas Otis wrote: : The r= parameter is defined by the signer as a simple number : of 0-9, where 0 is the default offering the lowest reliance : level. To ensure control in the case of MUA signing, this r= : parameter in the signature MUST always be less than or equal : t

Re: [ietf-dkim] Re: dkim-base-01 nits and semi-nits

> >Section 3.4.5 second to last paragraph "choose to reject" -> > >"choose to ignore signatures" [this one isn't a nit] > > I'm not sure we have consensus on dropping the "reject" language --- > I think Mark had some concerns. I'll add wording about ignoring the > signature though. My only co

Re: [ietf-dkim] r= for instilling good domain-name practices

J.D. Falk wrote: One signer's r=3 might connote a level of verification equivalent to another signer's r=8. So as a recipient, I'd have to keep track of the domain, the selector, AND the r value...even though I'll be making my reputation decision based entirely on criteria of my own choosing.

Re: [ietf-dkim] r= for instilling good domain-name practices

On Apr 28, 2006, at 5:45 PM, J.D. Falk wrote: On 2006-04-28 10:10, Douglas Otis wrote: : The r= parameter is defined by the signer as a simple number : of 0-9, where 0 is the default offering the lowest reliance : level. To ensure control in the case of MUA signing, this r= : parameter in th

Re: [ietf-dkim] r= for instilling good domain-name practices

Doug, > > Without conventions established for the use of this parameter, it will > offer only little value. Without conventions, only the reliance > parameter being greater than zero would be of any significance. > Conventions can recommend reliance levels for various types of sources > such as: