Latest docs

[Mark Davis]

Here is suggested text.

   This modification will allow some strings to be used in Stringprep
   contexts that are not allowed today.  It is possible that differences
   in the interpretation of the specification between old and new
   implementations could pose a security risk, but it is difficult to
   envision any specific instantiation of this.

   Any rational attempt to compute, for instance, a hash over an
   identifier processed by Stringprep would use network order for its
   computation, and thus be unaffected by the changes proposed here.
   While it is not believed to pose a problem, if display routines had
   been written with specific knowledge of the RFC 3454
<http://tools.ietf.org/html/rfc3454> Stringprep
   prohibitions, it is possible that the potential problems noted under
   "backwards compatibility" could cause new kinds of confusion.

<add>
The requirements stated in Section 3. "A requirement set for the BIDI rule"
avoid some of the problems for visual confusion with bidi labels that can
lead to security problems. However, it needs to be recognized that while the
rules in IDNA2008 have these requirements as goals, IDNs are not guaranteed
to meet those requirements. Two sources of unexpected rearrangement are:
(a) if programs are not conformant to the Unicode Standard for BIDI, they
may reorder characters in an unexpected fashion.
(b) because intralabel checks are not required, unexpected reordering may
occur as  discussed in "Section 5. Troublesome situations and guidelines".
<end>

Mark


On Mon, Dec 22, 2008 at 02:52, Harald Alvestrand <harald at alvestrand.no>wrote:

> Mark Davis wrote:
>
>>
>> Security Considerations (Defs/BIDI) still needs to:
>>
>>
>>   1. document how the compatibility problems between 2003 and 2008
>>      can cause security problems
>>      (See http://docs.google.com/Doc?id=dfqr8rd5_361dwv9cff8 ). Some
>>      of this is in Rationale, but needs to be added or referenced,
>>      while other parts are missing. I can supply some suggested text
>>      if desired.
>>
>>  I think Bidi is adequate on this point.
>
>>
>>   1. document the security issues that can arise in BIDI where Label
>>      Uniqueness and Character Grouping are not maintained. (These
>>      goals cannot be guaranteed because of intra-label issues and
>>      variance among bidi implementations).
>>
>>  Send text.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20081222/7c297cb1/attachment-0001.htm