Nikos,
Follow Alexey's advice about where to take this -- LAMPS should
have constructive suggestions. However, the evidence I've seen
suggests that, while most registrars use IDNA2008 as you note,
many or most browsers are still using IDNA2003 or some hybrid
involving IDNA2003, UTR46, and, sometimes, unofficial (and
inconsistent) versions of Stringprep modified to reflect some or
all Unicode versions since 3.2.
That makes many situations, not just HTTPS, quite confusing.
Free advice:
(1) Assume there will be no mapping. Use only labels
consisting of "final" codepoints, i.e., in IDNA2008 terminology.
the decoded form of each label in a domain name must be either
an LDH-label or a U-label
(2) Use domain names that are valid under both IDNA2003 and
IDNA2008. That, unfortunately, limits you to Unicode 3.2
because IDNA2003 does not allow later versions to be used to
create labels to be stored in the DNS.
If you follow both rules in your choice of domains, you should
be safe and behavior should be predictable unless you use a
string that IDNA2008 considers a valid U-label but that contains
characters that IDNA2003 and/or UTR46 map to different
characters. If you need to violate either rule, or use one of
the three characters referred to in the previous sentence,
expect confusion and possible bad results.
If what you intend to put in the certificates are non-ASCII
email addresses rather than just domain names, things are even
more complicated and confusing. Best to take that up in LAMPS
as well.
If you want someone to complain to about this situation, I'm
sure someone on this list can point you to appropriate parties.
:-(
Good luck.
john
--On Wednesday, November 23, 2016 16:19 +0100 Nikos
Mavrogiannopoulos <[email protected]> wrote:
> Hi,
> I sent the attached message originally in pkix list. It seems
> that PKIX (X.509) certificates are currently stuck with
> IDNA2003, making the HTTPS situation quite confusing, since
> most browsers and registrars use IDNA2008 for DNS. Is there
> any suggestion on how this situation can be addressed?
>
> regards,
> Nikos
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
