[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
*-form as a native method
-----BEGIN PGP SIGNED MESSAGE-----
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
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQCVAwUBNAMs4lQXJENzYr45AQExSQP9F0QpvAjuhJmJQqF5k6TP8QSM1jOuRieN
ZTIUvnL5VuYUUcaMGK56TgXkf04cm2+cCih3if/Z+xwJhXZwuohaFIBk9ILdOr1z
6iR0cj3XzwNIt3Yr3l51DpomRnP1sOVTjdiC3DzAMayUq0uTsXKUT6QsaMFF9HyF
elWM3mlkfvU=
=TX+V
-----END PGP SIGNATURE-----
+------------------------------------------------------------------+
|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 |
+------------------------------------------------------------------+
References: