[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Transfering a domain
- Date: Fri, 10 Jan 1997 12:53:30 -0800 (PST)
- From: Kent Crispin <kent@songbird.com>
- Subject: Re: Transfering a domain
davidk@ISI.EDU allegedly said:
>
>
> Michael,
>
> > Michael Dillon writes :
[...complicated schem...]
> > ...new key is emailled to them for the next change.
>
> This is an interesting idea. I just happened to have a simular thought
> but a little bit less complicated (and in line with my light-weight
> repository ideas ;-)):
>
> The end-user can specify an Acknowledgement E-mail address. The registrar
[..more complicated stuff...]
> ...a message (from the registrar) with the wrong signature since it doesn't
> know the repositories private key.
>
> > have received their bills. The registrars are the front-end customer
> > service reps, but CORE is the maintainer of the registry.
CORE should have little or no end-user interaction. It should only
become involved in the case of a serious dispute, or failure of a
registrar.
> The notices should be mailed by the registrars. It's their choice to use
[...]
> provide this service),
Here's a somewhat different scheme -- since you apparently believe
that the possibility of the current registrar changing a users key is
not a concern, because it would be visible.
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
registrar emails the end-user a digitally signed listing of the info
in DNS, so the user can guarantee that it was set up correctly. This
registrar is noted in DNS as being the registrar representing the
user, and thus is authorized to make changes on the user's behalf.
This is my current model, and what I have implemented in my
Ultra-lightweight registry.
Now we add the following: suppose the user wants to make a change.
The user can contact *any* registrar for the domain, indicating the
desired changes. The new registrar notes that it isn't the current
registrar representing the domain, so it sends an "update"
certificate to the user, which the user signs and returns. The new
registrar countersigns the certificate, and sends it to the dns upate
process, which checks the registrars sig, notes the user's sig,
checks it against the one stored in DNS, and does the update if it
works.
The user can change almost all fields this way, including updating
their key, or changing representing registrar.
The representing registrar acts as a fail-safe, in case the user
looses their key, since whichever registrar is so designated can
update records without the users key being supplied. But the user
always gets a signed certificate indicating the state of DNS.
A serious dispute would still have to go to a central authority.
--
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