Subject: [precis] PRECIS breadcrumbs

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 20 Feb 2015 02:56:35 +0100

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-masked] · 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/