[Freeipa-devel] [PATCH 0070] Normalization check only for IDNA domains

Martin Basti mbasti at redhat.com
Fri Jun 27 14:35:37 UTC 2014


On Fri, 2014-06-27 at 13:04 +0300, Alexander Bokovoy wrote:
> On Fri, 27 Jun 2014, Jan Cholasta wrote:
> >On 27.6.2014 10:58, Alexander Bokovoy wrote:
> >>On Fri, 27 Jun 2014, Jan Cholasta wrote:
> >>>On 27.6.2014 10:29, Alexander Bokovoy wrote:
> >>>>On Fri, 27 Jun 2014, Jan Cholasta wrote:
> >>>>>On 27.6.2014 10:15, Alexander Bokovoy wrote:
> >>>>>>On Fri, 20 Jun 2014, Martin Basti wrote:
> >>>>>>>On Fri, 2014-06-20 at 10:32 +0200, Jan Cholasta wrote:
> >>>>>>>>On 18.6.2014 16:49, Martin Basti wrote:
> >>>>>>>>>Due to compability with older versions, only IDNA domains should be
> >>>>>>>>>checked
> >>>>>>>>>Patch attached.
> >>>>>>>>
> >>>>>>>>I'm not particularly happy about the u'\xdf' special case. Isn't
> >>>>>>>>there a
> >>>>>>>>better way to do this check?
> >>>>>>>I cant find better way. u'\xdf' is mapped to ss, and ss is not IDN
> >>>>>>>string.
> >>>>>>>
> >>>>>>>Or just remove this validation.
> >>>>>>>
> >>>>>>>>(BTW I really think this should be a warning, not an error, but that
> >>>>>>>>would require larger amount of work, so I guess it's OK for now.)
> >>>>>>>(More pain than gain)
> >>>>>>Main thing in this patch is that the check should not be done against
> >>>>>>non-IDN strings. I want this version of the patch to go in for that
> >>>>>>reason as currently you cannot even complete ipa-adtrust-install
> >>>>>>run due
> >>>>>>to IDN normalisation check being applied to non-IDN domains.
> >>>>>
> >>>>>On non-IDN domains, the only effect of IDN normalization is that it
> >>>>>lower-cases the names (right?), so the check should compare
> >>>>>lower-cased original name with the normalized name, instead of
> >>>>>special-casing certain characters etc.
> >>>>.. what's the reason to do such comparison then? lower-cased non-IDN
> >>>>name will be equal to lower-cased normalized non-IDN name by definition,
> >>>>so the check is not needed in this case, at all.
> >>>
> >>>The point is that it works for both IDN and non-IDN, without
> >>>u'\xdf'-style hacks.
> >>No, your proposal of comparing low-cased value and normalized value is
> >>not going to work because low-cased value is in general not equal to
> >>normalized value for IDN names, only for non-IDN ones, due to the fact
> >>that lower case for non-ASCII Unicode character may map to a completely
> >>different character than in normalization situation. Take, for example,
> >>Turkish alphabet where there are six letters with different case rules
> >>(uppercase dotted i, dottless lowercase i, upper- and lowercase G with
> >>breve accent, and upper- and lowercase S with cedilla), which will break
> >>your generalized check.
> >>So you'll anyway will need to split these cases.
> >>
> >
> >I see.
> >
> >I'm still not comfortable with carrying the bit of knowledge about 
> >u'\xdf' in this particular spot. Can we check that a name is IDN some 
> >other way than "domain_name.is_idn() or u'\xdf' in value"?
> 
> Attached patch works for me. Note that nameprep() use should be
> per-label, not the whole DNS name, and we can use
> encodings.idna.ToASCII() per lable to check if the label is IDN. If any
> of the label is IDN, we force strict check.
> 

Hello,

be careful with this:

+            labels = value.split('.')

RFC3490 Section 3.1.1
Whenever dots are used as label separators, the following
      characters MUST be recognized as dots: U+002E (full stop), U+3002
      (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61
      (halfwidth ideographic full stop).

This is even not handled in python-dns, I have discussion with
python-dns maintaner and I will probably make a patch.

And in IDNA2008 [not supported in IPA/python-dns] - there is only U+002E
(full stop) as label separator.

I suggest to raise an error if domain name contains U+FF61, U+FF0E, U
+3002. User should use only U+002E (full stop). This will fix issue with
python-dns and works with IDNA2008 too

-- 
Martin^2 Basti




More information about the Freeipa-devel mailing list