On Feb 10, 2009, at 3:20 AM, wrote:
> Douglas Otis wrote:
>
>> Statements that imply the i= value is always OPAQUE prevents its
>> utilization for highlighting purposes with respect to identity
>> assurances, even when there is an exact match and this value could
>> be said to not be opaq
pasi.ero...@nokia.com wrote:
> Douglas Otis wrote:
>
>> Statements that imply the i= value is always OPAQUE prevents its
>> utilization for highlighting purposes with respect to identity
>> assurances, even when there is an exact match and this value could
>> be said to not be opaque. This also se
On Tue, Feb 10, 2009 at 4:50 PM, pasi.ero...@nokia.com
wrote:
> So, even exact match with some email header is useless to the
> recipient (unless it somehow knows that the Signer is using same
> namespaces for these two fields).
So, entirely opaque to the recipient and solely for the sender's use
Douglas Otis wrote:
> Statements that imply the i= value is always OPAQUE prevents its
> utilization for highlighting purposes with respect to identity
> assurances, even when there is an exact match and this value could
> be said to not be opaque. This also seems to conflict with the
> defined us
On Feb 5, 2009, at 8:08 AM, Jon Callas wrote:
>> Statements that imply the i= value is always OPAQUE prevents its
>> utilization for highlighting purposes with respect to identity
>> assurances, even when there is an exact match and this value could
>> be said to not be opaque. This also se
On 2/6/09 2:00 PM, Dave CROCKER wrote:
> RFC4871 is a body of specific text. Either one publishes replacements
> for its text or one publishes a rule that can be used for replacing
> text. The current Errata draft does the former. You want to do the
> latter.
>
> The latter invites one reader
Eliot Lear wrote:
>> It is common for Errata to provide precise corrections. That means
>> supplying
>> the exact text that needs to be changed. While a generic "warning" is
>> comforting, it is not precise.
>
> While I am very much amenable to a different set of text, I do not
> accept your
Dave,
On 2/6/09 4:20 AM, Dave CROCKER wrote:
> Eliot Lear wrote:
> > Here, the consumer of this information, the verifier, is warned against
> > making use of i=. However, what we are now saying is that practical
> > deployment experience requires a stronger warning; that absent
> > a
Eliot Lear wrote:
> Here, the consumer of this information, the verifier, is warned against
> making use of i=. However, what we are now saying is that practical
> deployment experience requires a stronger warning; that absent
> additional information from the signer that is not exposed by th
Eliot Lear wrote:
Here, the consumer of this information, the verifier, is warned against
making use of i=. However, what we are now saying is that practical
deployment experience requires a stronger warning; that absent
additional information from the signer that is not exposed by this
Douglas Otis wrote:
> This new function called the Identity Assessor for DKIM would
> presumably be focused on identities. For DKIM, it might determine
> which portion of an email-address gets highlighted.
>
> When the i= field _exactly_ matches with an email-address contained
> within a s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>
> Statements that imply the i= value is always OPAQUE prevents its
> utilization for highlighting purposes with respect to identity
> assurances, even when there is an exact match and this value could be
> said to not be opaque. This also seems to co
On Feb 5, 2009, at 3:36 AM, Charles Lindsey wrote:
>>
>> First, I stuck to terminology that was in RFC 4871 intentionally,
>> with an eye toward keeping the errata simple.
>
> Yes, but we are currently discussing Dave's errata, which carefully
> distinguishes between the Verifier, which does t
On Wed, 04 Feb 2009 18:40:14 -, Eliot Lear wrote:
>> No, SHOULD NOT is too strong. Normally, that would indeed be the case,
>> but
>> in specific cases the Assessor (not the Verifier) might have
>> information,
>> obtained by some out-of-band means, what that particular i= meant, and
>>
At 23:00 03-02-2009, Eliot Lear wrote:
>Here, the consumer of this information, the
>verifier, is warned against making use of
>i=. However, what we are now saying is that
>practical deployment experience requires a
>stronger warning; that absent additional
>information from the signer that
Eliot Lear wrote:
> I responded to Charles privately, but there seems to be more general
> confusion (and perhaps some on my part):
>
> On 2/4/09 11:15 AM, Charles Lindsey wrote:
>> On Wed, 04 Feb 2009 07:00:25 -, Eliot Lear wrote:
>>
>>
>>> absent additional information from the signer t
On Feb 4, 2009, at 10:40 AM, Eliot Lear wrote:
>
> Doug Otis cites the case I wonder as to whether it exists. One
> could envision all sorts of things going on within the LHS of the
> @, like a encrypted username with a nonce. I can't say whether
> anybody actually does that or wants to d
>deployment experience requires a stronger warning; that absent
>additional information from the signer that is not exposed by this
>specification, verifiers SHOULD NOT rely on i= as any sort of identity,
>because the value may not be present or stable.
That's basically it.
> 2. Is the above
I responded to Charles privately, but there seems to be more general
confusion (and perhaps some on my part):
On 2/4/09 11:15 AM, Charles Lindsey wrote:
On Wed, 04 Feb 2009 07:00:25 -, Eliot Lear wrote:
absent additional information from the signer that is not exposed by this
specifi
On Feb 4, 2009, at 2:15 AM, Charles Lindsey wrote:
> On Wed, 04 Feb 2009 07:00:25 -, Eliot Lear wrote:
>
>> Here, the consumer of this information, the verifier, is warned
>> against making use of i=. However, what we are now saying is that
>> practical deployment experience requires a
On Wed, 04 Feb 2009 07:00:25 -, Eliot Lear wrote:
> Here, the consumer of this information, the verifier, is warned against
> making use of i=. However, what we are now saying is that practical
> deployment experience requires a stronger warning; that absent
> additional information from the
Eliot Lear wrote:
> One remaining point of discussion:
>
> While the confusion arises between d= and i=, what verifiers do with a
> valid signed message is still up to them. They could take input from
> various header fields if they wish (and some assuredly do and will).
Correct.
Just as th
Tony, Dave, and John,
Thanks for your patient explanations. Particularly you, Dave. You did
quite a number of rounds with me in private. To summarize what I
understand (or misunderstand), the fundamental issue with this erratum
is that the text surrounding i= in RFC 4741 does not sufficient
23 matches
Mail list logo
