Subject: [ietf-dkim] The "real" (remaining) errata

From: Barry Leiba <[email-masked]>
Date: Fri, 1 May 2009 11:56:10 -0400

Apart from the item that resulted in the "errata" draft, now heading
to the IESG as an update to 4871, there are a bunch of other
non-controversial errata that Pasi needs a response to.  Will the 4871
authors please handle those, so the working group and Pasi can clear
them?

Barry (as chair)
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Doug Otis <[email-masked]>
Date: Fri, 1 May 2009 10:26:13 -0700

On May 1, 2009, at 8:56 AM, Barry Leiba wrote:

> to the IESG as an update to 4871, there are a bunch of other non- 
> controversial errata that Pasi needs a response to.  Will the 4871  

Barry,

Forgive the confusion about what was to be accomplished by the errata  
now heading to the IESG.  There was a vote in SF to _not_ make  
functional changes to RFC 4871, and that such changes were to be as a  
RFC 4871bis draft.  The errata however, either through error or by  
intent, made a significant change to RFC 4871 by excluding the i=  
value from being information passed to the MUA.  RFC 4871 indicates  
that the i= value IS the information passed to the MUA, where the d=  
value represents a default i= value when the i= value is not included  
within the signature.  In addition, the d= value must be included  
within the i= value.  The current RFC 4871 is in sync with the just  
released RFC 5451.

To avoid changing the role of the i= value (the signing identity), the  
text within the MUA consideration section could be as follows:
,---
The tendency is to have the MUA highlight the address associated AUID,  
in some way, in an attempt to show the user the address from which the  
mail was sent..
'---

Limiting address annotations to just the d= value prevents a signing  
domain _any_ means to eliminate on-behalf-of ambiguity for the  
recipient.  Without this feature, social engineering attacks that  
glean and spoof a person's acquaintances will be much more difficult  
to mitigate.  Any account from the same provider will always result in  
the same annotation of the From header.  :^(

Don't make changes in an errata that impacts a fundamental and  
potentially crucial feature of DKIM.  Reserve such changes for a fully  
reviewed RFC 4871bis draft.

-Doug

---

From: Barry Leiba <[email-masked]>
Date: Fri, 1 May 2009 14:43:53 -0400

> already "nodded in agreement" to a number of the non-controversial
> errata, and we had discussed that at IETF 73.  What's the process to
> clear the obvious ones?

Checking...

Barry

---

From: Jim Fenton <[email-masked]>
Date: Fri, 01 May 2009 11:31:14 -0700

> authors please handle those, so the working group and Pasi can clear

I'd need to go back through the archives, but I thought the authors had
already "nodded in agreement" to a number of the non-controversial
errata, and we had discussed that at IETF 73.  What's the process to
clear the obvious ones?

-Jim

---

From: <[email-masked]>
Date: Tue, 5 May 2009 13:28:33 +0200

I went back to the archives, and found this one:
http://mipassoc.org/pipermail/ietf-dkim/2008q4/010821.html

As far as I can tell, there were no objections, but the chairs
never forwarded them to me :-)

I have now edited the text for 1378 and 1383 to match the email:

http://www.rfc-editor.org/errata_search.php?eid=1378
http://www.rfc-editor.org/errata_search.php?eid=1383

I think the following ones are now ready to be marked as "Approved"
(will do in couple of days):

http://www.rfc-editor.org/errata_search.php?eid=1376
http://www.rfc-editor.org/errata_search.php?eid=1377
http://www.rfc-editor.org/errata_search.php?eid=1378
http://www.rfc-editor.org/errata_search.php?eid=1379
http://www.rfc-editor.org/errata_search.php?eid=1384
http://www.rfc-editor.org/errata_search.php?eid=1461
http://www.rfc-editor.org/errata_search.php?eid=1487

The ones listed below look correct, but I would welcome opinions
about whether these errors are likely to "cause implementation or
deployment problems or significant confusion". (If not, they should
be marked "Held for Document Update" instead of "Approved") 

http://www.rfc-editor.org/errata_search.php?eid=1380
http://www.rfc-editor.org/errata_search.php?eid=1381
http://www.rfc-editor.org/errata_search.php?eid=1382
http://www.rfc-editor.org/errata_search.php?eid=1383
http://www.rfc-editor.org/errata_search.php?eid=1386

And there are couple more that I haven't gone through yet 
(but will do so soon):
 
http://www.rfc-editor.org/errata_search.php?eid=1385
http://www.rfc-editor.org/errata_search.php?eid=1532
http://www.rfc-editor.org/errata_search.php?eid=1596

Best regards,
Pasi 

> -----Original Message-----
> From: 
Jim Fenton
> Sent: 01 May, 2009 21:31
> To: Barry Leiba
> Cc: IETF DKIM WG
> Subject: Re: [ietf-dkim] The "real" (remaining) errata
> 
> Barry Leiba wrote:
> > non-controversial errata that Pasi needs a response to.  Will the
> > 4871 authors please handle those, so the working group and Pasi can 
> > clear them?
> >
>