Identity et al (was Re: [E-Lang] Authority -- what is its dual?)

[Dean Tribble]

At 10:42 AM 10/22/01 -0700, Mark S. Miller wrote:
>Tribble wrote:
> >   - in the real world, doing this with signatures is beyond
> >   nightmarish.  Distribution of keys is *exactly* the same problem of
> >   distribution of capabilities.  How do you know that you have the actual
> >   Kellogg key?  How do you get a new one if that one is compromised or
> >   expired?
>
>At 08:41 AM 10/22/2001 Monday, Jonathan A Rees wrote:
> >Then let's come up with an idealization with clean semantics that
>...
>
>Dean, I surprised to hear you say that.  You followed and participated in
>the discussion of the CryptoBrandMaker and LazyCryptoBrandMaker, for which
>the following are the pipermail thread roots.

Hmmm.  Let me clarify.  <flame heat=mild> I hear people wave the PKI magic 
wand all the time (less so now!), often in the form of, "It's easy to do 
with <PKI buzzword>; what's your problem?".  This often comes up when I am 
trying to describe an alternate solution that is actually simpler, but 
*reveals* real semantic problems that are obscured by the mud of PKI 
implementation.  For example, in many PKI "solutions", key distribution is 
often ignored as a "deployment problem" (which then later slowly strangles 
the project), whereas in the distributed object equivalent, it MUST be 
addressed explicitly and up front.  Because secure distributed objects 
reveal the problem, they appear unfavorable in a comparison (e.g., "that 
object stuff has too many hoops, let's just use digital 
signatures").  (Yes, I feel strongly about all this.  I find such 
PKI-framed discussions especially frustrating because one of the biggest 
values of object-approaches is the ability to to reveal such problems 
early.) </flame>

Aside: See?  A valid use for xml!

In the original discussion, I wanted to avoid any discussions framed in the 
fictitious simplicity of PKI.  I too think the CryptoBrand approach is the 
right approach to address the question that JAR raised, but at the time I 
didn't think that was close to the central issue under discussion, and 
didn't have the reference handy.  I'm glad you found it :-)  Note that 
CryptoBrand brings in concepts of PassByPresence, intermittent connection, 
vat locations, etc.  This is fine, but I don't want them held up against an 
impossible ideal :-)

On to CryptoBrands :-)