Barry Leiba wrote:
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.
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.
Hi Barry,
I hope the following are non-spec changing suggestions.
I concur the proposed text change is proper:
Internationalized domain names MUST be represented as A-labels
as described in [RFC5890].
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html