Dear Julian,
> The key issue aren't the specs, but what implementations do. So we need to
> agree on what they should do and try to get *that* implemented, Otherwise the
> whole exercise is completely academic.
Your point is really understood and agreed.
We need a thorough discussion for requirement strength
of string preparation (including Unicode normalization)
for Basic and Digest schemes.
There is a tough trade-off: if the requirement is too weak,
it decreases interoperability and the users will experience
a frustrating failed authentications; if too strong, implementors
will not just follow it. We need to find a good mid-point.
My current position is not actually insisting PRECIS-based
handling for a MUST requirement of UTF-8 Basic.
My current preference is, assuming that the majority of people
think MUST-required PRECIS handling too strong, the following:
"to require NFC Unicode normalization a SHOULD, and some PRECIS
handling a MAY with stating it's a good practice to do."
The reason is: Unicode normalization is hard to be
worked-around by end users; other PRECIS preparations
are generally workaround-able by users by avoiding
some characters in their input.
(Oppositely, if the majority thought that UTF-8 Basic should do
a correct PRESIS-based preparation as a MUST for the
best interoperability assurance, I would happily follow it.)
*
Regarding general issue on string preparation for HTTP authentication,
I have two strong opinions around here:
1) "single solution":
Within HTTPAUTH technology area, There should not be
randomly many ways of preparations with minor differences
with no justifiable reasons.
There should be a single default way of preparation which will be
used for almost all HTTP-related authentications *if they do preparation*,
unless there are some other dependencies
(like SASLprep for SASL-backed schemes.)
2) "new good things for new technologies":
For *new* auth schemes, for which we can expect they will
have a new implementation efforts anyway,
we have a motivation for MUST-or-SHOULD
requirement of correct I18N handling.
(It is something like an exercise anyway,
so we may try to do the "correct" thing.)
However, for retrofitting schemes like Basic and Digest,
I suspect that the normative requirements for correct I18N may be
too strong. I guess we may need to allow implementors
to "ignore" such complex handling, and still saying
their implementations are compliant to the new UTF-8 Basic.
That's why, in my HTTPAUTHprep draft, I said it will serve
as a dual-purpose document, both as a normative reference
for new things and a best practice for other existing schemes.
(See Section 1.2 of my draft, understanding the phrase is not yet polished).
2014-02-05 Julian Reschke <[email protected]>:
> On 2014-02-05 10:21, Yutaka OIWA wrote:
>>>>
>>>> 2) As previously agreed upon, merge the two specs but only do some
>>>> handwaving with respect to normalization for now.
>>>
>>>
>>> I like 2).
>>
>>
>> Given taking 2), is it technically possible to make an "update" to
>> the merged Basic-auth spec by a PRECIS profile document defined
>> later (but sooner)?
>>
>> # I think, if any, the update may be something to "RECOMMEND"
>> # or to say "SHOULD" do, or possibly "MAY" do, but not to say "MUST",
>> # considering very pervasive and pragmatic nature of the Basic
>> authentication.
>
>
> We're going for Proposed Standard here. We can always revise the document
> again, change this, and go to Full Standard later on.
>
> The key issue aren't the specs, but what implementations do. So we need to
> agree on what they should do and try to get *that* implemented, Otherwise
> the whole exercise is completely academic.
>
> Best regards, Julian
>
--
Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group
Research Institute for Secure Systems (RISEC)
National Institute of Advanced Industrial Science and Technology (AIST)
Mail addresses: <[email protected]>, <[email protected]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5]
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
