Security Considerations: bad split
Harald Tveit Alvestrand
harald at alvestrand.no
Sun Dec 7 09:03:47 CET 2008
Having re-read the security considerations on -bidi, I fail to see how
it's possible to comprehend these few paragraphs without just having
read -bidi.
I also fail to see how these few paragraphs will enhance people's
understanding of any of the other documents.
For reference, the text is:
9. Security Considerations
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 Stringprep
prohibitions, it is possible that the potential problems noted under
"backwards compatibility" could cause new kinds of confusion.
In the case of -bidi, I see the drive for an unified security
considerations section as quixotic, harmful and nonsensical.
Clear enough opinion?
Harald
More information about the Idna-update
mailing list