Re: [ire] New version (4) of the spec and new draft on DNRD (1)

[Francisco Obispo <[e-mail]>]

Hi James,

On Dec 13, 2012, at 8:16 AM, "Gould, James" <[e-mail]> wrote:

> Gustavo,
> 
> I noticed the following additional items with draft-arias-noguchi-dnrd-objects-mapping-01:
> 
> 	• The description of the <crID> and <upID> should match what is in the EPP RFC's.  Specifically, change "identifier of the registrar" to "identifier of the client".  In our registries we have account users (verisign as well as registrar) that are reflected in the <crID> and <upID> fields via the user's user name (e.g. jgould).  This is important to track exactly who took the action, since actions can be taken outside of the EPP channel (Registrar Tool, CSR Tool, batch) that should properly be reflected in the <crID> and <upID> elements.  Now the next logical question is whether there needs to be a deposit for users to link the "client identifiers" to.  I would imagine that an EBERO provider would import the <crID> and <upID> fields as strings and replace them (most likely using different fields) with real user identifiers based on future updates to the objects.

I don't know about that, from the EPP perspective a *ID is a registrar not a system user, so interchanging the two doesn't seem like a good idea to me.

You could use a separate field to track those changes, without affecting the EPP semantics.


> 	• The question is whether the authInfo should be escrowed at all since these reflect secret passwords.  Our system stores them encrypted and I don't believe it is a good security practice to escrow them in a decrypted form or even provide a tool that can decrypt them.  I believe that the EBERO provider recovering a registry from the data escrow deposit can generate new random authorization info values and make them available in bulk to the registrars or on-demand by the registrars submitting an EPP info command for the objects.  What are your thoughts with this?  
> -- 

I agree with this, specially since the passwords are not the only component used to authenticate users, for example, we use IP addresses and TLS certificates as well, (we match the information in the certificate with the information associated with the clID)

In any case recovering a registry will require some time to setup these relationships, so I don't think there's a need to automate every single step.

> 

Francisco Obispo 
Director of Applications and Services - ISC
email: [e-mail]
Phone: [phone] || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE