At 12:03 AM 3/22/2006, Russ Housley wrote:
>Kurt:
>
>Would text like the following (which is largely stolen from draft-ietf-tls-psk) solve your concern:
No. While the language does address part of the question:
how/where canonical of the user_principal_name
string is performed?
it neither addresses this question:
how/where canonical of the domain_name
string is performed?
nor address the question:
what character set/encoding is used on the wire in
transferring these character strings?
I also suspect that the selection of SASLprep here, which
is intended to be used for simple usernames and passwords,
is appropriate for all of the user_principal_name string.
My understanding is that the user_principal_name is
composed of both a simple username part and a domain
part. Components of the latter likely should instead
be prepared by nameprep (if allowed to carry IDNA
components). Also, as the user part of the
user_principal_name is, it appears from casual
examination of various MS documents, to be
case insensitive, SASLprep should not be used.
Kurt
>This document does not specify how the server stores the user_principal_name, or how exactly it might be used to locate a certificate. For instance, it might be appropriate to do a case-insensitive lookup. It is RECOMMENDED that the server processes the user_principal_name with a stringprep profile [STRINGPREP] appropriate for the identity in question, such as SASLprep [SASLPREP].
>
>Russ
>
>At 12:19 PM 3/21/2006, Kurt D. Zeilenga wrote:
>>At 11:06 AM 3/21/2006, Stefan Santesson wrote:
>>>Kurt,
>>>
>>>I've spent some time over this topic with Russ Housley and Paul Hoffman
>>>here at the IETF and the conclusion is that we should not specify any
>>>granular encoding or matching rules for the hints.
>>>
>>>The client's use of the name hint requires the client to know its
>>>account name and as such the client will also know in what form the
>>>server needs it.
>>
>>What about character set/encoding?
>>
>>- Kurt
>>
>>>The client should never send the name hint in a way where the server
>>>needs to process it in order to map the hint to an account.
>>>
>>>There reference will be fixed (or removed).
>>>
>>>Stefan Santesson
>>>Program Manager, Standards Liaison
>>>Windows Security
>>>
>>>
>>>> -----Original Message-----
>>>> From: Kurt D. Zeilenga [mailto:Kurt@xxxxxxxxxxxx]
>>>> Sent: den 7 mars 2006 18:35
>>>> To: ietf@xxxxxxxx
>>>> Subject: draft-santesson-tls-ume Last Call comment
>>>>
>>>> I note the IETF last call was issued for rev. 2. That
>>>> revision no longer exists, hence I reviewed rev. 3.
>>>>
>>>> This document specification of a "User Principal Name",
>>>> I believe, is inadequate.
>>>>
>>>> The I-D indicates that a user_principal_name is a sequence of
>>>> 0 to 65535 bytes in the form of user@domain. However,
>>>> such a form implies the value is a character string,
>>>> but there is no mention of what character set/encoding
>>>> is used here. I would think interoperability
>>>> requires both client and server to have a common
>>>> understand of what character set/encoding is to
>>>> be used. Additionally, there is no discussion
>>>> of UPN matching. Are byte sequences that differ
>>>> only due to use of different Unicode normalizations
>>>> to be consider the same or differ? Are values
>>>> case sensitive or not? etc..
>>>>
>>>> The domain_name field suffers not only from the
>>>> above problem, but is flawed due to use of the
>>>> outdated "preferred name syntax" of RFC 1034.
>>>> This syntax doesn't allow domains such as
>>>> 123.example. The text should likely reference
>>>> the RFC 1123 which updates the "preferred name
>>>> syntax" for naming hosts.
>>>>
>>>> Additionally, no mention of how International
>>>> domain names (IDNs) are to be handled.
>>>>
>>>> I recommend ABNF be used to detail the syntax
>>>> of each of these fields and that the I-D detail
>>>> how values of these fields are to be compared.
>>>> Additionally, the I-D should discuss how IDNs
>>>> are to be handled.
>>>> -- Kurt
>>>>
>>>>
>>>> _______________________________________________
>>>> Ietf mailing list
>>>> Ietf@xxxxxxxx
>>>> https://www1.ietf.org/mailman/listinfo/ietf
>>
>>
>>_______________________________________________
>>Ietf mailing list
>>Ietf@xxxxxxxx
>>https://www1.ietf.org/mailman/listinfo/ietf
>
>
>_______________________________________________
>Ietf mailing list
>Ietf@xxxxxxxx
>https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf