Erik van der Poel <[EMAIL PROTECTED]> writes: >> A third way, which is what I am deploying, is to use the Unicode 3.2 >> NFKC together with a filter to reject the PR-29 problem sequences. >> This is in line with the RFC's, it solves problems related to PR-29 >> problem sequences, and is simple to implement. > > I don't think this is in line with the RFCs. You are rejecting sequences > that are not rejected by the RFCs.
I don't see how RFCs can force an implementation to accept strings that may cause security problems. My SASL implementation reject the PR-29 sequences, as will my Kerberos implementation, and I suggest that everyone implement similar precautions. Until this problem is addressed in an update of RFC 3454, rejecting the problem sequences appear to be the most conservative approach to me. What would you propose to do instead? If the situation is as you claim, that there are multiple StringPrep implementations out there that implement NFKC in different ways, it seems hazardous to permit the strings through when you don't know how other components will behave. This is especially true if you perform authentication or authorization on an internationalized authentication or authorization identity, and then pass it on to another component that may run another NFKC implementation on the string, before it is used by a component that assume the identity has been properly authenticated or authorized earlier. > More importantly, when you continue to ship your implementation as is, > more and more installations of your popular library will occur, making > it more difficult for the world to adjust if and when the affected types > of character sequences are introduced, either with the current > characters or new characters. The problem sequences doesn't normally occur in the wild, at least that is what PR-29 says, so it is unlikely to ever be a practical problem. It remains a security concern though, and that concern won't go away until the spec's are updated, regardless of what I do in my implementation. > You are in a position to make a difference. You already have. Please > reconsider. This isn't up to individual implementors. RFC 3454 need to be updated to address the problem. Everyone can submit their own update of RFC 3454 to the IETF and advocate for their proposal. I don't care strongly which solution is chosen, if there is a good migration plan to the new idea. Meanwhile, implementors will route around the damage and pick their own solutions. Regards, Simon
