[E-Lang] MintMaker with ACLs

[hal@finney.org]

Tyler wrote:

> Should I, and others, assume that you are in agreement with the points
> that you've deleted from my response? You've chosen to not respond to,
> and delete, some of the more important points, while addressing some
> of the less important ones.

I can understand this concern, but it was certainly not my intention.
In a long message I tried to select the most salient points.  However
I want to make clear that I was not trying to evade anything, so I will
include here all of Tyler's words that I had not responded to in my
earlier message.

Quoting Tyler:
> Hal wrote:
> > Let me try again, then, to make it more ACL-like.  Instead
> > of passwords
> > I'll use UIDs.
>
> This is what I think of as an ACL ( given the current discussions, I'm
> not sure I know what the word actually means anymore ;)
>
> Right off the bat, there are a couple of things that bug me about this
> implementation.

I didn't respond to this because it was just prefatory.

After asking how a trusted third party could facilitate a trade in the ACL
mint, Tyler wrote:

> I'll help you out here and code what I think your extension of the
> example would be:
>
> 	int next_account;
>
> 	int makeAccount()
> 	{
> 		int acct = next_account++;
> 		balance[acct] = 0;
> 		ownerUID[acct] = getuid();
> 		return acct;
> 	}
>
> 	int delegate(int acct, UID new_owner)
> 	{
>           	if( getuid() != ownerUID[sourceAccount] )
>               	return ERROR_INVALIDACCESS;
> 		ownerUID[acct] = new_owner;
>           	return NOERROR;
> 	}
>
> Let's assume that ints are integers, and we have infinite memory.
> (It's just an example people!!!) Assuming the ACL system has a public
> newUID() system call, Marcs can now be philanthropic with good
> samaritans.
>
> The makeAccount() method is the logical equivalent of the MintMaker's
> makePurse(). The delegate() method has no equivalent in the MintMaker.
> Using a HalMint there are two steps to passing authority over an
> account to another UID. First, you must pass the account number to the
> new UID holder, then you must call the delegate() method. With a
> MintMaker, there is only one step, pass the cap for the purse to the
> other party. In the case of the HalMint, both of the actions taken
> have the same logical intent, yet the ACL system requires that you
> take both steps. This is precisely the duplication of effort that I
> referred to in my response to Jonathan.

Tyler is trying to "help me out" here by anticipating the direction I will
go and responding to it.  This is always tempting due to the long delays
inherent in an email conversation.  However this was not in fact the response
I wanted to make.  Instead I wrote:

: How about if each of us simply pays the TTP using transfer(), and the
: TTP then pays us the appropriate amount?

With this approach I felt there was no need to explore the elaboration
that Tyler presented above so I did not quote it in order to shorten my
message somewhat.  It was not relevant in terms of the direction I was
trying to pursue.

> The explicit coding of security policies also has a devastating effect
> on code size. How much of the HalMint code is now dedicated to
> maintaining and checking ACLs? Does security feel like an additional
> burden placed on the code's functionality? Do you get the same feeling
> when looking at the MintMaker? "Who has time for implementing
> security?".

I did leave this paragraph out, and that was a mistake.  I was mislead
by careless reading, focusing on the last three sentences which I felt
were too subjective, talking in terms of "feel".  This is just a matter
of personal taste so I didn't respond.  But I overlooked the first two
sentences which made a specific point regarding code size in this example.

I do agree that much of the functionality here is devoted to dealing
with security.  But that is because the non-security functionality
is so trivial, just incrementing and decrementing balances.  In a more
substantial application you would do a lot more than this and the security
portion would be relatively smaller.

If there were no need to deal with security issues, the MintMaker could
probably be simplified considerably as well.  You wouldn't need the
sealer/unsealer pair, you wouldn't need the decr object.  You wouldn't
need sprout or getDecr.  You'd have withdraw and deposit as one-liner
methods: balance += (or -=) amount, and you'd trust that the amount was
right.


> > For the confused deputy example, let there be an agent
> > which will reveal
> > my public balance under certain conditions.  This agent needs to be
> > running with its own UID and that UID is put on the
> > accessUIDs list above.
> > This way I don't have to give the agent more power than he
> > needs and the
> > POLA is satisfied.
>
> The design laid out in this email now contains a confused deputy
> attack. Consider the trade facilitator I mentioned above, where that
> trade facilitator charges a fee for its services.

I left this paragraph out as well, because I had not included Tyler's
earlier design.  As I wrote above, I was not convinced that it was
necessary to explore that route in place of the simpler approach of paying
the TTP directly rather than giving him rights to my account.  It would
not make sense to include this paragraph without the earlier context.

That's all that Tyler wrote which I didn't include.  There was an example
of doing delegation which I didn't think was necessary; one paragraph
which mentions code size but also talks about subjective feelings toward
security; and another paragraph alluding to the delegation example.

Tyler says that these are some of the more important points he wanted
to make.  I did not realize that in responding to his article and so I
am sorry that I neglected to include them.

I do sometimes trim messages to which I am responding in order to keep
the length manageable.  Many times I have seen online debates in which
each person responds to one paragraph with two of his own.  Once this
has gone back and forth a few times, no one is reading any more except
the two parties.  It is not a productive mode of communication for a
public forum, in my opinion.  However the alternative, which is to try
to focus on specific points, leaves open the charge that one is evading
the strongest arguments.  I don't know the right solution in general,
but for future conversations in this forum I will be careful not to
eliminate any text unless I am fully in agreement with it.

Hal