Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Patrick Mevzek <[e-mail]>]

On Mon, Jun 4, 2018, at 22:30, Gould, James wrote:
> The Login Security Extension (draft-gould-regext-login-security) was 
> posted 
> (https://datatracker.ietf.org/doc/draft-gould-regext-login-security/) 

Thanks James, this is nice.

Some comments before really trying to implement it:

- I am not a huge fan of the [LOGIN-SECURITY] token, but I see no good alternatives. Specifically, this variant forbids any later revision of the specification. So I would either argue for the shortname, loginSec-1.0, so that at least it will be backwards compatible or, to be bolder, use RFCXXXX when XXXX will be known...
Or to want to avoid collisions at all cost, I would either go towards something like U+001A (SUBSTITUTE) or U+001B (ESCAPE) repeated 16 times.

Or a completely different route would be to use the XML ID/IDREF mechanism.
I am not 100% sure but maybe the current <pw> could have an xml:IDREF attribute with a path pointing to the new loginSec:pw node which would have the corresponding xml:ID attribute?

- 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

- 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.

-- 
  Patrick Mevzek