Subject: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

From: Jim Fenton <[email-masked]>
Date: Thu, 31 Mar 2011 14:33:51 -0700

The direction of the DKIM specifications since RFC 4871 have been to 
rely less and less on the AUID (agent or user identifier, the i= value 
on the signature) to the point that it provides no security benefit.  On 
the other hand, a malformed AUID can cause a DKIM signature not to 
verify, and i= currently adds to the complexity of the DKIM 
specification.  For this reason, I am formally proposing that the i= tag 
and supporting text be removed from 4871bis.

i= was introduced in RFC 4871 as a mechanism to:

(1) Allow a parent domain to sign for a subdomain, simplifying the 
management of keys.  So if example.com had several subdomains and wanted 
to use the same keys to sign for all of them, it could put the actual 
domain name being used in the i= value (e.g., marketing.example.com) and 
the location where the keys were stored in the d= value (e.g., example.com).

(2) Support finer-grained verification in conjunction with the g= 
tag/value in the key record.  We have already decided to remove the g= 
tag/value in 4871bis.

(3) Support matching with the From address to determine if a signature 
was an Author Signature in SSP.  SSP became ADSP, and WG consensus was 
to match the domain of the From address against the SDID instead.

In order to remove i= from the specification, we need to:

- Remove section 2.6 (definition)
- Remove i= tag definition from 3.5
- Remove i= from example at the end of 3.5
- Remove "s" flag from t= tag definition in 3.6
- Remove section 3.9 (Signing by Parent Domains)
- Remove section 3.10 (relationship between SDID and AUID) or change it 
to reflect SDID-only information
- Remove reference to i= tag in 6.1.1 paragraph 5
- Remove section 8.13 (Inappropriate Signing by Parent Domains)
- Remove i= from examples in A.2 and A.3
- Change IANA registries to retain i= tag in signature and "s" flag in 
key record as deprecated

That's what I could find, but I may have missed something.

In a conversation with Dave Crocker and Murray Kucherawy, they noted the 
use of the local part of i= as an opaque identifier.  Its use as such an 
identifier is not described in any standard, but the relaxation of the 
current restrictions on the use of i= (that the domain-part be a 
subdomain of d=, etc.) would result in an incompatibility with RFC 
4871-compliant verifiers.  It is, however, possible to remove it 
entirely without creating a compatibility problem.

Comments, please.

-Jim

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

---

From: Franck Martin <[email-masked]>
Date: Fri, 1 Apr 2011 11:31:40 +1200 (FJT)

I had the feeling that Y! was using the local part of i= to do differentiation in reputation. ie various streams within the same domain.

I know the spec intent recommends, different domains for different streams, but then....

Intuition would tell me, that few people are willing (or understand) to have different domains for different streams.

----- Original Message -----
From: "Jim Fenton" <[email-masked]>
To: "IETF DKIM WG" <[email-masked]>
Sent: Friday, 1 April, 2011 9:33:51 AM
Subject: [ietf-dkim] Proposal:  Removal of AUID (i= tag/value)

Comments, please.

-Jim

---

From: "Mark Delany" <[email-masked]>
Date: 31 Mar 2011 18:05:21 -0700

> and supporting text be removed from 4871bis.

Gosh Jim, you're probably not surprised when I say +1 to that :-)

While the i=/g= were attempting to solve problems, I agree that the
spec has moved on and simplifying to just d= has considerable
crispness.

As for the other follow-up, I am not aware of Yahoo using i= as a
discriminator.

Mark.