Re: Comments on overall direction

[Karl Auerbach <karl@CaveBear.com>]

> At 12:29 PM 12/26/00 -0800, Karl Auerbach wrote:
>
> >3. I am very wary of continuing the current notion of agent-to-agent
> >transfers.  To my mind any transfer should be accomplished via the
> >customer, i.e. that some signed certificate must be handed by the
> >relinquishing agent to the customer for the customer to hand over to the
> >acquiring agent.
>
> It would help to have a description of an existing service that has similar
> scale and scope, that uses a similar mechanism.

A bill of lading.  It's a technique that's been in use since about the
year 1500.

In recent times, in operating systems the technique has been called a
"capability".

It's not a big extension to conceive of a digitally signed object that
represents an instruction to perform some action on some asset - such as a
domain name.  Indeed, we are part way there with the PGP signed domain
update forms that we use today.

When I ask for my domain to be transfered from agent A to agent B, I tell
agent A to initiate a transfer, A gets a digitally signed certificate of
control from the database/registry, signs it itself, and then hands it to
me.  I sign it.  I, in turn, hand it to agent B who verifies the various
signatures.  Agent B signs it and hands it to the database/registry, which
also verifies everything and, if they check out, performs the transfer.


> >5. The issue of privacy and security seems to be being glossed over - we
> >are talking about databases that will be among the worlds larger bodies of
> >personally identifiable information - with both strong privacy
> >characteristics and high value to marketing/sales folks.
> >
> >This suggests to me that there ought to be adequate information in the
> >protocols to build unambiguous, timestamped, transaction journals.
>
> "in the protocols"?  Sites can and do do high quality, timestamped
> journaling without special protocol issues.  What specific mechanisms or
> information do you believe affect the protocols?

Timestamps can be faked, that's why there needs to be both client and
server timestamps, and for them to be integrity protected in the packets.

> >It also suggests to me that there be provision for solid identification
> >and authenticatation of all transactions.
>
> so, you want a public key signature on every protocol unit?

Not every PDU - but certainly on every transaction.

		--karl--