[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
>other?
>
>
>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: