[regext] AD review for draft-ietf-regext-login-security-04

[Barry Leiba <[e-mail]>]

I have mostly editorial comments that I hope you’ll consider, but that will
not block anything.  My comment below for Section 4.1 is, though, something
I want to discuss before I start last call.

— Section 1.1 —
Please use the new BCP 14 boilerplate and references; see RFC 8174

  In examples, "C:" represents lines sent by a protocol client and "S:"
   represents lines returned by a protocol server.  Indentation and
   white space in examples are provided only to illustrate element
   relationships and are not a REQUIRED feature of this protocol.

This is not a BCP 14 key word, and should be “required” in lower case.

— Section 2 —
For other similar regext documents, ADs have suggested that the
compatibility/migration recommendations be left in the document for
publication, rather than asking the RFC Editor to remove them.  Unless
there’s a good reason not to publish this section, please remove the
request to the RFC Editor.

— Section 3.1 —

   There MAY be multiple
   events returned that provides information for the client to address.

“provide”

   The <loginSec:event> MAY include a free form description.

There should be a hyphen in “free-form” here and elsewhere when it’s used
as a modifier.

   The enumerated list of "type" values include:

“includes”

       "password":  Identifies a password expiry event, where the
           password expires in the future or has expired based on the
           "exDate" date and time.
       "certificate":  Identifies a client certificate expiry event,
           where the client certificate will expire at the "exDate" date
           and time.

Why are these worded differently?  Is there a reason they do not both say,
<< where the [thing] has expired or will expire at the “exDate” date and
time. >> ?

   "lang":  Identifies the language of the free form description if the
       negotiated language is something other than the default value of
       "en" (English).

This seems to imply that it should never be set to “en”.  If that isn’t
what’s meant, it might be better said as, << Identifies the language of the
free-form description.  The default is “en” (English). >>.

   Example login security event for a password expiring in a week:

There’s no context for “in a week.”  How about this?: << Example login
security event for password expiration, where the current date is
2018-03-26: >>
(And similarly for the related example in Section 4.1.)

— Section 4.1 —

   <loginSec:pw>:  OPTIONAL plain text password that is case sensitive,
       has a minimum length of 6 characters, and has a maximum length
       that is up to server policy.  All leading and trailing whitespace
       is removed, and all internal contiguous whitespace that includes
       #x9 (tab), #xA (linefeed), #xD (carriage return), and #x20
       (space) is replaced with a single #x20 (space).  This element
       MUST only be used if the [RFC5730] <pw> element is set to the
       "[LOGIN-SECURITY]" value.

Two things here:

1. Are there any limitations on valid characters other than the four
mentioned?  Is there any server policy involved?

2. What is the reason for collapsing those, four characters, and not
allowing a password to actually contain, say, a tab, or three consecutive
spaces?  What about all the other Unicode characters that represent spaces
in various forms, or zero-length characters?

—
Barry


On Fri, Oct 25, 2019 at 9:44 AM James Galvin via Datatracker <
[e-mail]> wrote:

> James Galvin has requested publication of
> draft-ietf-regext-login-security-04 as Proposed Standard on behalf of the
> REGEXT working group.
>
> Please verify the document's state at
> https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/
>
>