[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Application inquiry
-----BEGIN PGP SIGNED MESSAGE-----
Hi Kaelin,
>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?
Both models are possible, but I have always envisioned the second. It's
probably fair to investigate both, of course. Who knows: there might be a
paper there.
>For the sake of discussion, let's call the first alternative the "ticket"
>security model and the second the "pass" model.
>
>The pass model requires that certificates be stored somewhere. For existing
>applications like S/MIME this is typically on the user's local machine.
That's one possibility. Another is to store them on your web site and just
store the URL that fetches a cert chain on the local machine -- on the
assumption that the only time you need certs is when you're on-line.
>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.)
There's also CDSA (originally from Intel, now through the OpenGroup) -- that
also provides certificate storage machinery and has the hooks for SPKI.
>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.)
SPKI certificates are specific to one application, so I've always assumed
they would be stored and accessed by the application that uses them. For
example, I had a file once (long since lost among the backup tapes from past
machines) that gave passwords and initial directories for various machines
for FTP. I would imagine that file extended to hold the SPKI certificates
instead -- carrying not only permission to log in but also the base
directory in the SPKI leaf cert in the form of
(tag (ftp ftp.clark.net /pub/cme/html/))
for example. That cert's Subject would indicate the private key that has to
be used, but another field might be used to carry a pointer to that
private key -- e.g., where to find it (in some smartcard, PCMCIA card, PCI
card, passphrase-protected file, ...).
>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?
My problem with the ticket model is that the user would have to have some
credentials with which to go fetch the ticket. That looks to me like just
as much work as holding the passes of the pass-style. Do you see any way to
simplify that process?
>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?
I don't follow this question. Certificates carry either a public key (in
which case you have it already) or, for brevity, the hash of the public key.
If a certificate carries just the hash as the subject, then it's necessary
to include the public key itself in the bundle of certificates.
The implementation I did in which just hashes were kept, kept all public
keys in an in-memory database, indexed by hash. I used the low order bits
of the full hash of the public key to index that hash table.
>The novel advantages of SPKI are quite apparent to me, but of course the devil
>is in the details of implementation...
Maybe it's the devil -- but it's also the fun. I'm looking forward to
having the specs out as RFCs so we can get on with implementations.
- Carl
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.3
iQCVAwUBNkFCPRN3Wx8QwqUtAQHLxAP9GLaK08rl2mmZaG0RgTe2OE37IAf5tk5+
p3DeRWh8nX1yxWHqBzzNzNReKYZOP9hfRcyA7Op5fDi1QzdM3rMwozMlWlo09hPH
vRHY8fXq5PcDZkRJu/EwjyNV5/cV/OjkQXSCF6EIm7R5aXJS4ij2nRJpASs9f+lo
ZDJJTQM8j0I=
=nmNr
-----END PGP SIGNATURE-----
+------------------------------------------------------------------+
|Carl M. Ellison cme@acm.org http://www.pobox.com/~cme |
| PGP: 08FF BA05 599B 49D2 23C6 6FFD 36BA D342 |
+--Officer, officer, arrest that man. He's whistling a dirty song.-+