[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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