Hans Reiser, the designer of the very interesting reiserfs filesystem, recently posted to the [EMAIL PROTECTED] list (which is cc'ed here) about Josh MacDonald's idea that a PKI is a distributed filesystem, and the thought that public keys could replace UIDs or SIDs in a filesystem. I'm attaching Hans's message and Josh's follow-ups with the hope of getting a bit of inter-disciplinary discussion going... - J�rgen
Sorry, a version of this email got sent before it was finished.... Josh McDonald and I had an interesting dinner last night in which he convinced me that a private key infrastructure is a distributed file system, and better than SIDS. I thought I'd toss that idea out to our mailing list, and see if the rest of you agreed that perhaps we should be basing our security on public keys, and PKI concepts, rather than UIDs or SIDS. Hans -- Get Linux (http://www.kernel.org) plus ReiserFS (http://devlinux.org/namesys). If you sell an OS or internet appliance, buy a port of ReiserFS! If you need customizations and industrial grade support, we sell them.
Hi everyone. I'm in the process of subscribing to your mailing list here, but I'm not on it yet. Before anyone can disagree with the statement Hans made, let me point you towards some literature I have been using to come up with this stuff. This is the preliminary thinking behind a future research project of mine. Basically I am very unsatisfied with the current state of the art in PKI, and there are many reasons why the existing, deployed PKIs fail. There are some good papers on this subject by Carl Elison and Bruce Schnier. Search for any paper by Carl Elison, the basic summary of his claims are "If you want to implement a secure application, you need access control, therefore you need your PKI (which MUST be the foundation of security) to provide a primitive form of authorization, not authentication (which is a special case of "Is this subject authorized to speak-for this principal"). The primary failing of systems like PGP and X.509 are that they are a form of name-to-key binding. They differ in how they establish trust, but that's because they are doing it wrong. Some newer PKIs are: SPKI, which is an IETF effort headed by Carl Elison, and SDSI, which is done by Ron Rivest and Butler Lampson. They explain how to get it right, by throwing a lot of mostly orthogonal features at the problem, things like: * Each key corresponds to a principal, establishing the notion of identity. * Name space management, for creating name spaces local to a particular principal. Each name entry can bound to another principal. They are fully decentralized systems. * Group management. These are an overloading of the name space concept, for the most part, where belonging to a name space represents group membership. * Delegation/trust management: provide a set-theoretic language for expressing trust relationships, enabling access control statements to be written. * Linked local name spaces: these are known as "self-certifying paths", a concept also developed in work on the "Secure File System", which was recently presented at the SOSP by David Mazieres. This is basically a symbolic link for crossing name space boundaries, and allowing one principal to access another principal's names. * Grab-bag of necessary features: certificate management, on-line proxy service for querying name spaces, management of its own internal state, w/ access control over that state. Here comes the claim: a PKI should rightfully be described as a decentralized file system. If you are a file system architect and you read the paper on SDSI you will see that each of the features they present are one facet of a file system, dressed up to look like a PKI that doesn't realize it is a file system. Why? The primary goal of a file system is to provide generic state management. The operating system provides AUTOMATIC SECURITY over that state, making it easy to write applications that have built in access control. The operating system must provide a concept of users and groups to accomplish this. The PKI provides: user identity, group identity, name space management, state management, and access control. So why not present a generic state management interface instead of a PKI-specific one, and call it a file system? It already is. These are some of the ideas I eventually want to go into PRCS. I'm planning on preparing an annotated bibliography on this subject some time in the next month. I'll post it here. In the mean time, if you want to understand the relationship between file systems and PKIs I suggest you read about SDSI (Simple Distributed Security Infrastructure), the Secure File System, and one of Carl Elison's recent position papers. -josh Quoting Hans Reiser ([EMAIL PROTECTED]): > You really should cc Josh on your emails. > > Hans > > Michael Samuel wrote: > > > > On Fri, Feb 18, 2000 at 01:39:38PM +0300, Hans Reiser wrote: > > > Sorry, a version of this email got sent before it was finished.... > > > > > > Josh McDonald and I had an interesting dinner last night in which he convinced > > > me that a private key infrastructure is a distributed file system, and better > > > than SIDS. I thought I'd toss that idea out to our mailing list, and see if the > > > rest of you agreed that perhaps we should be basing our security on public keys, > > > and PKI concepts, rather than UIDs or SIDS. > > > > I disagree, but some basics first: > > > > There are 2 different PKIs in use at the moment, the current system where > > there's a central authority that can sign public keys to testify to their > > validity, and there's the one used by PGP where other people can testify to > > the validity of another's key, and you assign 'trust levels' to public keys. > > > > So, that gives you either a heirachy of trust, or a web of trust, repectfully. > > > > Now, for why I disagree: the way PKI works not only envolves expensive > > calculations, but would make the login process dependant on the user > > remembering a _very_ big random number, and all FS operations. (Although, > > dedicated crypto hardware and smart cards can solve those problems) > > > > Am I looking at a different aspect of PKI than what you were thinking about? > > Maybe you could expand upon your thoughts. > >
