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

Re: Application inquiry


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 
>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.

>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 

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 
>involved in a particular access check is a non-trivial operation. Are we 
>to trust each individual application to implement this correctly? Or could 
>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

Version: PGP for Personal Privacy 5.5.3


|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.-+