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

["Patrick Mevzek" <[e-mail]>]

On Tue, Nov 5, 2019, at 16:37, Gould, James wrote:
> The trimming and collapsing of whitespace in 
> draft-ietf-regext-login-security is a feature of the XML schema “token” 
> type that exists today based on what’s defined in RFC 5730.  

I know.

I was just going into Barry's way, as it makes no sense to me as well to not allow two multiple U+0020 spaces, but we allow U+00A0 U+0020, which is a variation of the same thing.

We are "mostly" safe because all of those are typically not user handled passwords,
as they are used for machine to machine connections, so "mostly" safe from display
and human handling issue. But just "mostly", not completely.

> There is 
> no issue with complying with the NIST recommendation, where the use of 
> the trimming and collapsing of the XML schema "token" type is needed to 
> address XML formatting issues (e.g., XML pretty printing).

I did not say that there is an issue there, nor that following this recommendation is good
or bad.
Note however it remains vague as saying "*THE* space character" (emphasis mine) and
"UNICODE characters should be accepted as well" and these 2 sentences do not mix well
as Unicode defines more than one "space" character...

> I don't see the applicability of PRECIS for 
> draft-ietf-regext-login-security.  

I am sorry if I failed to show its applicability, but for me it is absolutely applicable to it. It gives both a framework and examples.
The framework allows each application (that is each protocol) to properly define
"classes" of strings, such as the one for usernames or the one for passwords,
and to define the rules in it.
This is completely orthogonal to the final schema used to encode the stuff
in some framing protocol, such as XML here.

But we had this debate before as I brought the issue, you already said it
is not relevant in your opinion, and the draft is now near standardization,
so too late and useless to discuss it again I think. I didn't want to bring the
issue again, I was just leaning towards Barry's opinion that the constraints are
"strange" (yes they come from the XML schema datatypes, but that does not define
the semantic of the field, which is not just an XML token, but really a password,
which is all the discussion of PRECIS in fact).

-- 
  Patrick Mevzek
  [e-mail]