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

[Christopher Browne <[e-mail]>]

On Thu, Dec 13, 2012 at 11: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.
> 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 largely concur...  Yes, indeed, there will be some users that are
not specifically
registrars, so <crID> and <upID> are not strictly "registrars";
sometimes they will
indicate registry operator agents that are not registrars.

As for authinfo values, I'm a bit torn.

On the one hand, there is a significant problem in changing authinfo values on
the registrants, particularly when the registry operator may have no direct
channel for communicating updates to the registrants.  (This is most pointedly
the case for "thin" registries where no contact information is captured in the
registry!)

However, as soon as we are in a situation of switching registry operators, there
are distinctly too many agents that share the secret authinfo values.
It has been
our practice, when taking over operations of registries, to change all authinfo
values.  My instant, kneejerk recommendation upon receiving a dump of data
for a registry is to say, "And we'll be replacing all the authinfos, right?"

I observe that the authinfo values should be considered distinct from user
authentication information for registrars; those are quite different things.  I
see what looks like conflation of the two things downthread.