Patrick,
The use of the PCRE in draft-gould-regext-login-security-policy was solely
meant to define the format policy. The other password policies can be able to
be defined in a consumable manner. For "Passwords should be changed every 12
months and should be different than the previous 6 passwords.", the changing of
the password every 12 months would be covered with the policy definition of the
"password" security event, as in:
<loginSecPolicy:event type="password">
<loginSecPolicy:level>warning</loginSecPolicy:level>
<loginSecPolicy:level>error</loginSecPolicy:level>
<loginSecPolicy:exDate>true</loginSecPolicy:exDate>
<loginSecPolicy:exPeriod>P1Y</loginSecPolicy:exPeriod>
<loginSecPolicy:warningPeriod>P15D</loginSecPolicy:warningPeriod>
<loginSecPolicy:errorAction>login</loginSecPolicy:errorAction>
</loginSecPolicy:event>
Covering the policy associated with the use of the previous 6 passwords is
currently not covered by draft-gould-regext-login-security-policy, but I can
add support for it.
Thanks,
--
JG
James Gould
Distinguished Engineer
[email protected]
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
On 7/25/19, 12:58 AM, "regext on behalf of Patrick Mevzek"
<[email protected] on behalf of [email protected]> wrote:
On Mon, Jul 8, 2019, at 13:57, Gould, James wrote:
> Use of the PCRE to define the password format policy is meant for
> machine consumption, so "easy to read" is not a factor. The
> description is meant to be human readable and "easy to read".
>
> Do you have a specific example of an EPP password format that cannot be
> defined using a PCRE?
I think you are switching between format and policy while I am clearly
stating
that even if a regex could encode (most, but I would not guarantee all)
formats,
it certainly can not deal with policy in all generic cases.
Here is an example of a policy from a registry I am sure you know very well:
"Passwords should be changed every 12 months and should be different than
the previous 6 passwords."
This can not be reflected in a regular expression.
You can put that as free text anywhere: then you do not achieve more than
current documentation for human consumption
Or you decide to try to model things like that with a specific XML schema,
and while you technically could, I highly doubt you can make that flexible
enough to handle
all registries different policies.
So in the end, the goal to define the policy around passwords is not met
for me
(just because it can't be met, so it is maybe just a matter of aligning the
goal),
, while the goal to define the syntax of passwords can be met.
I think we just disagree on the question if that second goal is good enough
or not.
But I would at least suggest that the draft is clearer on what it defines,
policy or format.
--
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
