Jim, thanks for accepting most of my edits and for addressing my question about the password characters. It just seems odd to me that you can't use << my#x20#x20#x20pw >> as a password, but you can use, say, << my#x20#xA0#x20pw >> (or any of a number of other variations with other Unicode space characters. But the reason sounds... reasonable, so: post a rev and I'll last-call it.
b On Tue, Oct 29, 2019 at 3:15 PM Gould, James <jgo...@verisign.com> wrote: > Barry, > > > > Thank you for the review and feedback. I provide my responses to your > feedback inline below. I will post draft-ietf-regext-login-security-05 > with the changes based on your feedback. > > > > -- > > > > JG > > > [image: cid:image001.png@01D255E2.EB933A30] > > > *James Gould *Distinguished Engineer > jgo...@verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > *From: *regext <regext-boun...@ietf.org> on behalf of Barry Leiba < > barryle...@computer.org> > *Date: *Tuesday, October 29, 2019 at 12:10 AM > *To: *"draft-ietf-regext-login-security....@ietf.org" < > draft-ietf-regext-login-security....@ietf.org> > *Cc: *"regext@ietf.org" <regext@ietf.org> > *Subject: *[regext] AD review for draft-ietf-regext-login-security-04 > > > > 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 > > > > JG – That will be fixed. > > > > 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. > > > > JG – That will be changed. > > > > — 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. > > > > JG – I will remove the note to the RFC Editor so that the section remains. > > > > — Section 3.1 — > > > > There MAY be multiple > > events returned that provides information for the client to address. > > > > “provide” > > > > JG – This will be fixed. > > > > 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. > > > > JG – This will be fixed. There are two occurrences of “free form” that > will be changed to “free-form” in section 3.1. > > > > The enumerated list of "type" values include: > > > > “includes” > > > > JG – “include:” will be changed to “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. >> ? > > > > JG – The wording is different, since if the certificate expires, the > connection will fail prior to getting to the login command. If the > password expires, the client can execute the login command and therefore > the server can include the security event post the expiry of the password > in the login response. Therefore the server can only warn the client of an > expired certificate in the login response prior to its expiry, but the > server can inform the client of an expired password in the login response > prior to or after the expiry of the password. > > > > "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). >>.. > > > > JG – This language was borrowed from the various EPP RFCs include RFC > 5731. There is no intent to disallow inclusion of the “lang” attribute if > the value is “en”. I’ll change it based on your proposed language to make > it clearer, but with “negotiated language” instead of “language”, since the > greeting and the login command negotiate the language to use. > > > > 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.) > > > > JG – Yes, that will cover future dates, I’ll make the change. I believe > the correct current date is 2018-03-25 for an expiry on 2018-04-01 in a > week. I’ll make a similar change for the 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? > > > > JG – There are no additional constraints for valid characters in the draft > or in RFC 5730. The constraints defined in the draft are based on the > selection of the XML schema “token” type, which matches the type in RFC > 5730. The XML schema “token” type constraints are explicitly defined in > the draft based on feedback from the Working Group. Server policy will > define the specific password constraints (e.g., characters, minimum length, > maximum length, restricted words) for the server. An example is the use of > draft-gould-regext-login-security-policy to define the password rules in > EPP. > > > > 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? > > > > JG – One goal of the draft is remove the 16 character maximum constraint > in RFC 5730 while supporting the same XML schema type of “token”. The > trimming and collapsing of whitespace is a feature of the XML schema > “token” type that exists today based on what’s defined in RFC 5730. > > > > — > > Barry > > > > > > On Fri, Oct 25, 2019 at 9:44 AM James Galvin via Datatracker < > nore...@ietf.org> 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 regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
