Subject: Re: [ietf-dkim] Proposed new charter

From: Dave CROCKER <[email-masked]>
Date: Mon, 01 Mar 2010 17:24:04 +0800

This is perhaps more relevant to a discussion about interoperability testing, 
but I thought it worth raising also for the next round of specification, etc. work:

    Do we know whether DKIM works IDNs?  If not, what should we do about that?

(I'm sitting in Apricot and this came up during an APCauce discussion.)

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: <[email-masked]>
Date: Mon, 1 Mar 2010 09:26:00 -0500

Only if IDNA is incorporated in the DKIM signature verifier

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
Sent: Monday, March 01, 2010 4:24 AM
To: [email-masked]
Subject: Re: [ietf-dkim] Proposed new charter

d/

-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 1 Mar 2010 21:00:34 -0000

>(I'm sitting in Apricot and this came up during an APCauce discussion.)

IDNs are all punycoded as xn--whatever and turn into normal domain
names.  Nothing exotic there.

If people want to put un-punycoded UTF into their domain names, it
won't work very well for DKIM, but then it wouldn't work any better
for anything else.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 02 Mar 2010 05:44:37 +0800

in theory, there's no difference between theory and practice.

in practice, there's interoperability testing...

d/

-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Mon, 01 Mar 2010 14:02:15 -0800

>      Do we know whether DKIM works IDNs?  If not, what should we do about that?
Not only will DKIM need to contend with RFC 3490 and RFC 3492 
conventions for puny-code, but also conditionally apply RFC 5242 and 
Unicode Technical Report #36, http://www.unicode.org/reports/tr36/ rule 
sets.  The SMTP experimental conventions established by RFC 5336 expects 
these fields are handled by humans. Input would represent UTF-8 and not 
Puny-code.  While IDN for DNS must be converted to xn--<puny-code> 
form,  friendly displays in email will likely need to be in UTF-8.

With respect to problems for DKIM, it would seem downgrade (Alt-Address) 
operation might cause DKIM signatures to be declared non-compliant with 
ADSP.

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 1 Mar 2010 20:12:45 -0500

> in practice, there's interoperability testing...

I'd think more conformance than interop, since I'd be surprised if there 
were any ambiguity about the correct way to encode UTF-8 into punycode.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 02 Mar 2010 09:27:42 +0800

On 3/2/2010 9:12 AM, John R. Levine wrote:
> I'd think more conformance than interop,

The IETF technical community largely lacks the construct of "conformance".  Over 
the years, the influx of telecom folks has introduced it periodically, but it 
still is absent from formal IETF work.

There is a long pragmatic history behind this cultural constant.

 >    since I'd be surprised if there

Would you rather be surprised in the middle of critical infrastructure 
operations or during an interop event?

d/
-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 1 Mar 2010 20:31:24 -0500

>>    since I'd be surprised if there were any ambiguity about the correct 
>> way to encode UTF-8 into punycode.

> operations or during an interop event?

No, of course not.  If we have another interop event, it would make sense 
to drop in a few IDNs and see what the software does.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Mon, 01 Mar 2010 18:01:22 -0800

> were any ambiguity about the correct way to encode UTF-8 into punycode.
There remains issues related to DNS conversion for code predating RFC 
5242, which can lead to different results.  UTF-8 in email is used to 
accommodate IDNs per RFC 5336.  Uncertain conversions represent 
justifications for finding ways to replicate zones in order to establish 
name equivalency.   It takes many years for code to find stability, 
where IDN is within a transitional phase.

As a side note, the tpa-label scheme could accommodate "equivalent" and 
"alt-name" validations, such as those related to ADSP, in addition to 
the authorizing of mailing-lists that remains an open issue.

-Doug

---

From: Eliot Lear <[email-masked]>
Date: Tue, 02 Mar 2010 09:36:37 +0100

Dave,

I think you've caught a problem.

I want to stress that I'm not an IDN expert.  Patrik Fältström is, and 
I'm copying him on this for further comment.
He points out that RFC-4952 properly states that-

    "The domain part of email addresses is already internationalized
    [RFC3490], while the local part is not."

But RFC-4952 is itself only an informational document, and there are 
experimental documents that might seem to conflict.  Specifically, 
RFC-5335 does *not* reference 3490, and talks about an SMTP extension to 
carry UTF8 headers.  Worse- RFC 5505 doesn't reference 3490 either and 
references RFC 2047 encoding.  The key issue is the order of encoding (a 
word in which we get into some trouble), from I can tell; because an 
alternate header is otherwise provided, and that breaks DKIM.

For DKIM to work, I don't see how we can avoid saying that 3490 encoding 
must occur prior to EAI (RFC 5335/5505) encoding.  Otherwise, you have 
to handle the case where both the signing and verifying DKIM 
implementation must handle Downgrade- headers in a perhaps fruitless 
effort to reconstruct the original headers so that the original domain 
can be derived, in order to then encode THAT into 3490.

I suspect what is needed at the very least is a clarification; probably 
a proposed standard would be nice.

FWIW, I don't have single MUA on my systems (and I have quite a number) 
that supports ANY of this yet; including TB, Apple Mail, pine, and 
associated tools.

Eliot

---

From: John Levine <[email-masked]>
Date: 2 Mar 2010 18:45:01 -0000

>    [RFC3490], while the local part is not."

Right.  There is a standard way to encode Unicode domain names, but
there is no standard way to represent email addresses with non-ASCII
local parts.  EAI is working on it, slowly, and I think it would a
poor idea to attempt to guess what they might eventually send down the
standards track.  EAI docs so far are experimental or informational.

This means that in DKIM, the d= value is a domain, it's punycoded, no
question about that.  The i= value has the syntax of an email address,
so its domain part is also punycoded.  But if the mailbox part is not
ASCII, you're out of standards territory.  For the copied headers,
they should all be in ASCII already unless you're doing 8bit, but 8->7
downcoding will break a lot more than the copied headers, so
fugeddaboudit.

Basically, for non-ASCII domains, the solution is obvious, for general
non-ASCII mail addresses, we do what everyone else is doing and wait
for EAI.

R's,
John

PS: Dueling experts: I ran this past Paul Hoffman and he generally
agreed.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 03 Mar 2010 06:12:09 +0800

On 3/3/2010 2:45 AM, John Levine wrote:
> question about that.

I don't recall that in the DKIM specification and I don't recall the part of the 
specification the dictates a context in which the punycode version is a given.

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Tue, 02 Mar 2010 14:58:11 -0800

On 3/2/10 10:45 AM, John Levine wrote:
>  poor idea to attempt to guess what they might eventually send down
>  the standards track.  EAI docs so far are experimental or
>  informational.

IDN is at the beginning of a dramatic change.  As such, DKIM work should 
consider long term impacts.  Soon there will be a proliferation of human 
Unicode input for both right and left hand portions of an email 
address.  Does anyone really doubt that?

To satisfy human desires of obtaining "equivalent" names, similar to 
ASCII case folding, UTF-8 to puny-code conversion is changing.   As 
such, there is ongoing efforts to utilize name equivalency to deal with 
UTF-8 to puny-code conversion inconsistencies.  Reasons have been 
offered in RFC 5242 and Unicode Technical Report #36, 
http://www.unicode.org/reports/tr36/ rule sets.  Evolution of this 
process should also be expected to continue many years.

>  This means that in DKIM, the d= value is a domain, it's punycoded,
>  no question about that.  The i= value has the syntax of an email
>  address, so its domain part is also punycoded.

Agreed.  But that does not mean headers communicating with human 
recipients will be in puny-code, or that input accepted from humans will 
be puny-code either.  If that were the case, there would be little 
advantage in having IDNs.  Newer name services already utilize UTF-8 for 
domain queries.  As such, puny-code may someday become an interim 
solution. IEEE/EIA 12207.1-1997 and US Government 2007 CSR require 
systems to accommodate UTF-8.

>  But if the mailbox part is not ASCII, you're out of standards
>  territory.  For the copied headers, they should all be in ASCII
>  already unless you're doing 8bit, but 8->7 downcoding will break a
>  lot more than the copied headers, so fugeddaboudit.

There are methods to encode headers using ASCII which could be extended 
to include email-addresses.  As such, DKIM should be able to play a role 
in the confirmation of "equivalent" names, in a manner similar to what 
might be used to authenticate third-party signers.  Introduction of IDN 
will then be less disruptive when DKIM is able to accommodate an array 
of UTF-8 equivalent or alt names.

>  Basically, for non-ASCII domains, the solution is obvious, for
>  general non-ASCII mail addresses, we do what everyone else is doing
>  and wait for EAI.

EAI has already produced a general framework.  This framework, along 
with mailing-list issues, should be enough to justify having methods in 
DKIM to affirm related names.

-Doug

---

From: "John R. Levine" <[email-masked]>
Date: 2 Mar 2010 18:11:27 -0500

> I don't recall that in the DKIM specification and I don't recall the part of 
> the specification the dictates a context in which the punycode version is a 
> given.

There's two contexts, actually, d= and i=.

RFC 4871, top sentence on page 20, in the description of d=

    Internationalized domain names MUST be encoded as described in
        [RFC3490].

RFC 4871, second paragraph on page 21, in the description of i=

    Internationalized domain names MUST be converted using the steps
        listed in Section 4 of [RFC3490] using the "ToASCII" function.

In retrospect, the two sentences should have been worded the same, but if 
you read RFC 3490, you can see that they amount to same thing.

For anyone else unfamiliar with IDNs, RFC 4690 offers a good overview, 
with pointers to the relevant standards including RFC 3490.  As RFC 4690 
notes, although there is a standard way to encode Unicode domain names, 
there's no encoding for non-ASCII mailbox names yet.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 03 Mar 2010 09:05:26 +0800

>> the specification the dictates a context in which the punycode version is a
...
> RFC 4871, top sentence on page 20, in the description of d=
...
> RFC 4871, second paragraph on page 21, in the description of i=

Thanks for dredging that up; I had done a thoroughly inadequate quick check of 
the doc and used the wrong search term, as well as indeed entirely forgetting 
that there was any relevant text at all in the spec.

That said, the text for i= is more of the type that should exist.  i= is not the 
primary parameter, and d= is, but the text for d= is too vague.  Probably better 
than nothing, but too generic.

For the bis effort, I'd recommend this clarification.  I think it would fall 
within acceptable boundaries of change while going to Draft.

d/

-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 3 Mar 2010 02:47:27 -0000

>within acceptable boundaries of change while going to Draft.

I agree the two sentences should say the same thing. Don't feel
strongly about the wording since the way UTF->punycode works is the
same for all domain names everywhere.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 03 Mar 2010 11:04:34 +0800

> same for all domain names everywhere.

My point is that the citation is essentially specifying a functional interface 
and, therefore, needs to be a highly precise reference into the specific 
function(s) to be incorporated into DKIM.

d/
-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 2 Mar 2010 23:10:06 -0500

> My point is that the citation is essentially specifying a functional 
> interface and, therefore, needs to be a highly precise reference into the 
> specific function(s) to be incorporated into DKIM.

It wouldn't hurt, but since there is exactly one (1) standard specified 
way to encode IDNs in the DNS, there'd be no ambiguity even if the DKIM 
spec had said nothing at all about IDNs.

Encoding IDNs as punycode is like encoding text domains in ASCII.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Wed, 03 Mar 2010 08:24:23 +0100

> standards track.  EAI docs so far are experimental or informational.

Dave asked the question - does DKIM work with IDNs.  The simple answer 
is "no" because IDNs themselves don't really work today, as a practical 
matter, in the context of email.  What is clear is that folks from DKIM 
need to track and perhaps influence EAI.

> downcoding will break a lot more than the copied headers, so

In 7-bit, we have two forms of encoding available: punycode for domain 
names in the from line and MIME for the rest.  To date, we have confused 
implementations, Apple Mail being one clear case.  Again, in answer to 
Dave's question, this situation is ripe for a mess, and closer 
collaboration with EAI might help.

Eliot

---

From: Barry Leiba <[email-masked]>
Date: Wed, 3 Mar 2010 08:47:16 -0500

> need to track and perhaps influence EAI.

Does this, then, turn into another item on the new charter?
"Work with the EAI working group to ensure that DKIM and EAI work well
together." ?

Barry

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 03 Mar 2010 21:54:21 +0800

> "Work with the EAI working group to ensure that DKIM and EAI work well

Maybe other folk are tracking this, but I'm now confused.

DKIM does not affect other email header-fields, other than doing a hash on them. 
  For example, DKIM has nothing to do with any of the address fields, whereas I 
believe that is EAI's focus.

Since DKIM has /lots/ to do with a domain name (in d=, most importantly), it 
really does have to pay attention to IDNA.  But I am not understanding how DKIM 
relates to the EAI work.

Eliot, can you clarify?

And if you still believe we need to work with the EAI wg, can you clarify what 
that might/should entail and, for that matter, whether we wind up fate-sharing 
with them?  And if yes, then doesn't the difficult history of the EAI work make 
it likely we will share the difficulty?

d/

-- 

   Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Wed, 03 Mar 2010 15:32:39 +0100

Hi Dave,

> DKIM does not affect other email header-fields, other than doing a 
> hash on them.  For example, DKIM has nothing to do with any of the 
> address fields, whereas I believe that is EAI's focus.
>
> Since DKIM has /lots/ to do with a domain name (in d=, most 
> importantly), it really does have to pay attention to IDNA.  But I am 
> not understanding how DKIM relates to the EAI work.
>
> Eliot, can you clarify?

Certainly.  In a nut shell, the problem is at the implementation end 
between the MUA and the signer.  The common signers out there will only 
do so for certain domains, and they will generally only do so, based on 
the From: line.  Here is where the confusion sets in.  If an MUA sees an 
address, such as the following:

From: Eliot Lear <[email-masked]>

What is the right conversion?  In the 7-bit world, you might see 
something like the following:

From: Eliot Lear =?iso-8859-1?Q?<lear@klapsm=FChle.ch>?=

When the signer sees this, it could upgrade to get klapsmühle.ch, and 
then check the punycode version of that.  Things get more confused in 
EAI, because there 8-bit MIME floating around.  If you sign 8-bit MIME 
and a downgrade occurs, the game is over, and the signature is invalidated.

But suppose you instead decide to downgrade first.  You may not be able 
to downgrade, according to the RFC 5504.  If an implementation cannot 
downgrade it must return an error to the user.  In practice, this will 
mean that your MTA in the middle must do the downgrade, adding 
Downgraded headers, and rewriting various others before handing the 
message to DKIM for signing.

Some clarification here would at the very least be useful.  Perhaps this 
is as much an update to RFC 5585 as anything else.  A clear warning that 
the domain found in the From: line may not appear in punycode seems like 
good advice, if nothing else.

Eliot

---

From: "John R. Levine" <[email-masked]>
Date: 3 Mar 2010 09:43:35 -0500

> Dave asked the question - does DKIM work with IDNs.  The simple answer is 
> "no" because IDNs themselves don't really work today, as a practical matter, 
> in the context of email.  What is clear is that folks from DKIM need to track 
> and perhaps influence EAI.

Sounds to me like we have a confusion of TLAs.  IDNs, that is, Unicode 
domain names, work just fine.  There is a standard, well defined, and 
widely implemented way to translate between Unicode and punycode.  If you 
want to use an IDN as the d= domain or a selector, or even as the domain 
part of i=, it is quite clear what should happen, and existing signing and 
verifying code will handle it correctly since it's no different from the 
handling of any other domain.  I could imagine ways that provisioning 
systems might be broken, but I'd be surprised if there were any that 
didn't do the right thing if you typed in the xn--blah punycode version of 
your IDN.

EAI, on the other hand, general non-ASCII e-mail addresses, don't work at 
all, and I think we agree that they don't work in DKIM just like they 
don't work anywhere else.

> In 7-bit, we have two forms of encoding available: punycode for domain names 
> in the from line and MIME for the rest.  To date, we have confused 
> implementations, Apple Mail being one clear case.

Right.  There's no standard, so it's not surprising that different MUAs do 
different random things.  We can hope that the EAI WG will eventually 
disgorge a usable spec and that MUAs will implement it.

> Again, in answer to Dave's question, this situation is ripe for a mess, 
> and closer collaboration with EAI might help.

Agreed, but it's not just a DKIM mess, it's a general mess.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 03 Mar 2010 22:48:04 +0800

> address, such as the following:

Confusion, indeed.  In what way is the From: line relevant to DKIM, other than 
being part of the header field hash?

I believe we are not in any way implying any changes to the hashing algorithm, 
since DKIM does not do field-specific processing.  (For example, it cannot know 
all of the possible address header fields.)

> and a downgrade occurs, the game is over, and the signature is invalidated.

Ahh, well, the DKIM specification does not provide text that guides selection of 
the d= value.

So, yes, the signer might have differential signing practices based on the From: 
field, but that's outside the scope of the specification.

What am I missing?

d/
-- 

   Dave Crocker

---

From: Eliot Lear <[email-masked]>
Date: Wed, 03 Mar 2010 15:57:12 +0100

On 3/3/10 3:48 PM, Dave CROCKER wrote:
> Ahh, well, the DKIM specification does not provide text that guides 
> selection of the d= value.
>
> So, yes, the signer might have differential signing practices based on 
> the From: field, but that's outside the scope of the specification.
>
> What am I missing?

As I wrote, I think this is more of a clarification, and perhaps not to 
the spec, but to RFC-5585.

Eliot

---

From: Ian Eiloart <[email-masked]>
Date: Wed, 03 Mar 2010 11:02:24 +0000

> address.  Does anyone really doubt that?

Uh Oh! Let's hope we can continue to rely on the presence of an '@' symbol, 
and that the domain always remains on the right hand side, even when 
right-to-left languages are used.

-- 
ןשמק@דודדקסץשבץול

Vertical email addresses anyone?!

秒
年
亿
@
宿
舍
色
相
。
阿
城
。
佧
可

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: Michael Thomas <[email-masked]>
Date: Wed, 03 Mar 2010 06:47:00 -0800

> "Work with the EAI working group to ensure that DKIM and EAI work well
Howse about something more reactionary: things that mangle bytes after they
leave a signer are an automatic DISCUSS with extreme prejudice from the
security AD's.

Mike

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 03 Mar 2010 15:30:21 -0000

> standards track.  EAI docs so far are experimental or informational.

Indeed, although it is rapidly becoming into use in China and such places.  
But DKIM cuurently applies only to messages complying with RFC 5322. A  
future (possibly Experimental) extension would be needed to DKIM for it to  
apply to RFC 5355 messages.

AIUI, punycoding is only essential for DNS queries (i.e. when you need to  
get an MX record in order to send email to it). And even that may change,  
as Doug has said. Before that, one might use either UTF-8 or punycode  
forms. All agree that in visible form in email clients it will be in  
UTF-8. Currently, for transmission using RFC 5321, it has to be in  
punycode.

In the "experimental" universe within which people implement RFC 5335/6,  
transmission also uses UTF-8 (so punycode is only seen during DNS lookups,  
if there). So long as messages remain within that experimental universe  
(as 95% of them will), DKIM as it stands should work quite happily,  
leaving everything in UTF-8, with no punycode anywhere.

BUT at a boundary where a message leaves that experimental universe (i.e.  
where the sending server advertises the UTF8SMTP Capability and the  
receiving server does not), then a Downgrade has to take place.  
Downgrading can change so many things that any DKIM signature is almost  
certain to be broken, and I think we have to accept that (as we already do  
with mailing list expanders). And changes to the format of email addresses  
would not be the only cause of such failures. A sufficiently smart  
verifier MIGHT just about manage to salvage a verifiable signature from  
the remains, but I doubt it.

Hence that boundary seems like a good place for the Downgrading Agent to  
do a resigning (hopefully adding an A-R header and including it in the new  
signature).

Coming in the opposite direction, a message addressed to ascii@i18ndomain  
would already have the i18ndomain in punycode. Under EAI it would remain  
in that form (although user agents might well display it in utf-8).  
Likewise with any From and Reply-To headers and suchlike. So any incoming  
DKIM signature should remain verifiable anywhere in the experimental  
universe.

But I agree that what we need now is for some dialogue with the EAI WG.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 3 Mar 2010 17:47:34 -0000

>What is the right conversion?

There isn't any.  Until we have EAI standards, there is no way to
represent non-ASCII characters in e-mail addresses in a standards
compliant mail message.

Some years ago we had a modest flame fest about how to sign a message
body that contains bare CR or LF characters.  The answer was "don't do
that", since DKIM signatures only apply to valid 822/2822/5322
messages.  This is the same issue.

I entirely realize that for the large majority of the world that
writes its names in non-ASCII characters, this is a gaping hole which
has provoked a variety of more or less sound and more or less
incompatible workarounds.  But it's one that EAI has to solve for all
e-mail, not one to which we can unilaterally apply a band-aid in DKIM.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Wed, 03 Mar 2010 13:30:42 -0800

> same for all domain names everywhere.
Disagree.  One should not assume there is a unitary conversion of UTF to 
punycode.  The informational RFC 5242 has changed this one-to-one 
relationship.  As such UTF->punycode will produce a more than one 
conversion, depending upon conversion rule-sets applied.  There is a 
genuine need for the additional rule-sets, so don't assume there is a 
unitary conversion of UTF to punycode, or that there are even just two 
possibilities.

This issue will impact ADSP more than DKIM base.   ADSP is based upon 
what is seen in the From header.  Conversions of the From header may not 
resolve to a specific domain, depending upon the evolving conversion 
rule-sets.  The solution sought to deal with this issue is to use 
"equivalent" names to intercept these possible conversions.  The set of 
overlapping UTF names can be rather large and evolving.

ADSP may consider advising the use of double conversion.  Convert UTF 
into punycode using RFC5242 rules, and then convert punycode to UTF-8.  
Since there is no definite conversion that might be used, assured 
compliance may depend upon methods that allow use of third-party 
signatures, which could apply whenever the conversion rule-sets between 
sender and receiver are not the same.

-Doug

---

From: Barry Leiba <[email-masked]>
Date: Fri, 12 Mar 2010 11:49:23 -0500

OK, let's see... I've seen no wordsmithing of the proposed charter
text, so that stands as it is (but see below).  Based on the very
limited discussion of milestones and dates, I've come up with the
following for y'all to bash:

  +++ Milestones +++
  1. Produce an interoperability report for DKIM base... July 2010

  2. Produce a working group I-D detailing deployment and effectiveness
     data for DKIM base... Sept 2010

  3. Produce a working group I-D detailing deployment and effectiveness
     data for ADSP... Nov 2010

  4. Produce a working group I-D addressing issues related to mailing
     lists... Dec 2010

  5. Update overview and deployment informational RFCs as appropriate,
     and/or produce one or more new informational RFCs from information
     obtained above... Feb 2011

The discussion has raised the issue of working with IDNs and EAI.  Do
we have consensus add a charter item for that?  Is it necessary that
we do?  If we want one, someone please propose charter text and one or
more milestones for it.

Barry, as chair

---

From: Eliot Lear <[email-masked]>
Date: Fri, 12 Mar 2010 17:58:32 +0100

Barry,

This looks good, although the schedule seems very aggressive.  I think 
it would be very helpful to know that there are volunteers for each 
component, so that they can get a running start.  Are there?

Eliot

---

From: Barry Leiba <[email-masked]>
Date: Fri, 12 Mar 2010 12:39:39 -0500

> This looks good, although the schedule seems very aggressive.  I think it
> would be very helpful to know that there are volunteers for each component,
> so that they can get a running start.  Are there?

I agree; I'd be happier with the dates more spread out, but
1. I'm documenting what's been said here, with just some minimal
adjustments, and
2. for the interop report, I'm responding to the urgency that some
have expressed.

So, as Eliot asks: Do we really have people with time and inclination
to push these through?  Are these dates reasonable, or should some be
pushed out a bit?  In any case, who will work on which items?

Please post here, if you will actively work on the milestones (and
specify which).  And, in particular, if you want to be the primary pen
on the interop report, send an off-list note to the chairs,
<[email-masked]>.

Barry, as chair

---

From: Douglas Otis <[email-masked]>
Date: Fri, 12 Mar 2010 10:24:51 -0800

Barry,
> we do?  If we want one, someone please propose charter text and one or
6. Review proposed by EAI changes and make needed accommodations where 
appropriate.  This effort might include strategies for handling domains 
with overlapping puny-code versions of an initial UTF-8 U-label... Feb 
2012.  (IDNA will take time, where DKIM WG involvement should improve 
the results.)

Resultant domains representing common administrations needed to handle 
rule changes in puny-code conversions.  This will impact email 
significantly.  ADSP might assist in determining whether puny-code 
referenced signatures relate to the resulting multitude of visual email 
addresses.  While many consider DKIM limited to white-listing, ADSP in 
conjunction with some consolidation mechanism could assist in managing 
new TLDs and many related domains.

-Doug

---

From: John Levine <[email-masked]>
Date: 12 Mar 2010 18:45:23 -0000

>we have consensus add a charter item for that?

Please, no.  4871 already says what it needs to about IDNs.  Should
the EAI group ever come up with a standards track rule for encoding
non-ASCII mail addresses, we might add a twiddle saying that the rule
for i= is the same, but we can burn that bridge when we come to it.

In the meantime, I'll be happy to work on the mailing list stuff.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 12 Mar 2010 11:51:34 -0800

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Barry Leiba
> Sent: Friday, March 12, 2010 9:40 AM
> To: Eliot Lear
> Cc: Patrik Fältström; IETF-DKIM

Happy to put time and effort into working on any of those five items you listed.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 12 Mar 2010 12:24:07 -0800

> for i= is the same, but we can burn that bridge when we come to it.
Agreed, the i= field would change when local-parts are allowed to 
contain more than ASCII.

There is also RFC5617 that involves what is found within the From 
header, which is not constrained by the transport,and that already often 
contains more than just ASCII.  It would be this aspect of EAI, such as 
illustrated by RFC5335, where the DKIM WG should offer guidance in how 
this is best handled.  It would be better not to ignore this issue.
> In the meantime, I'll be happy to work on the mailing list stuff.
Good.  ADSP also affects mailing lists in addition to versions of UTF-8 
found in the From header. :^)

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 15 Mar 2010 11:19:36 -0700

> Sent: Friday, February 19, 2010 11:32 AM
> To: IETF DKIM WG
> Subject: [ietf-dkim] Proposed new charter
> 
> [...]
> 
>   2. Collect data on the deployment, interoperability, and
>      effectiveness of the base DKIM protocol, with consideration
>      toward updating the working group's informational documents.

Would an appropriate part of this output be a "standard" test suite for implementations to try, i.e. a batch of test messages and their expected body and header hashes?

There are vague reports of interoperability issues starting to surface, and I wonder how proactive the WG can be in assisting resolution of these.  Debugging interoperability problems is often a chore, especially when unresponsive vendors are involved.  Nipping these problems before they get out into the wild is possibly the best course of action.

If this isn't a reasonable WG output, the implementers can probably come up with such a test suite among themselves, but it seems to me there's a lot of audience overlap anyway...

-MSK

---

From: John Levine <[email-masked]>
Date: 16 Mar 2010 01:12:09 -0000

> Would an appropriate part of this output be a "standard" test suite
> for implementations to try, i.e. a batch of test messages and their
> expected body and header hashes?

Yes, definitely.  There are plenty of RFCs that include test vectors
to validate implementations, e.g. RFCs 2144, 2410, 3711, and 4434.

R's,
John

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 17 Mar 2010 16:11:35 -0600

> pushed out a bit?  In any case, who will work on which items?

Fairly certain I can provide some relevant aggregated data within that timeframe, and participate in the discussions.  Not sure if I'll have the time to lead any of the proposed efforts.

--
J.D. Falk <[email-masked]>
Return Path Inc