Russ, RFC 4279 has one additional requirement that is quite important in this context: "identity MUST be first converted to a character string, and then encoded to octets using UTF-8". If my user name contains the "Latin small letter A with diaeresis", it's important to specify whether the bytes-on-the-wire should contain that in ISO 8859-1, Windows code page 1254, UTF-8 encoded Unicode, little-endian UTF-16 encoded Unicode, or big-endian UTF-16 encoded Unicode. In other words, I don't think treating the identity as an _octet_ string is a good approach. The UPN looks more like a _character_ string to me, and then we need to specify how the characters get encoded to octets. Just assuming that the client knows what encoding the server is expecting sounds like a recipe for interoperability problems... (However, I do agree with Stefan that we probably should not specify any more granular matching rules or ABNF...) Best regards, Pasi > -----Original Message----- > From: ext Russ Housley [mailto:housley@xxxxxxxxxxxx] > Sent: 22 March, 2006 08:04 > To: Kurt D. Zeilenga; Stefan Santesson > Cc: ietf@xxxxxxxx > Subject: RE: draft-santesson-tls-ume Last Call comment > > 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@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