Hi, Yesterday I tried to find out if the latest draft for HTTP Basic auth- entication allows colons in passwords. I eventually gave up; what I did: http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-06 has
For the password, recipients MUST support all characters defined in the "OpaqueString" profile defined in in Section 4.2 of [PRECIS]. Went to http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-13 and when I searched for `OpaqueString` in the document the first hit beyond the ToC is: 4. Passwords 4.1. Definition This document specifies that a password is a string of Unicode code points [UNICODE], encoded using UTF-8 [RFC3629], and conformant to OpaqueString profile of the PRECIS FreeformClass specified below. This left me confused why `basicauth` references `OpaqueString` instead of "a password as defined in [PRECIS]" or something like that. Anyway... Since `OpaqueString` is said to be "specified below", I continued the search and the next hit is 4.2. OpaqueString Profile The definition of the OpaqueString profile is provided in the following sections, including detailed information about preparation, enforcement, and comparison (on the distinction between these actions, refer to [I-D.ietf-precis-framework]). 4.2.1. Preparation An entity that prepares a string according to this profile MUST ensure that the string consists only of Unicode code points that conform to the "FreeformClass" base string class defined in [I-D.ietf-precis-framework]. In addition, the string MUST be encoded as UTF-8 [RFC3629]. Since `basicauth` allows other character encodings than UTF-8, I have found the MUST requirement here somewhat irritating, but I assume that is resolved somewhere. In any case, I skipped the rather complicated rules that follow the quoted text above, since the definition of the `FreeformClass` is needed before I could apply the additional steps to find out if colons are allowed in `basicauth` passwords. The definition is in another document, so I went to http://tools.ietf.org/html/draft-ietf-precis-framework-21 and the first relevant hit there is FreeformClass: a sequence of letters, numbers, symbols, spaces, and other characters that is used for free-form strings, including passwords as well as display elements such as human-friendly nicknames for devices or for participants in a chatroom; the intent is that this class will allow nearly any Unicode character, with the result that expressiveness has been prioritized over safety for this class. Note well that protocol designers, application developers, service providers, and end users might not understand or be able to enter all of the characters that can be included in the FreeformClass - see Section 12.3 for details. I clicked the link to Section 12.3 but that turned out to be wrong. So instead I kept searching the document for `FreeformClass` and ended up in section 4.3 which has several pages of rules that define the class, most of which refer to other sections of the document, which in turn re- ference, among other things, various properties in the Unicode database, such as the general category of characters. The takeaway was that I would have to spend an afternoon or likely more time implementing all the rules before I could answer my rather simple question. Retracing my steps just now it might have been possible to see `ASCII7` listed as `valid` but I can't really be sure if `Disallowed` rules in 4.3.3. might override that, and in any case, I would have to go through the definition of `OpaqueString` to see whether the colon might be disallowed there even if `FreeformClass` allows it. The conclusion was that I would need a tool to tell if `OpaqueString` allows colons. I also wondered whether it would make sense to list at least the ASCII-range characters explicitly for the relevant class de- finitions (and shudder to think that they might change due to changes in Unicode); I am also not sure whether classes like `OpaqueString` correspond to repeated classes like [a-z]* or have more complicated restrictions (like U+1234 can occur in `OpaqueString` but not after U+ABCD). FWIW, -- Björn Höhrmann · mailto:[email protected] · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
