Hi James, On Wed, Apr 10, 2019, at 12:54, Gould, James wrote: > > I did the exercise of defining the PCRE the matches your password > format policy, which can be verified using https://regex101.com. The > PCRE is defined below: > > > *(?=.*[A-Z])(?=.*[a-z])(?=.*\d)(?=.*[.,:;!?-])(?!.*(.{2,}).*\1)(?!.*(.)\2)^[\x00-\x7F]{17,33}$*
Thanks to have taken the time to prove me wrong, I bow in front of that, but maybe you could agree that it is neither easy to write, nor to read, and that as beautiful as it may be in general, it still can not cover 100% of cases, because the world is like it is and regular expressions solve many problems but not all. So I would still claim that a regex will not be able in all cases to encode the registry policy on passwords but you can say that it will code for the most frequent cases/the more important subcases, and additions can be expressed in human documents, such as it is today, so regex already go a little further than current situation. > Should the <loginSecPolicy:pw><loginSecPolicy:expression> element be > made optional to address a password format policy that a PCRE cannot be > created for? I do not think anyone follows me there, so you can probably keep it mandatory... and a registry can publish its regex to be ^.*$ which will accomodate all cases. > If a server cannot define their password format policy using a PCRE, I > believe the policy may be too complex and should be re-evaluated. Maybe, but that is a business/policy problem not a protocol problem. I would disapprove any IETF document stating which passwords policies are too complex or not and need to be re-evaluated. Besides generic discussion on strength based on the count of possible different values. > Should the <loginSecPolicy:pw> element support a method to reference an > external resource (e.g., url) that defines the password policy > information? That would then be only for human consumption, an EPP client won't be doing anything with it, so providing that URL through EPP does not provide any gain I believe. -- Patrick Mevzek [email protected] _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
