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

Re: Application inquiry

At 6:16 PM -0700 11/4/98, Kaelin Colclasure wrote:
>I have been reviewing the SPKI drafts and trying to apply the concepts to
>a security model for SmartSockets (our message-oriented middleware
>product). I believe I have a fair grasp of the theory of operation, but I
>am wrestling with the practical considerations of implementing and
>deploying SPKI.
>I hope that I might impose upon the members of this list to help enlighten
>me... :-)

Flattery will get you everywhere.  :-)

>First, my reading of the proposals would lead me to conclude that either
>a) authorization certificates are to be issued "on demand" when a user
>requires the authorization in question (and passes the scrutiny of the
>authorizing authority) or b) a user is likely to accumulate a fair number
>of authorization certificates, which she will have to store somewhere.
>SPKI could apparently support either model, but is one preferred over the
>For the sake of discussion, let's call the first alternative the "ticket"
>security model and the second the "pass" model.

We do not take a position.  Note that certificates do not need to be kept
secret if the authorization they represent is not a secret.  They could be
kept on a LDAP server.

If the ticket model re-calculates the certificate each time, that will
impose a signing load on the authorizing authority.  A rule of thumb is .25
to 1 second for a signature.

>The pass model requires that certificates be stored somewhere. For
>existing applications like S/MIME this is typically on the user's local
>machine. But AFAIK there are no standards as to *where* on a machine a
>given users certificates might be found. (Well, Win32 has some standard
>certifate store functions-- but not other OSs.) Does SPKI presume that a
>common certificate store will eventually be widely supported? Or is it
>expected that each application will manage the storage of its own
>certificates, as is currently done? (If there is any work being done in
>this arena, I'd appreciate a pointer.)

We don't have an opinion.  I don't have any pointers either, but someone
else might.
>With the ticket model, the local storage requirements are alleviated. But
>how does the service that issues ticket certificates keep track of
>authorizations? Might it aggregate pass-style certificates acquired from
>other sources, acting as a central store for them?

Central storage of certificates could work, as alluded to in the LDAP
server scenario.
>The second issue I'm grappling with is that "tuple reduction" combined
>with obtaining the necessary keys to validate all the signatures of the
>certificates involved in a particular access check is a non-trivial
>operation. Are we really to trust each individual application to implement
>this correctly? Or could this perhaps be delegated to a trusted service
>which implements checking in accordance with local policies?

On can imagine a tuple reduction engine in a runtime library.  The tuple
reduction algorithm has no policy associated with it.  The policy is part
of its input.

Bill Frantz       | Macintosh: Didn't do every-| Periwinkle -- Consulting
(408)356-8506     | thing right, but did know  | 16345 Englewood Ave.
frantz@netcom.com | the century would end.     | Los Gatos, CA 95032, USA

Follow-Ups: References: