Re: [ietf-dkim] RFC4871bis

Ok.  The key question there seems to me to be 'does the UAID namespace
represent actual identities'?  For most of the use cases I can think of
for assessing the UAID, it doesn't really matter whether it matches the
from address or not. 

-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Tony Hansen
Sent: Monday, January 26, 2009 2:51 PM
To: DKIM IETF WG
Subject: Re: [ietf-dkim] RFC4871bis

The only one of interest I've seen suggested so far was if the i= value
was identical to the users' email addresses. But I could potentially see
other possible values for the 2nd area of interest. Another way to frame
the 2nd area of interest is: what type of namespace does the signer use,
if they care to identify it?

        Tony Hansen
        tony(_at_)att(_dot_)com

Michael Adkins wrote:

The stability part I agree with. For the second area of interest, are
you saying the verifier would only find it interesting if i= was the
same as the user's (for some definition of 'user') email address?

Dave CROCKER wrote:

but, ummm...,  this really would be a functional enhancement, and so
it ought to be discussed as part of the broader RFC revision effort,
and certainly under a different thread, such as the Subject I'm using
here...

d/

Tony Hansen wrote:

A side conversation with several people generated these two areas of
interest to a verifier about the i= identifiers being generated by a
signer:

1) Are the values stable? That is, will the same value be used by

the

signer each time a message is signed on behalf of a particular
user/agent? Examples of stable values are
emailaddress(_at_)domain(_dot_)example(_dot_)com (such as AUIDs that use 
the same
namespace as their users' email addresses),
user10234912(_at_)domain(_dot_)example(_dot_)com (such as AUIDs based on 
the users'
internal user IDs), and 
ABCDEFGH123456789(_at_)domain(_dot_)example(_dot_)com (such

as

AUIDs based on a hash of the user name). Examples of unstable values
would be ones that incorporate additional information within the i=
value that is time varying, but is still able to be mapped to a

single

user's/agent's identity.

2) For stable values, is the namespace the same as the users' email
addresses? That is, is the stable value the same as the user's email
address?

One suggestion made was to use key record t= value to communicate

this

information.

    Tony Hansen
    tony(_at_)att(_dot_)com

Michael Adkins wrote:

I think there will be cases where a signer chooses to make their
UAID semantics known to assessors specifically for assessment
purposes. How the signer might communicate that to the assessors is
out of scope for the moment I think. I would assume that, for
starters, the signers would approach individual assessors/mailbox
providers. If it proved useful and was worth doing on a larger
scale, then we could figure out a way to make the signer's
preference automatically known to assessors.


Siegel, Ellen wrote:

A question regarding the notes in 10 and 11:

Would it make more sense to suggest that the mail system make the
UAID
clear to the reader if its the identity whose reputation was used

to

deliver the message, and make the SDID clear to the reader

otherwise?

_______________________________________________

[> ]
Given that the semantics of the UAID are inherently opaque, how
would you suggest that the mail system make the assessment? I like
the concept, but don't see how it can be implemented given the
defined syntax/semantics.

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

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

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