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