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(_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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf