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

*To*: cme@cybercash.com*Subject*: auth fields*From*: rivest@theory.lcs.mit.edu (Ron Rivest)*Date*: Tue, 11 Mar 97 11:10:04 EST*Cc*: blampson@microsoft.com, spki@c2.net

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/* but /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. Thoughts? Cheers, Ron Rivest

**Re: auth fields***From*: Carl Ellison <cme@cybercash.com>

- Prev by Date:
**Re: encoding: SPKI vs. SDSI** - Next by Date:
**Re: encoding: SPKI vs. SDSI** - Prev by thread:
**Re: rules for SPKI <auth> field comparisons** - Next by thread:
**Re: auth fields** - Index(es):