Re: evaluation: draft-legg-ldapext-component-matching

["Steven M. Bellovin" <smb@research.att.com>]

In message <p06001205bb1fdb74c1ee@[129.46.227.161]>, hardie@qualcomm.com writes
:
>Steve,
>	I think this draft takes a slightly different road
>than RFC 3454-style stringprep.  The way I look at it, stringprep
>profiles define a set of steps which must be taken in order
>to correctly store a string or compare two strings
>within a particular protocol context (from section 1.2 of
>RFC 3454).  In a sense, it provides a set of mechanisms
>that allow you to manipulate a set of data so that well-known
>matching rules can be safely (and simply) applied.
>	This draft takes the other direction--it leaves
>the data as is, but uses generic matching rules against
>user-identified component parts to allow for
>arbitrarily complex attribute matching.  Some of those
>generic matching rules relate to string matching (section
>4.2.1.1 has a list), but they derive from types set up
>in draft-legg-gser-abnf, which has both ABNF and
>ASN.1 definitions for them.  While stringprep profiles
>could be used in the definitions of some of the generic
>matching rules, I am not sure it is the right fit, since
>the actual matches won't fit within the basic stringprep
>theory.
>	If there are more particular problems you have
>specific string matching profiles, let me know.  Also,
>both Harald and Russ have extensive experience here
>(certainly much more than mine), and I'd be happy to
>have their opinion on how this fits.

I'd like such input, too; any time I comment on this area, I'm skating 
on very thin ice indeed.  However, on rereading 4.2.1.1 I suspect that 
there really is an issue.  If I understand 3454 correctly, you can't 
even properly compare for equality without normalization.  Consider the 
case of an LDAP phone book, where one person prepares the entry -- and 
hence implicitly selects the software used to encode a person's name -- 
while another person queries the phone book, using entirely different 
software.  Without some definition, the proper entry may fail to match.

But as I said, I'm on very shakey ground when I comment on this stuff.


		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)