[regext] Roman Danyliw's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-regext-login-security-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 3.1.  When @type=”stat” and the name of the stat is set in @name,
how does a client know the semantics of this stat?  Is that negotiated out of
band?

** Section 4.1.  Per  <loginSec:userAgent>, how are the clients supposed to
generate the app, tech or os strings in a way that the server will understand?
If this is out of scope, please just say so.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Alissa Cooper’s DISCUSS position.

** Section 3.1.  Is a @value required when @type=”cipher” or
@type=”tlsProtocol”? The examples in Section 4 show the use of @value.  Also,
what format should be used to express the cipher or tlsProtocol?

** Section 3.1.  Per the description of event@lang, please cite the language
format as coming from Section 3.4.3[W3C.REC-xmlschema-2-20041028]

** Section 4.1.  Per the children of <loginSec:userAgent>, would supporting a
more formal approach also be useful -- using SWID (ISO/IEC 19770-2:2015) or
COSWID (draft-ietf-sacm-coswid)?

** Section 4.1. Per pw and newPW’s descriptions of “all internal continuous
whitepaces … is replaced with a single #x20” – is this intentionally precluding
a password with a double space?

** Section 4.1. Per “If non-ASCII characters are supported with the plain text
password, then use a standard for passwords with international characters, such
as the OpaqueString PRECIS profile in [RFC8265].”, if non-ASCII characters are
supported, how does a client know which approach to take with a given server in
an interoperable.  RFC8265 is a helpful reference but the current text seems to
provide no guidance.

** Section 5.  Please note in the Section 5 introduction that the blob between
the BEGIN and END tags in Section 5.1 are formally specified by XML Schema.

** Section 8.  Please note that the Security Considerations of RFC5730 apply
and that this document enhances these security services.

** Editorial Nits
-- Section 1.  Typo.  s/pssword/password/