ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] draft Errata on RFC 4871

2009-01-27 13:54:28
At 07:05 27-01-2009, Dave CROCKER wrote:
That section also does not tie the term to a particular tag.  So 
what is the problem with not changing the section?

In Section 4 of the draft, the UAID is defined as a value which 
identifies the user or agent.  In Section 5, it is specified that the 
UAID must be the value of the i= tag.  In Section 7, the corrected 
text says that i= The responsible User Agent Identifier.

Section 3.5 of RFC 4871 mentions that the d= must be the same or or a 
parent domain of the "i=" tag (the signing identity, as described below).

There is a tie to a particular tag.  If you amend Section 3.5, then I 
cannot tell whether the Signing Identity in Section 1.1 (RFC 4871) 
refers to the Signing Domain identifier or the User Agent 
Identifier.  The draft discusses about the relationship between the 
two new identifiers.  It introduces an Identity Assessor which is 
primarily consuming the Signing Domain Identifier.  Some people may 
read that as the Signing Identity in Section 1.1 (RFC 4871) is the 
de-facto Signing Domain Identifier.

The reason we are having this discussion is because of a confusion 
about "identities".  What may be clear to you and the rest of the WG 
might not be so for implementors who have not been part of the 
WG.  RFC 4871 is on the Standards Track.  That document or its 
successors will be around for quite some time if DKIM is widely 
deployed.  If the goal is to get a technical specification published, 
then we can choose the easy route.  If it is is to create a standard, 
then things like this may be a problem at some point in future.

The proposed errata changes the text.  So I'm not understanding what 
point you are making here.

The point I am making is that d= was not defined as an identity which 
is why some people favor i= over d=.  Your text changes it to an 
identifier and by extension an identity as it is consumed by the 
Identity Assessor.

I don't understand.

In my opinion if the changes after a document has been published 
introduce new definitions and establish relationships, it is not 
clear on whether it can be approved as an errata.

I'm posting the following for the record.

There was a discussion about d= and i= tags when DKIM was 
drafted.  It was viewed that in the absence of an i= tag, the d= tag 
is implicitly taken as the "identity".  The i= tag might be used to 
perform a fine grained assessment.  For example, I may decide not to 
give all DKIM signed mail from a large ESP the same way "weight" by 
assessing identities instead of the entire domain.  That method may 
not scale.  Some people will go for the d= tag as it's easier to manage.

In a previous message I mentioned the g= tag and its relationship 
with the signing identity (i=).  Section B.1.1. (the text is 
informational) elaborates on how it can be used to facilitate 
restricted authorization.  It even mentions that a specific From 
header field Local-part can be authorized.

I understand that the identity from i= is opaque and it is not 
required to match
the identity in any message header fields.  If the identity is 
stable, a verifier could implement a policy to identify that 
"source".  This can be useful if we are thinking in terms of "good" 
and not "bad" messages.

Regards,
-sm 

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