Re: Transfering a domain

[Kent Crispin <kent@songbird.com>]

davidk@ISI.EDU allegedly said:
> 
> 
> Kent,
[...]
> Let's say it a bit different. It is a concern. It would be nice if this
> problem could be eliminated, however I think that keeping the data public
> is sufficient for having a system that will work for our needs although
> it is not completely satisfactury (but who can build a system that is
> satisfactory in every sense?)

After some thought I think the public visibility is quite 
sufficient.  Remember that the end user will have a digitally signed 
document that cannot be refuted, as well.

> > When a domain is created, the end user supplies a public key.  This 
> > public key and other info is added to DNS by the registrar.  The 
> 
> There is a slight problem here or I didn't understand your last sentence.
> The repository OR the end-user are the only ones that could (should) add
> the data to the DNS since the end-user runs primary for its own site and
> the repository primary for the TLDs.

Ah -- yes.  I finally see what you were thinking -- it's puzzled me
for some time.  In your model the key and whois data go in the *users*
zone.  In my model they go into the *registries* zone, with the glue
records for the users SLD.  That, incidentally, was why I wasn't so
worried about accessibility of the contact info as an issue -- if the 
TLD DNS goes down you have far more serious problems to worry about.

> The registrar should have no power
> over the keys since it is the weak part in the chain. The registrar could
> go out of business and the public keys could be unavailable at the same
> time (The end-user could also go out of business but then the domain
> will simply time-out after a year in the repository).

I don't follow this -- if the registrar went out of business I would 
just go to another registrar and change things.  I must be missing something.

> The end-user user could put the public key in DNS themselves (or in any
> other database that is running on the end-users *own* machines). They
> will need to setup their (primary) nameservers anyway and it solves the
> concerns over changing the public key by anybody else. However, this
> scheme has flaws since the end-users machine could not be very well
> reachable in case of a DNS/ISP change ...

No, I am convinced that with a signed certificate from the original 
registrar the user could always get a change done.

> Conclusion: the public keys should be stored at a location that is in
> control of the repository whether it is DNS or a simple database.

[...]

> As I said before: your scheme and mine don't differ that much ;-).

Well, of course, I borrowed :-).

> The
> algorithm that you describe here can be used in both schemes. The main
> difference is that you want to use DNS as the database and I would rather
> like to use a very small high speed and simple database for generating
> the zone files. One of the reasons I would do it that way is that I
> expect that it is easier, faster and more crash resistant to add data to
> a simple database then directly editing the zone files when an update in
> the repository comes in. At the same time I already said that I would
> prefer dumping the repository data in DNS for public review instead of
> running a simple whois database at the repository.

I agree -- editing of the zone files is for the birds (though that's
what I did...) This is a perfect application for a small database. 
Note that it doesn't have to be visible to the outside world, though. 

In the not too distant future, however, I think that dynamic update 
in DNS would handle the job perfectly.

[...]

> It can only check the signature under all conditions if the public key is
> maintained by either the repository or the end-user itself. The public
> key will not be retrievable when the registrar goes out of business and
> runs primary for the data-set that it maintains. You could circumvent
> this by forcing the repository to act as a backup but then you can as
> well store the data centrally from the start...

If it's in the TLD zone it is available regardless of a registrar failure.

[...]

> > A serious dispute would still have to go to a central authority.
> 
> Yup, we can of course only try to minimize the amount of disputes (This
> is another reason why a skilled administrative person at the repository
> site is a good idea, engineers are not always the best mediators ;-)).

Yup :-)

> Then at last:
> 
> I appreciate that you pointed out the weaknesses in my scheme, it is a
> challenge to come up with a better proposal each time. I hope that my
> comments will do the same for you ;-).

Actually, they already did -- recall that I wasn't convinced of the
viability of using the users' public key.  I now think it is the
correct approach.  Furthermore, and amazingly enough, it is really
straightforward to implement -- I probably won't be able to do it 
this weekend, but by sometime next week I should have it added to my 
prototype.  The main issue is a resonable interface for scarfing up 
the users public key.

> David K.
> PS  Note that English is not my native language and that I might
>     sometimes sound a bit harsher then intended.

Not too worry.  I consider your comments to be among the most 
valuable on this list.

-- 
Kent Crispin				"No reason to get excited",
kent@songbird.com,kc@llnl.gov		the thief he kindly spoke...
PGP fingerprint:   5A 16 DA 04 31 33 40 1E  87 DA 29 02 97 A3 46 2F