[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

auth fields

Hi Carl --

You mentioned a "sorting order" for auth fields.  This implies that
you want what mathematicians call a "total order" on the elements, so that
between any two such elements you have a relationship (either greater,
less than or equal to).

But I think that an "auth field" may not have an associated total order,
only a partial order.  (So that between two elements there may not be
a relationship.)  As an example, I'm thinking of regular expressions
or the like for file names, so that
	/a/rivest/foo < /a/rivest/*
	/a/rivest/*   and   /a/ellison/*
are incomparable.  (For regular expressions, you can say that expression
R1 is less than or equal to R2 if and only if the set of words matching
R1 is a subset of the set of words matching R2.)

Moreover, it may be desirable to have not only a partial order, but a
lattice, so that there is a LUB (least upper bound) and a GLB
(greatest lower bound) for any two elements.  This allows one to
combine a sequence of certificates into a compressed form.  That is,
if cert 1 is issued by A to B with authorization (<= R1), and cert 2
is issued by B to C with authorization (<= R2), then there is an R3
such that the certificate chain has authorization (<= R3) from A to C.
And similarly if the authorization was for >= instead of <=.  A total
order is trivially a lattice.  A boolean lattice is a good example.
Imagine that an auth field can specify keywords, either as "must have
these given keywords" (lower bound) or "can't have keywords outside these
given keywords" (upper bound). Then it is easy to compress a certificate
chain by taking the union of the lower bounds and the intersection of the
upper bounds.  


	Ron Rivest