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

*-form as a native method


At 03:42 PM 8/18/97 -0400, David Black wrote:
>--- *-form Set Algebra ---
>On the next item, we seem to have a "smart minds think alike" effect.
>Markku-Juhani Saarinen writes:
>> We do not need a general "intersection algebra" because a application
>> can intersect two auths in the same (or compatible) DOI in a way
>> that is fit for that particular application.
>> One might have a general SPKI library to which a caller (i.e. an
>> application) supplies two callback functions:
>>   1) Check that this auth is in caller's DOI
>>   2) Intersect the raw auth data
>The important point is that that with respect to SPKI, intersection is a
>"native" method that given two <foo>'s returns a single result <foo> or
>null, as opposed to being based on domain independent list manipulations.
>Carl Ellison writes:
>>  I probably went overboard in my elaboration of 
>> what can combine with what to produce what.  [It's the mathematician in me 
>> :).]  We might have too many *-forms.  What we need for sure is a way to 
>> specify numeric ranges (for banking, purchase orders, etc.) and a way to 
>> specify pathname completion (for access to file systems).
>I agree, and in addition to range and pathname, I would add a suffix mechanism
>to do hostname wildcarding (e.g., *.research.foo.com), but leave out all the
>list and set algebra.  This leads to the suggestion:

On the one hand, individual developers should be allowed to create their own 
(* range foo ...) for foo of their choice and maybe create whole new *-forms.

On the other hand, there's a reason to have the few remaining *-forms [e.g., 
probably (*), (* set), (* range) and (* prefix)] understood globally.

For 5-tuple reduction, the job is performed by the verifier, presumably the 
product of the same developer who defined the new forms -- but the prover 
needs to select which certs to send to the verifier and that process is 
nearly equivalent to 5-tuple reduction.  The draft doesn't talk much about 
the process of selecting those certs, but that does need to be addressed.

My two solutions at this time, for that job, are:

1)	let me receive a pre-packaged (sequence ...) instead of a single cert 
when I get a permission to do something (i.e., hand the job off to the human 
or developer of the issuer).

2)	do the equivalent of 5-tuple reduction, but without a security check, in 
the prover -- take the certs involved in that process and send them along to 
the verifier.  This solution distributes to multiple sites, not just one 
prover, although as a fully distributed application it might involve a lot 
of network traffic.  On the + side of that, once a (sequence...) has been 
built, it can be re-used and individual certs inside can be updated all 
without doing another distributed search for the right certs.

 - Carl

Version: PGP for Personal Privacy 5.0
Charset: noconv


|Carl M. Ellison  cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street   PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |