Patrick,


We are discussing how to express the password format policy in 
draft-gould-regext-login-security-policy, which uses a Perl-compatible Regular 
Expression (PCRE).  The use of a PCRE was discussed at the REGEXT Interim 
Meeting 2018OCT16  
(https://mailarchive.ietf.org/arch/msg/regext/3VWY7MlELXmEu5GdQbGnm70Im30).  I 
believe that a PCRE can effectively express the password format policy for EPP; 
although there may be exceptions to the rule.  Below I include an example EPP 
password format policy from draft-gould-regext-login-security-policy that uses 
a PCRE with a matching description.  A client can generate and pre-verify a new 
EPP password by leveraging the PCRE.



     <loginSecPolicy:pw>

       <loginSecPolicy:expression>

         (?=.*\d)

         (?=.*[a-zA-Z])

         (?=.*[\x21-\x2F\x3A-\x40\x5B-\x60\x7B-\x7E])

         (?!^\s+)

         (?!.*\s+$)

         (?!.*\s{2,})

         ^[\x20-\x7e]{16,128}$

       </loginSecPolicy:expression>

       <loginSecPolicy:description>

         16 to 128 printable characters (alphanumeric, space, and

         special characters) with at least one number, letter, and

         special character, with no leading or trailing whitespace,

         and with no consecutive spaces.

       </loginSecPolicy:description>

     </loginSecPolicy:pw>



I believe your password format policy can be expressed via a PCRE, but I’ll 
leave that exercise to you.



Currently draft-gould-regext-login-security-policy has the 
<loginSecPolicy:pw><loginSecPolicy:expression> element defined as required.  
The question is whether there are existing or planned EPP password format 
policies that cannot be expressed via a PCRE.  If so, we can adjust 
draft-gould-regext-login-security-policy to support providing an external URL 
reference or make the <loginSecPolicy:pw><loginSecPolicy:expression> element 
optional, so that the server only provides the description.  Other possible 
password policy elements are not defined in 
draft-gould-regext-login-security-policy, like use of prior passwords or use of 
insecure words.  Should such non-format policies be defined in 
draft-gould-regext-login-security-policy and if so what policies should be 
defined?



Thanks,

—

JG







James Gould

Distinguished Engineer

[email protected]



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com <http://verisigninc.com/>



On 4/9/19, 6:06 PM, "regext on behalf of Patrick Mevzek" 
<[email protected] on behalf of [email protected]> wrote:







    On Tue, Apr 9, 2019, at 16:37, Gould, James wrote:

    > I’m not claiming that all password policies can be condensed into a

    > regular expression, but at a minimum the syntactical policy can.



    Ok.

    I am still curious to know the valid regex encoding this policy for example:



    - any character from the Unicode Latin script

    - at least one uppercase, one lowercase, one digit, and one punctuation 
character (in no specific order)

    - no repeated sequence of two or more characters

    - no given character repeated in sequence

    - between 17 and 33 characters long in total



    --

      Patrick Mevzek

      [email protected]



    _______________________________________________

    regext mailing list

    [email protected]

    https://www.ietf.org/mailman/listinfo/regext


_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext

Reply via email to