RE: Comments on overall direction

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

While I know of at least one company that would be thrilled to see
requirements for millions of domain name owners to become PKI-capable (or
even just the subset who wish to request transfers), I have to echo the
point raised by Dave concerning deployment and adoption.  I'm sure there are
domain name holders who would understand and welcome such developments, but
people aren't exactly falling over each other to install applications that
provide cryptographic services.

I don't disagree that transactional integrity is essential, but we may have
different ideas on where that integrity service needs to be available or
applied.  I believe that we have a far better chance to produce a widely
accepted protocol if we do our best to keep the protocol itself extremely
simple, and using a layered approach to add services that make sense in
particular operational environments.

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Karl Auerbach [mailto:karl@CaveBear.com]
Sent: Wednesday, December 27, 2000 5:08 AM
To: ietf-provreg@cafax.se
Subject: Re: Comments on overall direction



> 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--