Re: [regext] AD review for draft-ietf-regext-login-security-04

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
jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@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-bounces@ietf.org on behalf of pm@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
      pm@dotandco.com

    _______________________________________________
    regext mailing list
    regext@ietf.org
    https://www.ietf.org/mailman/listinfo/regext