RE: draft-santesson-tls-ume Last Call comment
On Sunday, March 26, 2006 02:48:17 PM -0800 Kurt D. Zeilenga [EMAIL PROTECTED] wrote: I note that SASLprep is case-insensitive and hence may not be appropriate for the user portion of a UPN. I think this is a type. SASLprep is case-preserving, and hence may not be appropriate for the user portion of a UPN, if the latter are intended to be case-insensitive. I also think it odd to allow both toUnicode and toASCII domain component forms on the wire. So do I. (I recommend the latter). Why? The toASCII form was designed to allow IDN's to be encoded for use in protocol fields which are very restrictive about what octet strings they can carry; in particular, label fields in the DNS wire protocol. Why do I keep seeing people who insist on using that inefficient encoding in protocol slots which are perfectly capable of carrying UTF-8? That's very much like suggesting the use of base-32 encoding in an 8-bit-clean field. Use of toASCII is appropriate for _existing_ IDN-unaware uses of domain names. I wish someone would explain to me why so many people want to use it for IDN-aware uses in new protocols. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-santesson-tls-ume Last Call comment
First, I think much of my concern is a due to having no clue what a user principal name is in the context of this draft. It seems to be some identifier used in some directory service. The only clue given in the document is that it is a name form defined by Microsoft. It is odd that there is no reference, not even an informative one, to this definition. As I am lacking clue, I doubt I can offer appropriate text provding the (necessary) clue that independent developers will need to produce an interoperable implementation. But I will, nevertheless, try in hopes it help you and other better understand my concerns. It will likely need to be reworked by the I-D authors based upon their understanding of what a UPN is. At 08:47 AM 3/22/2006, Russ Housley wrote: Kurt: Okay. I think I get your point. I'll try one more time, but if that does not satisfy you, then you will have to respond with proposed text. I'm trying to address Pasi's comment too. Based on updates from a previous comment, the document will say: The domain_name parameter, when specified, SHALL contain a domain name in the preferred name syntax, as specified by RFC 1123. I would suggest instead: The domain_name parameter, when specified, provides a DNS [RFC1034][RFC2181] host name [RFC1123] represented as an ASCII [ASCII] character string conforming to the domain production provided in Section 2.1 of [draft-zeilenga-ldap-cosine]. It is also noted that applications supporting Internationalized Domain Names SHALL use the ToASCII method [RFC3490] to produce label components of this domain production. I think that this resolves your concern about the encoding of domain_name. I propose the following text to handle the same concern for user_principal_name: The user_principal_name parameter, when specified, SHALL contain an Unicode UPN, encoded as a UTF-8 string. Now, for the rest: 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 Nameprep [NAMEPREP] for the portion domain portion of UPN and SASLprep [SASLPREP] for the user portion of the UPN. I note that SASLprep is case-insensitive and hence may not be appropriate for the user portion of a UPN. I note that Nameprep has to be applied component wise. I also think it odd to allow both toUnicode and toASCII domain component forms on the wire. The specification should choice one or the other (I recommend the latter). However, based in part with off line discussions with Stefan, I suggest. This document does not detail the syntax or semantics of a User Principal Name beyond that it is a string of UTF-8 encoded Unicode characters (with no required normalization) where at least of these characters is the COMMERCIAL AT (@ U+0040) character. The syntax and semantics of User Principal are application specific. It is expected that applications calling for the use of this extension detail these syntax and semantics. I note that I believe independent developers have near-zero chance of producing an interoperable implementation of this I-D (as is, or as modified by the various suggestions). The developer, it seems, has to depend on knowledge gained outside of this I-D. Regards, Kurt Russ At 10:04 AM 3/22/2006, Kurt D. Zeilenga wrote: 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
RE: draft-santesson-tls-ume Last Call comment
Kurt: Okay. I think I get your point. I'll try one more time, but if that does not satisfy you, then you will have to respond with proposed text. I'm trying to address Pasi's comment too. Based on updates from a previous comment, the document will say: The domain_name parameter, when specified, SHALL contain a domain name in the preferred name syntax, as specified by RFC 1123. I think that this resolves your concern about the encoding of domain_name. I propose the following text to handle the same concern for user_principal_name: The user_principal_name parameter, when specified, SHALL contain an Unicode UPN, encoded as a UTF-8 string. Now, for the rest: 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 Nameprep [NAMEPREP] for the portion domain portion of UPN and SASLprep [SASLPREP] for the user portion of the UPN. Russ At 10:04 AM 3/22/2006, Kurt D. Zeilenga wrote: 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:[EMAIL PROTECTED] Sent: den 7 mars 2006 18:35 To: ietf@ietf.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 [EMAIL PROTECTED] 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
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:[EMAIL PROTECTED] Sent: den 7 mars 2006 18:35 To: ietf@ietf.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 [EMAIL PROTECTED] 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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-santesson-tls-ume Last Call comment
I'm not disagreeing with anything in this discussion. However I don't think we need to address this in the discussed document. The username in the defined domain hint is an account name and not necessarily a host name. Name restrictions in this case are thus governed by user name restrictions for the accessed system. Stefan Santesson Program Manager, Standards Liaison Windows Security -Original Message- From: Eric A. Hall [mailto:[EMAIL PROTECTED] Sent: den 7 mars 2006 21:06 To: Mark Andrews Cc: Kurt D. Zeilenga; ietf@ietf.org Subject: Re: draft-santesson-tls-ume Last Call comment On 3/7/2006 8:16 PM, Mark Andrews wrote: * Hostnames that are 254 and 255 characters long cannot be expressed in the DNS. Actually hostnames are technically defined with a maximum of 63 characters in total [RFC1123], and there have been some implementations of /etc/hosts that could not even do that (hence the rule). But even ignoring that rule (which you shouldn't, if the idea is to have a meaningful data-type), there is also a maximum length limit inherent in SMTP's commands which make the maximum practical mail-domain somewhat smaller than the DNS limit. For example, SMTP only requires maximum mailbox of 254 octets, but that includes localpart and @ separator. The relationship between these different limits is undefined within SMTP specs, but its there if you know about the inheritance. When it is all said and done, max practical application of mailbox address is 63 chars for localpart, @ separator, 63 chars for domain-part. Anything beyond that runs afoul of one or more standards. /pedantry -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-santesson-tls-ume Last Call comment
I agree, We should provide better guidance on encoding of the UPN. This should map with the format of UPN when provided in a certificate. The reference to the preferred name syntax is thus inherited from RFC 3280. This is how RFC 3280 restricts labels in the dNSName subject alt name. I will come back with a proposal on new text later today. Stefan Santesson Program Manager, Standards Liaison Windows Security -Original Message- From: Mark Andrews [mailto:[EMAIL PROTECTED] Sent: den 8 mars 2006 04:23 To: Eric A. Hall Cc: Kurt D. Zeilenga; ietf@ietf.org Subject: Re: draft-santesson-tls-ume Last Call comment On 3/7/2006 8:16 PM, Mark Andrews wrote: * Hostnames that are 254 and 255 characters long cannot be expressed in the DNS. Actually hostnames are technically defined with a maximum of 63 characters in total [RFC1123], and there have been some implementations of /etc/hosts that could not even do that (hence the rule). RFC 1123 Host software MUST handle host names of up to 63 characters and SHOULD handle host names of up to 255 characters. 63 is not a maximum. It is a minumum that must be supported. But even ignoring that rule (which you shouldn't, if the idea is to have a meaningful data-type), there is also a maximum length limit inherent in SMTP's commands which make the maximum practical mail-domain somewhat smaller than the DNS limit. For example, SMTP only requires maximum mailbox of 254 octets, but that includes localpart and @ separator. The relationship between these different limits is undefined within SMTP specs, but its there if you know about the inheritance. When it is all said and done, max practical application of mailbox address is 63 chars for localpart, @ separator, 63 chars for domain-part. Anything beyond that runs afoul of one or more standards. /pedantry -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 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 [EMAIL PROTECTED] 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. Could the IESG / RFC editor please reject any request to publish a document which use the 'preferred name syntax of RFC 1034'. RFC 952 as modified by RFC 1123 which was the the intent of this section of RFC 1034. For mail domains it was RFC 821 as modified by RFC 1123 (even though RFC 1123 fails to mention RFC 821). If it didn't apply you could send mail to the address records for 3com.com but not to the MX records and I don't think that was ever the intent. Domain name, hostname and mail domain are not interchangable concepts. There are too many RFCs which incorrectly interchange these concepts which leads to lots of confusion. The latter to are very restriced subsets* of the first. Additionally, no mention of how International domain names (IDNs) are to be handled. If we restrict to RFC 952 as modified by RFC 1123 then IDN comes into play. That doesn't help with the user side however unless we apply the mailbox translation for the DNS. 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 * Hostnames that are 254 and 255 characters long cannot be expressed in the DNS. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-santesson-tls-ume Last Call comment
On 3/7/2006 8:16 PM, Mark Andrews wrote: * Hostnames that are 254 and 255 characters long cannot be expressed in the DNS. Actually hostnames are technically defined with a maximum of 63 characters in total [RFC1123], and there have been some implementations of /etc/hosts that could not even do that (hence the rule). But even ignoring that rule (which you shouldn't, if the idea is to have a meaningful data-type), there is also a maximum length limit inherent in SMTP's commands which make the maximum practical mail-domain somewhat smaller than the DNS limit. For example, SMTP only requires maximum mailbox of 254 octets, but that includes localpart and @ separator. The relationship between these different limits is undefined within SMTP specs, but its there if you know about the inheritance. When it is all said and done, max practical application of mailbox address is 63 chars for localpart, @ separator, 63 chars for domain-part. Anything beyond that runs afoul of one or more standards. /pedantry -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-santesson-tls-ume Last Call comment
On 3/7/2006 8:16 PM, Mark Andrews wrote: * Hostnames that are 254 and 255 characters long cannot be expressed in the DNS. Actually hostnames are technically defined with a maximum of 63 characters in total [RFC1123], and there have been some implementations of /etc/hosts that could not even do that (hence the rule). RFC 1123 Host software MUST handle host names of up to 63 characters and SHOULD handle host names of up to 255 characters. 63 is not a maximum. It is a minumum that must be supported. But even ignoring that rule (which you shouldn't, if the idea is to have a meaningful data-type), there is also a maximum length limit inherent in SMTP's commands which make the maximum practical mail-domain somewhat smaller than the DNS limit. For example, SMTP only requires maximum mailbox of 254 octets, but that includes localpart and @ separator. The relationship between these different limits is undefined within SMTP specs, but its there if you know about the inheritance. When it is all said and done, max practical application of mailbox address is 63 chars for localpart, @ separator, 63 chars for domain-part. Anything beyond that runs afoul of one or more standards. /pedantry -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-santesson-tls-ume Last Call comment
On 3/7/2006 10:23 PM, Mark Andrews wrote: On 3/7/2006 8:16 PM, Mark Andrews wrote: 63 is not a maximum. It is a minumum that must be supported. Right, sorry. Same results. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
