From: Peter Saint-Andre <stpeter@mozilla.com>
To: precis@ietf.org
References: <CAN2symj4jCLiM0y52Ey07rQSrh8ui4x9gZjmc53WbEYfWcoZtA@mail.gmail.com>
 <10b17ef3-a34a-5fe2-3484-e86c4005a5a0@mozilla.com>
Openpgp: preference=signencrypt
Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata=
 xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P
 Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN
 jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU
 FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB
 bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H
 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw
 CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO
 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp
 EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS
 CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu
 dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl
 YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY
 f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T
 D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP
 SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4
 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX
 wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu
 fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq
 oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t
 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0
 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp
 jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu
 jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK
 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18
 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk
 oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7
 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN
 wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG
 VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz
 ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO
 vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51
 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp
 BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR
 Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY
 CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9
 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr
 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM
 W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq
 cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN
 Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx
 /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT
 V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V
Message-ID: <e9e45d0a-5593-962d-690a-53dd7a33f07c@mozilla.com>
Date: Wed, 9 May 2018 15:57:30 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0)
 Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <10b17ef3-a34a-5fe2-3484-e86c4005a5a0@mozilla.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="GamjWl8ojc6djDyyidJvzsIA5rJkDdYld"
Archived-At: <https://mailarchive.ietf.org/arch/msg/precis/Q6xIxRhDAWZfqYjIa1EBojdmSRI>
Subject: Re: [precis] RFC 8264 / 8265 Order of rules
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--GamjWl8ojc6djDyyidJvzsIA5rJkDdYld
Content-Type: multipart/mixed; boundary="SWmzV9w0eF48O8wYsAxLk9gDwczD8s3eX";
 protected-headers="v1"
From: Peter Saint-Andre <stpeter@mozilla.com>
To: precis@ietf.org
Message-ID: <e9e45d0a-5593-962d-690a-53dd7a33f07c@mozilla.com>
Subject: Re: [precis] RFC 8264 / 8265 Order of rules
References: <CAN2symj4jCLiM0y52Ey07rQSrh8ui4x9gZjmc53WbEYfWcoZtA@mail.gmail.com>
 <10b17ef3-a34a-5fe2-3484-e86c4005a5a0@mozilla.com>
In-Reply-To: <10b17ef3-a34a-5fe2-3484-e86c4005a5a0@mozilla.com>

--SWmzV9w0eF48O8wYsAxLk9gDwczD8s3eX
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 5/4/18 12:40 PM, Peter Saint-Andre wrote:
> On 3/14/18 10:04 AM, Paul Crovella wrote:
>> Followup question on
>> https://www.ietf.org/mail-archive/web/precis/current/msg01445.html
>>
>>> implementations should follow the order of rules in Section 7 of RFC =
8264.
>>
>> Should string class validation then be moved from the preparation step=

>> of all profiles to the end of enforcement? I don't know whether
>> there'd be a practical effect on profiles using the FreeformClass
>> string class (OpaqueString and RFC 8266's Nickname), or if there's the=

>> potential to be, but it'd be nice to know where to do things.
>=20
> The intent in my head when working on RFC 8265 & RFC 8266 was to define=

> the set of rules for a profile and then in each subsection (preparation=
,
> enforcement, comparison) specify each rule to be applied for that
> operation, without having them be additive (i.e., don't say in the
> enforcement operation than you first do everything in preparation, then=

> some things in addition). Clearly, this did *not* get translated into
> the final text because I failed in my responsibility as a spec author.
>=20
> I will send proposed text for errata to this list sometime soon.

I have in mind something like the following for Section 3.3 of RFC 8265.

###

OLD

3.3.3.  Enforcement

   An entity that performs enforcement according to this profile MUST
   prepare an input string as described in Section 3.3.2 and MUST also
   apply the following rules specified in Section 3.3.1 in the order
   shown:

   1.  Case Mapping Rule

   2.  Normalization Rule

   3.  Directionality Rule

   After all of the foregoing rules have been enforced, the entity MUST
   ensure that the username is not zero bytes in length (this is done
   after enforcing the rules to prevent applications from mistakenly
   omitting a username entirely, because when internationalized strings
   are accepted, a non-empty sequence of characters can result in a
   zero-length username after canonicalization).

   The result of the foregoing operations is an output string that
   conforms to the UsernameCaseMapped profile.  Until an implementation
   produces such an output string, it MUST NOT treat the string as
   conforming (in particular, it MUST NOT assume that an input string is
   conforming before the enforcement operation has been completed).

3.3.4.  Comparison

   An entity that performs comparison of two strings according to this
   profile MUST prepare each string as specified in Section 3.3.2 and
   then MUST enforce the rules specified in Section 3.3.3.  The two
   strings are to be considered equivalent if and only if they are an
   exact octet-for-octet match (sometimes called "bit-string identity").

   Until an implementation determines whether two strings are to be
   considered equivalent, it MUST NOT treat them as equivalent (in
   particular, it MUST NOT assume that two input strings are equivalent
   before the comparison operation has been completed).

NEW

3.3.3.  Enforcement

   An entity that performs enforcement according to this profile MUST
   apply the following rules specified in Section 3.3.1 in the order
   shown:

   1.  Width Mapping Rule

   2.  Case Mapping Rule

   3.  Normalization Rule

   4.  Directionality Rule

   After all of the foregoing rules have been enforced, the entity MUST
   ensure that the username is not zero bytes in length (this is done
   after enforcing the rules to prevent applications from mistakenly
   omitting a username entirely, because when internationalized strings
   are accepted, a non-empty sequence of characters can result in a
   zero-length username after canonicalization).

   The result of the foregoing operations is an output string that
   conforms to the UsernameCaseMapped profile.  Until an implementation
   produces such an output string, it MUST NOT treat the string as
   conforming (in particular, it MUST NOT assume that an input string is
   conforming before the enforcement operation has been completed).

3.3.4.  Comparison

   An entity that performs comparison of two strings according to this
   profile MUST apply the following rules specified in Section 3.3.1
   in the order shown:

   1.  Width Mapping Rule

   2.  Case Mapping Rule

   3.  Normalization Rule

   4.  Directionality Rule

   The two strings are to be considered equivalent if and only if they
   are an exact octet-for-octet match (sometimes called "bit-string
   identity").

   Until an implementation determines whether two strings are to be
   considered equivalent, it MUST NOT treat them as equivalent (in
   particular, it MUST NOT assume that two input strings are equivalent
   before the comparison operation has been completed).

###

Would this clarify string handling enough to be useful?

/psa


--SWmzV9w0eF48O8wYsAxLk9gDwczD8s3eX--

--GamjWl8ojc6djDyyidJvzsIA5rJkDdYld
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlrzbsoACgkQZWGMGH9o
FKnBQhAA1d3hKJkI96LhG0NIFNngRdfYFPgk3ZFtpW8LkGfAZIMMh3KDl+JR98jN
N43tkGVy3iiqE/v87BUtbdo2YHx6gQVyhQYmGUA3vvSzmtavowSgMF5/E6fTzlAR
UIEjY7SCGX1IFz04/VbvnYrbtFrv5EcrNfxhqLjtOJKx9OYazixZocG4un0mrOiq
tSt0Z8geB4gJX/O4cbs9G2hhAZPRgHrdOGkgQVAC2xRcsQ/anCnWFTXq+QJzfJQU
urpXoyoSDUOmdkI+nhKVaZ5ZpBAOr91KmbGUthL36F9+8ElUyQFTskhvc5UFZbDE
2/A2GQwlltxDUvFRUAqr7eMDfTOl3RZiNzDKqkYLb28GNaJuEoTtUuLgIj94ZU++
mayP4qLQb84tcq69klMUBLIZJxezscJpZdTFH2i6ceBLdfrzl03yMYDytY1CpbKd
I90GayXY5I7BK5YISBDjOxReSD3nKr83yjE6y0RBIrKAzdwtghsRTJlI9XBlyo7p
kgr6vR44CMnmDhAZZLF1mViIJkUKybsX4jLyabBJVQNWdASQNvWPIyLQxE4iCcA5
tSpj0sJmbiVMt9ksHOaP7gwtsovTdj3HsHQZEI+nuIP+cqFkxMWbZroI4rnC5a0A
ePhWF8WzTh8KnHLJE96Gsrv+sPWwhtWN/lqWQpjfqp0sAeCrF30=
=G7Yf
-----END PGP SIGNATURE-----

--GamjWl8ojc6djDyyidJvzsIA5rJkDdYld--