Re: [ietf-dkim] ISSUE: non-ascii header text
Douglas Otis wrote: Changing a reference of RFC3490 to RFC5890 already represents an incompatible change. Your assertion is noted. John, it is correct to reference RFC5890 but for any implementations that currently have RFC3490 support there is a conflict verifiers need to be aware of. A proposed text change addendum as follows is both protocol consistent and provides compatibility insight: 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 without a RFC3490 reference: 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. The desire is not to increase anyone's workload, but the reasons for developing DKIM will become even more apparent during the introduction of UTF-8. IMO, if someone begins to start thinking about UTF8 support for DKIM, they will need to view this expensive revamping for their general 5321/5322 mail I/O operations. In the mean time, AFAMUG, RFC5890 offers an isolated DKIM transition for implementing in operations not yet wrapped with Unicode support. Unfortunately, the current DKIM specifications ignore important aspects about where A-Labels are to exist within a protocol. Are we not specifying all the IDNs within RFC5322 including DKIM-Signature, in particular d=, s= and i=? A-Labels are NOT intended for human consumption. +1, neither is Unicode outside their locales. But displays are expected to translate all that for human viewing. DKIM also failed to ensure resources are only obtained at valid A-Labels or NR-LDH defined locations. Does that mean we need affirmation if we are just talking about A-label as input for DNS lookups only. A significant security flaw, especially when definitions of valid A-Labels has significantly changed for the better. Lost me. Better for security? Or worst? Or better for something else, worst for security? -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: non-ascii header text
On 4/20/11 5:02 PM, John R. Levine wrote: Internationalized domain names MUST be encoded as Non-Reserved LDH, A-Labels as described in RFC5891, or equivalent U-Labels. Repeating this bad idea doesn't make it a good idea, Besides being a bad idea on its own merits, this would without question require us to recyle at proposed standard. John, Use of A-labels within header fields supporting UTF-8 is a bad idea. Changing a reference of RFC3490 to RFC5890 already represents an incompatible change. Clarify use of resources MUST be at NR-LDH or valid A-Labels whether or not U-Labels are used within headers. Mandating use of A-labels within header fields defeats the internationalization effort and is wrong. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: non-ascii header text
On 21/Apr/11 14:25, John R. Levine wrote: Use of A-labels within header fields supporting UTF-8 is a bad idea. Since DKIM is defined on RFC 5322 messages, and 5322 is ASCII-only, no header fields in a compliant message can contain UTF-8. It would be surprising if DKIM supported UTF-8 in the header, since it recommends 7bit encodings for the body :-/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: non-ascii header text
On 4/21/11 5:25 AM, John R. Levine wrote: Use of A-labels within header fields supporting UTF-8 is a bad idea. Since DKIM is defined on RFC 5322 messages, and 5322 is ASCII-only, no header fields in a compliant message can contain UTF-8. I don't know why you keep repeating this uttetly wrong stuff, but please stop now. http://tools.ietf.org/html/draft-ietf-eai-rfc5336bis-09 While the majority of users within your borough may not care, a large population within Asia and elsewhere do. In fact, much of their email already violates RFC5322's ASCII-only requirements. This limitation will change very soon. Setting DKIM on a sustainable track must deal with this natural evolution, despite those saying please stop. You are a good and intelligent person that deserves a great deal of respect. Changing a reference of RFC3490 to RFC5890 already represents an incompatible change. Your assertion is noted. The desire is not to increase anyone's workload, but the reasons for developing DKIM will become even more apparent during the introduction of UTF-8. Unfortunately, the current DKIM specifications ignore important aspects about where A-Labels are to exist within a protocol. A-Labels are NOT intended for human consumption. DKIM also failed to ensure resources are only obtained at valid A-Labels or NR-LDH defined locations. A significant security flaw, especially when definitions of valid A-Labels has significantly changed for the better. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: non-ascii header text
While the majority of users within your borough may not care, a large population within Asia and elsewhere do. In fact, much of their email already violates RFC5322's ASCII-only requirements. I have trouble reading this as other than we're going to leapfrog everything that EAI is doing in this minor DKIM revision. In any event, I'll leave it to the chairs whether they see any support for making incompatible changes to support (as opposed to detect or reject) messages that are explicitly not 5322. Regards, John Levine, jo...@iecc.com, 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
Re: [ietf-dkim] ISSUE: non-ascii header text
Murray S. Kucherawy wrote: Oops, this is a separate issue. But I hope it's also not contentious. [...] Since I'm not exactly an EAI/IDNA expert... The only thing that's not obvious to me is whether the hash functions should hash the bytes of the UTF-8, or convert them to UTF wide characters and hash those. Depending on the way the MTA is written, either might seem more natural, but I'm inclined to say you hash the UTF-8 bytes because the SHA-1 and SHA-256 hash functions are defined on bytes, not wider things. Can you suggest the exact change to make here, or confirm there isn't one? Murray, I viewed this as another layer issue. Adding a DKIM-Signature: header is no different than any other RFC5322 header where UTF8 conversion is already a consideration. But maybe to provide guidance for what parts of the DKIM-Signature RFC5322 header needs to be UTF8 ready, I think that might the following text is useful. RFC5322 messages should be prepared with UTF-8 readiness when required. For the DKIM-Signature RFC5322 header, implementators SHOULD focus on tags d=, s= and i= to be UTF8 ready. I think the above will help implementators with the engineering incentive for UTF8 conversions is more for general mail operations than it is specifically for DKIM. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: non-ascii header text
On Wed, 20 Apr 2011 09:24:26 +0100, Hector Santos hsan...@isdg.net wrote: Murray S. Kucherawy wrote: Oops, this is a separate issue. But I hope it's also not contentious. [...] Since I'm not exactly an EAI/IDNA expert... The only thing that's not obvious to me is whether the hash functions should hash the bytes of the UTF-8, or convert them to UTF wide characters and hash those. Depending on the way the MTA is written, either might seem more natural, but I'm inclined to say you hash the UTF-8 bytes because the SHA-1 and SHA-256 hash functions are defined on bytes, not wider things. Can you suggest the exact change to make here, or confirm there isn't one? Murray, I viewed this as another layer issue. Adding a DKIM-Signature: header is no different than any other RFC5322 header where UTF8 conversion is already a consideration. But maybe to provide guidance for what parts of the DKIM-Signature RFC5322 header needs to be UTF8 ready, I think that might the following text is useful. RFC5322 messages should be prepared with UTF-8 readiness when required. For the DKIM-Signature RFC5322 header, implementators SHOULD focus on tags d=, s= and i= to be UTF8 ready. Is there anything that actually needs to be done with a UTF-8 header that is not covered already in our DKIm spec.? The EAI effort, whilst still formally in the experimental stage, is on the verge of becoming a Proposed Standard. Indeed, it may even get there before we do. So we may as well ensure that DKIM is compatible with it; otherwise we shall be asked to make it compatible during AUTH48. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: c...@clerew.man.ac.uk 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
Re: [ietf-dkim] ISSUE: non-ascii header text
The only thing that's not obvious to me is whether the hash functions should hash the bytes of the UTF-8, or convert them to UTF wide characters and hash those. Depending on the way the MTA is written, either might seem more natural, but I'm inclined to say you hash the UTF-8 bytes because the SHA-1 and SHA-256 hash functions are defined on bytes, not wider things. Can you suggest the exact change to make here, or confirm there isn't one? No change needed, it's all hypothetical at this point anyway. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: non-ascii header text
Is there anything that actually needs to be done with a UTF-8 header that is not covered already in our DKIm spec.? No, it's fine, so long as we make my proposed changes that clarify that the bits of domain names in the DKIM-Signature: header (d= i= s=) are represented as A-labels. Regards, John Levine, jo...@iecc.com, 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
Re: [ietf-dkim] ISSUE: non-ascii header text
Charles Lindsey wrote: Murray, I viewed this as another layer issue. Adding a DKIM-Signature: header is no different than any other RFC5322 header where UTF8 conversion is already a consideration. But maybe to provide guidance for what parts of the DKIM-Signature RFC5322 header needs to be UTF8 ready, I think that might the following text is useful. RFC5322 messages should be prepared with UTF-8 readiness when required. For the DKIM-Signature RFC5322 header, implementators SHOULD focus on tags d=, s= and i= to be UTF8 ready. Is there anything that actually needs to be done with a UTF-8 header that is not covered already in our DKIm spec.? The heads up is mentioned (in an odd way), but I think John's proposal to define it as A-label is probably the right way. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: non-ascii header text
On 4/20/11 7:09 AM, John R. Levine wrote: Is there anything that actually needs to be done with a UTF-8 header that is not covered already in our DKIm spec.? No, it's fine, so long as we make my proposed changes that clarify that the bits of domain names in the DKIM-Signature: header (d= i= s=) are represented as A-labels. http://tools.ietf.org/html/draft-ietf-dkim-rfc4871bis-06#section-3.5 d= ... Internationalized domain names MUST be encoded as described in [RFC3490 http://tools.ietf.org/html/rfc3490]. Should be changed to: Internationalized domain names MUST be encoded as Non-Reserved LDH, A-Labels as described in RFC5891, or equivalent U-Labels. Validation therefore ensures U-Labels resolve DKIM resources published at valid A-Labels. In some cases, labels that were valid per RFC3492 may need corresponding resources published at different domains. This may entail expressing labels using only lower case characters, for example. U-Labels SHOULD be used whenever UTF-8 is known to be supported by the receiver. Otherwise, recipients will be unable to discern relationships with email domains also expressed in UTF-8 when A-Labels are used within DKIM header fields. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: non-ascii header text
Internationalized domain names MUST be encoded as Non-Reserved LDH, A-Labels as described in RFC5891, or equivalent U-Labels. Repeating this bad idea doesn't make it a good idea, Besides being a bad idea on its own merits, this would without question require us to recyle at proposed standard. Regards, John Levine, jo...@iecc.com, 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
Re: [ietf-dkim] ISSUE: non-ascii header text
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of John Levine Sent: Tuesday, April 12, 2011 11:32 PM To: ietf-dkim@mipassoc.org Subject: [ietf-dkim] ISSUE: non-ascii header text Oops, this is a separate issue. But I hope it's also not contentious. [...] Since I'm not exactly an EAI/IDNA expert... The only thing that's not obvious to me is whether the hash functions should hash the bytes of the UTF-8, or convert them to UTF wide characters and hash those. Depending on the way the MTA is written, either might seem more natural, but I'm inclined to say you hash the UTF-8 bytes because the SHA-1 and SHA-256 hash functions are defined on bytes, not wider things. Can you suggest the exact change to make here, or confirm there isn't one? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] ISSUE: non-ascii header text
Oops, this is a separate issue. But I hope it's also not contentious. 3.5, d= and i= tags: references to RFC3490 should be RFC5890. The reference to ToASCII() should go, or else in both places say IDNs are represented as A-labels. Suggested new language under d= on page 22: Change: Internationalized domain names MUST be encoded as described in [RFC3490]. To: Internationalized domain names MUST be represented as A-labels as described in [RFC5890]. Suggested new language under i= on page 23: Change: Internationalized domain names MUST be converted using the steps listed in Section 4 of [RFC3490] using the ToASCII function. To: Internationalized domain names MUST be represented as A-labels as described in [RFC5890]. 3.5, z= tag, remove paragraph Header fields with characters requiring conversion (perhaps from legacy MTAs that are not [RFC5322] compliant) SHOULD be converted as described in MIME Part Three [RFC2047]. DKIM only applies to RFC5322 compliant messages, RFC2047 does not provide conversions for all of the fields that can be copied in a z= header, and as soon as the EAI RFCs come out, which is likely to be soon, this advice will be wrong anyway. Free extra bonus confusion: the EAI WG is working on 5322 extensions that basically allow UTF-8 anywhere in messages handled by EAI-aware mail software, specifically including anywhere in an e-mail address. (That is, the domain part does not have to be an A-label.) I think it is reasonable to assume that a DKIM-Signature in an EAI message can include UTF-8 characters in any data field where it makes sense, e.g., d=, i=, s=, z=. DKIM-quoted-printable doesn't need to change since there's no need to quote any non-ASCII UTF-8 characters. The only thing that's not obvious to me is whether the hash functions should hash the bytes of the UTF-8, or convert them to UTF wide characters and hash those. Depending on the way the MTA is written, either might seem more natural, but I'm inclined to say you hash the UTF-8 bytes because the SHA-1 and SHA-256 hash functions are defined on bytes, not wider things. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: non-ascii header text
Oh, one other thing: 3.5, s= tag. Since the selector is components of a domain name, they can also be IDNs, so on page 26, between the sentence describing s= and the ABNF: Add: Internationalized domain names MUST be represented as A-labels as described in [RFC5890]. Regards, John Levine, jo...@iecc.com, 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
Re: [ietf-dkim] ISSUE: non-ascii header text
I'm generally in favor of updating the document to match the current state of IDN and EAI work, but I don't know it well enough to comment intelligently on whether John's proposed text does so. What John has looks right to me, and is consistent with earlier advice from John Klensin and with what the IRI group has done. Barry, as participant ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: non-ascii header text
On 4/13/2011 10:31 AM, J.D. Falk wrote: I'm generally in favor of updating the document to match the current state of IDN and EAI work, but I don't know it well enough to comment intelligently on whether John's proposed text does so. as phrased, I'll disagree with this. one spec should not try to track fluid developments of other specs. it should cite stable specs, and preferably ones that have gained adoption. anything more than that is attempting to predict the future. in the case of internationalized character issues, that's proved problematic for at least 20 years... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: non-ascii header text
one spec should not try to track fluid developments of other specs. it should cite stable specs, and preferably ones that have gained adoption. Agreed. That's why I only cited 5890. The other comments were basically saying that as far as I can tell, once we take out the reference to 2047 (which we should do anyway), nothing we're doing has obvious unpleasant interactions with the current state of EAI, so even if we felt like doing something, there'd be nothing to do. Regards, John Levine, jo...@iecc.com, 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
Re: [ietf-dkim] ISSUE: non-ascii header text
On Apr 13, 2011, at 12:07 PM, Dave CROCKER wrote: On 4/13/2011 10:31 AM, J.D. Falk wrote: I'm generally in favor of updating the document to match the current state of IDN and EAI work, but I don't know it well enough to comment intelligently on whether John's proposed text does so. as phrased, I'll disagree with this. one spec should not try to track fluid developments of other specs. it should cite stable specs, and preferably ones that have gained adoption. Yeah, that's a good point. If that work isn't stable yet, it may be better to simply point to the working group. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: non-ascii header text
Dave CROCKER wrote: On 4/13/2011 10:31 AM, J.D. Falk wrote: I'm generally in favor of updating the document to match the current state of IDN and EAI work, but I don't know it well enough to comment intelligently on whether John's proposed text does so. as phrased, I'll disagree with this. one spec should not try to track fluid developments of other specs. it should cite stable specs, and preferably ones that have gained adoption. anything more than that is attempting to predict the future. in the case of internationalized character issues, that's proved problematic for at least 20 years... +1. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
