Patrick, The trimming and collapsing of whitespace in draft-ietf-regext-login-security is a feature of the XML schema “token” type that exists today based on what’s defined in RFC 5730. There is no issue with complying with the NIST recommendation, where the use of the trimming and collapsing of the XML schema "token" type is needed to address XML formatting issues (e.g., XML pretty printing). Multiple consecutive space characters will be replaced with a single character by the XML parser. I don't see the applicability of PRECIS for draft-ietf-regext-login-security.
Thanks, -- JG James Gould Distinguished Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 11/4/19, 11:26 AM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: On Tue, Oct 29, 2019, at 14:20, Barry Leiba wrote: > Jim, thanks for accepting most of my edits and for addressing my > question about the password characters. It just seems odd to me that > you can't use << my#x20#x20#x20pw >> as a password, but you can use, > say, << my#x20#xA0#x20pw >> (or any of a number of other variations > with other Unicode space characters. But the reason sounds... > reasonable, so: post a rev and I'll last-call it. As a data point, the current NIST recommendations on passwords: https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length. All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well. To make allowances for likely mistyping, verifiers MAY replace multiple consecutive space characters with a single space character prior to verification, provided that the result is at least 8 characters in length. Truncation of the secret SHALL NOT be performed. For purposes of the above length requirements, each Unicode code point SHALL be counted as a single character. </quote> Note the "MAY replace multiple consecutive space characters". Also, as I hinted in the past during discussion on this extension, the whole area of "internationalized" identifiers, such as usernames and passwords has been explored in the PRECIS ("Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols") set of RFCs, and specifically RFC 8265 "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords". In short it defines an "OpaqueString" profile, to be applied for passwords. Among other things it has this: . Additional Mapping Rule: Any instances of non-ASCII space MUST be mapped to SPACE (U+0020); a non-ASCII space is any Unicode code point having a Unicode general category of "Zs", with the exception of SPACE (U+0020). As was the case in RFC 4013, the inclusion of only SPACE (U+0020) prevents confusion with various non-ASCII space code points, many of which are difficult to reproduce across different input methods. (note also RFC8264 §5.3 for a discussion about spaces) I am still of the opinion that we should have used/referenced that work more. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
