Subject: Re: [ietf-dkim] [dkim] #4: non-ascii header text

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 14 Apr 2011 15:41:34 -0700

> -----Original Message-----
> From: dkim issue tracker [mailto:[email-masked]]
> Sent: Wednesday, April 13, 2011 6:53 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: [dkim] #4: non-ascii header text
> 
> #4: non-ascii header text
> 
>  http://mipassoc.org/pipermail/ietf-dkim/2011q2/015789.html
> [...]

I'm fine with all of these changes, but am happy to defer to those more well-versed in EAI than I am.

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

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 16 Apr 2011 09:45:52 -0700

> I'm fine with all of these changes, but am happy to defer to those more well-versed in EAI than I am.

Unfortunately, I think this topic is not trivially resolved.

Our spec relies on ToASCII, but the UTF-8 folks took it away.  Since it's 
documented in an RFC and we have no complaints that it fails to work correctly, 
we can continue to refer to it, in spite of its being obsoleted.  However, that 
is obviously an uncomfortable road to travel.

The problem with switching to RFC5890 is the potential that that constitutes an 
actual protocol change of a type not allowed for going to Draft Standard.

The problem with ignoring UTF-8 issues is, of course, that that's no longer 
acceptable.

This issue has been floating around for months and I have never found my own 
view landing on solid ground.  I do not know the best way for us to navigate it. 
  Worse, I'm not even sure who we should talk with to get advice, since the 
EAI/UTF-8 space has its own content and process problems right now.

mumble.

The best I can think of is to take the details John Levine proposes and float 
them by a number of IESG folks for pre-approval review.  If they are comfortable 
that it resolves the issue without threatening Draft status, then we are done.

d/
-- 

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

---

From: "John R. Levine" <[email-masked]>
Date: 16 Apr 2011 13:47:31 -0400

> actual protocol change of a type not allowed for going to Draft Standard.

I believe this same question was fought at length in the IDNA group and 
when the dust and blood settled, they agreed that the changes between 3490 
and 5480, which are apparently limited to the encoding of three rarely 
used diacriticals, are sufficiently trivial that it's not considered a 
protocol change.  Hence they did not change the xn-- prefix for A-labels.

I certainly have no objection to checking with the IDNA crowd to confirm 
my impression.  I'll check with a few of the usual suspects.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John R. Levine" <[email-masked]>
Date: 16 Apr 2011 14:07:51 -0400

>> actual protocol change of a type not allowed for going to Draft Standard.

I asked my IDNA expert, who said that the definitive answer is "it 
depends".  He suggests our chair ask our AD to check with the IESG.

I just looked through my three year archive of DKIM signatures and as far 
as I can tell, I've literally never seen one with an IDN, much less one 
with an IDN that would be different, so I think we can make a plausible 
argument that the practical change is imperceptible.

Regards,

---

From: Barry Leiba <[email-masked]>
Date: Sun, 17 Apr 2011 15:22:30 -0400

> depends".  He suggests our chair ask our AD to check with the IESG.

Our chair is asking our AD to check.

Barry, our chair

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 18 Apr 2011 18:22:25 +0200

> The problem with ignoring UTF-8 issues is, of course, that that's no longer 

Would it be acceptable to put some text like the following?

  Internationalized domain names MUST be represented as A-labels
  as described in [RFC5890].

     NOTE: For experimental use only, domain names MAY be
     represented in UTF-8 as described in [RFC5335].

or

     INFORMATIVE NOTE: For experimental use of [RFC5335],
     domain names are to be represented in UTF-8.

jm2c

---

From: "John Levine" <[email-masked]>
Date: 18 Apr 2011 18:15:06 -0000

>     represented in UTF-8 as described in [RFC5335].

Please, no.  If you're interested in the swamp of non-ASCII
domain names and mail addresses, head over to the EAI WG.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Thu, 21 Apr 2011 13:46:07 -0400

> Our chair is asking our AD to check.

We have the IESG's answer: we should change the reference to RFC 5890
and change the text to use A-labels, as John recommended.  That will
NOT be considered a major change, and will allow us to proceed to
Draft Standard with this version of the spec.

Barry, as chair

---

From: Hector Santos <[email-masked]>
Date: Thu, 21 Apr 2011 18:59:21 -0400

Barry Leiba wrote:
>>> depends". �He suggests our chair ask our AD to check with the IESG.

Hi Barry,

I hope the following are non-spec changing suggestions.

I concur the proposed text change is proper:

However, looking at the code implementation/change requirements there 
might a need for some additional text to address compatibility 
concerns and also help provide a better understanding.  Since I wasn't 
around the EAI WG to know if the following was already considered, 
thus completely forgetting the original text IDN MUST requirement, I 
will throw it out there to see if its make sense.

Considering MUST design requirements in the original DKIM text:

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

and the following MUS design requirement in rfc5336bis-09, section 3.2 
as it applies to SMTP:

    When doing lookups, the EAI-aware SMTP server MUST either
    use a Unicode aware DNS library, or transform it to A-label
    defined in [RFC5890].

For compatibility and protocol consistency, would it be technical 
correct to have additional similar semantics applying to verifiers as 
well?

For example:

    Internationalized domain names MUST be represented as A-labels
    as described in [RFC5890].  For public key lookups, verifiers
    MUST transform internationalized domain names already encoded as
    described in [RFC3490] to A-labels.

or in less text:

    Internationalized domain names MUST be represented as A-labels
    as described in [RFC5890] for both DKIM-Signature domain values
    and for Public Key DNS lookups.

With these insights, it means a complete DKIM verifiers will need to 
wrap their code with multi-translators, for example, when extracting 
d= value

    alabel = EncodeRFC5890(DecodeRFC3490(dkim.signer))

Each function will check its input to see if its already function 
result format (i.e, already decoded/encoded).

But if we think RFC3490 was still insignificant and don't need to 
mention it, then the DKIM verifier would just need:

    alabel = EncodeRFC5890(dkim.signer)

Also, finally, it may also help to show an example of complete public 
key query string in a-label format.  To answer the question if you 
translate the entire query string first or each part first?

This:

    selector =  DecodeRFC3490(dkim.selector)
    signer   =  DecodeRFC3490(dkim.signer)
    query    =  EncodeRFC5890(selector) +
                ".domainkey." +
                EncodeRFC5890(signer)

versus:

    selector =  DecodeRFC3490(dkim.selector)
    signer   =  DecodeRFC3490(dkim.signer)
    query  =    EncodeRFC5890(selector+".domainkey."+signer)

-- 
HLS

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 25 Apr 2011 11:51:15 +0100

> Draft Standard with this version of the spec.

But, alternatively, you could change the text to use U-labels. AFAICS from  
RFC 5890, properly formed U-labels and A-labels are interchangeable. So it  
just a question of who and when does the conversion - the signer or the  
verifier.

-- 
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 R. Levine" <[email-masked]>
Date: 25 Apr 2011 10:13:27 -0400

> just a question of who and when does the conversion - the signer or the

As I pointed out to Doug several times, U-labels are UTF-8 which are not 
ASCII, so that would be both an incompatible change, and a violation of 
RFC 5322.

A few minutes ago a guy with a name similar to yours sent in a passionate 
note saying how important it was only to sign valid RFC 5322 messages. 
Could the two of you thrash it out privately?

R's,
John