help-libidn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC5280 update for IDNA2008


From: Simon Josefsson
Subject: Re: RFC5280 update for IDNA2008
Date: Sun, 19 Feb 2017 09:54:23 +0100
User-agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux)

Tim Ruehsen <address@hidden> writes:

> On Monday, January 16, 2017 1:12:00 PM CET Nikos Mavrogiannopoulos wrote:
>> Hi,
>>  There is an attempt to update RFC5280 with IDNA2008:
>> https://mailarchive.ietf.org/arch/msg/spasm/o0l9nJ4TMPla7KQeqnEyDIqz_Lw
>> 
>> Do you have any comments on the effort? I do not know whether the
>> conversion rules listed in section 7.2 apply in IDNA2008, nor whether
>> the TR#46 should be referred to or ignored (as it is done now).
>
> "NEW
>
>    Domain Names may also be represented as distinguished names using
>    domain components in the subject field, the issuer field, the
>    subjectAltName extension, or the issuerAltName extension.  As with
>    the dNSName in the GeneralName type, the value of this attribute is
>    defined as an IA5String.  Each domainComponent attribute represents a
>    single label.  To represent a label from an IDN in the distinguished
>    name, the implementation MUST perform the "ToASCII" label conversion
>    specified in Section 4.1 of [RFC3490].  The label SHALL be considered
>    a "stored string".  That is, the AllowUnassigned flag SHALL NOT be
>    set."
>
>
> The draft doesn't mention preprocessing of IDNs at all, just mentions still  
> RFC3490 (known as IDNA 2003).
> This doesn't clarify anything, just changes the wording...
> At it's current state, it is useless (for me).

Yep - I agree.  And any effort that replace IDNA2003-references with
IDNA2008 will break catastrophically in the real world since IDNA2008
needs pre-processing to be useful.

/Simon

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]