On Tue, Jun 5, 2018, at 17:11, Gould, James wrote: > JG - The reason for a '[LOGIN-SECURITY]' constant value in RFC 5730 <pw>
[..] Yes, but my comment was both to propose other values than this string and even alternate mechanisms. Please have a look and let me know. > There may be a better constant value to use or another > mechanism that is compliant with RFC 5730, while allowing for overriding > the password value in the extension. This is indeed the subject on the table. > - for loginSec:pw/loginSec:newPw I am not a fan of specifying > minimum length, because if you remove all maximum length constraint in > the schema for the maximum, by symmetry I would do the same for the > minimum, leaving both to pure policy choices by the server (the > "sensible" minimum depends of course on the number of different > characters allowed, it would not be the same value when accepting only > ASCII or when accepting "any" Unicode characters > > JG - I don't believe that the security would be enhanced by removing the > minimum length. RFC 5730 had a minimum of 6 characters and I bumped it > up to a minimum of 8 characters to match current password security > guidelines. NIST defines the minimum length as 8 characters. I never said the security would be "enhanced" I am saying that if part of the goal of the new extension is to remove previous artifical limits on length, it might as well let the policy decide what good vales are, instead of the protocol. Defining a minimum length without defining the space of characters allowed nor miscelleanous rules regarding complexity seems defeating the purpose, you just enshrine some arbitrary numbers as sacred cows. And the next iteration of the extension will again need to lift the value. > - I would also not put anything here related to what characters are > allowed or not. I would instead defer to the PRECIS framework (RFC7564) > and more specifically section 4 of RFC8265. At least as a base, using > OpaqueString and then building one more constrained on top of it if it > is really deemed important > (passwords here are typically not seen nor managed by humans, so I > think they need less strict rules than when handled by humans, and I see > no problems per se with spaces... I have seen far more trouble when > people try to use < or & in a password and forgetting to encode it as > those are specific characters in an XML streams). > > I know that RFC5730 does the same thing, but it was written before PRECIS. > So now I think we should instead build on it. > > JG - The rules around the leading / trailing whitespace and the > contiguous whitespace is based on the selection of the XML schema > "token" type. We could consider changing the type, but that is the type > defined in RFC 5730. The login security extension simply removes the > maximum length constraint and increases the minimum length constraint > from 6 characters to 8 characters to meet current security guidelines. Please have a look again at what I wrote and the details about PRECIS. I still think that this is not core EPP and hence we should defer to other RFCs dealing with passwords for recommendations instead of trying to invent new ones. This has nothing to do with the XML schema type. And I am still not convinced that whitespaces are a problem here (again, because the password is entered by a program and not by a human), but this is a bikeshedding point. -- Patrick Mevzek _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
