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

*To*: rivest@theory.lcs.mit.edu (Ron Rivest)*Subject*: Re: auth fields*From*: Carl Ellison <cme@cybercash.com>*Date*: Fri, 14 Mar 1997 14:26:55 -0500*Cc*: blampson@microsoft.com, spki@c2.net*In-Reply-To*: <199703111610.AA02342@swan.lcs.mit.edu>*Sender*: owner-spki@c2.net

Hi Ron. At 11:10 AM 3/11/97 EST, Ron Rivest wrote: >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). No, I had always been thinking of a partial order -- maybe a lattice -- although it's not clear that any such lattice would be closed. E.g., in your filesystem example, "ftp://cybercash.com/pub/cme/" and "ftp://theory.lcs.mit.edu/pub/rivest/" might theoretically be both subordinate to "ftp:" but there might be no cert ever generated for that lattice point. The problem with thinking of such lattices, to me, is that for some real uses of certs, we'll need to be able to do an occasional PolicyMaker translation of <auth> -- something that I don't know how to express in such a form. A PolicyMaker program would join arbitrary places on such a lattice. Agree? - Carl +------------------------------------------------------------------+ |Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme | |CyberCash, Inc. http://www.cybercash.com/ | |207 Grindall Street PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 | |Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 | +------------------------------------------------------------------+

**Re: auth fields***From*: Ben Laurie <ben@gonzo.ben.algroup.co.uk>

**auth fields***From*: rivest@theory.lcs.mit.edu (Ron Rivest)

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