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 <
[email protected]> 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/
>
>
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
