ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Open issues in RFC4871bis

2011-04-02 01:34:32
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Douglas Otis
Sent: Friday, April 01, 2011 4:30 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Open issues in RFC4871bis

On 4/1/11 2:08 PM, Murray S. Kucherawy wrote:
The first, and biggest, is the removal of “i=” that Jim has proposed
separately, so please comment on that thread.

For ADSP the d= and the From domain must match, which removes the need
for i=. Nevertheless, the i= can introduce different identities that
might assist when transitioning to different IDN encodings. [...]

Doug, I reiterate: Please comment on *that* thread.  That is, discuss "i=" over 
there, not here.

2) The document has text related to “assessment”. Does an “independent
assessment service” fit into the DKIM model? Again, the issue is
whether or not we want to include discussion of uses that are possible
but uncommon. Is there support for this change, or support against
making the change, or does it not really matter?

It is likely the only sustainable assessment will be matching with known
good sources, which would benefit by having a means to handle aliases
and authorized paths. :^)

I have no idea whether you're expressing an opinion for or against the 
suggested change here.

The text in question is this:

*2.3**. Identity*

A person, role, or organization. In the context of DKIM, examples

include the author, the author's organization, an ISP along the

handling path, an independent trust assessment service, and a mailing

list operator.

DKIM should make no claims about identities. DKIM only relates signed
portions of a message with that of a domain that publishes the public
key. Would it be right to suggest this domain _is_ an identity?

Section 2.3 is only a definition, not an expression of signature semantics.  
So, again, I don't understand how you're answering the question(s) here.


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html