Kurt:
Would text like the following (which is largely stolen from
draft-ietf-tls-psk) solve your concern:
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(_at_)OpenLDAP(_dot_)org]
>> Sent: den 7 mars 2006 18:35
>> To: ietf(_at_)ietf(_dot_)org
>> 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(_at_)domain(_dot_) 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(_at_)ietf(_dot_)org
>> https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf