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

["Gould, James" <[e-mail]>]

Francisco,

My feedback is below.


-- 

JG
 

 
James Gould
Principal Software Engineer
[e-mail]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com







On 12/13/12 12:25 PM, "Francisco Obispo" <[e-mail]> wrote:

>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.

Your interpretation is different from mine of the EPP specifications.  The
term client is generic, where the reference to the "sponsoring client" in
the description of <clID> refers to the registrar.  The reference to
simply "client" in the description of crID and upID can and should refer
to any client including the actual user. It makes no sense to only return
the sponsoring client information for the crID and upID fields, since they
would pretty much almost always match the same value of clID.  It's best
to reference the actual user (Registrar User, Registry User, or whoever)
actually created or updated the object via any of the supported channels
(EPP, Registrar Web Tool, CSR Web Tool, Batch, etc.).  I believe you need
to change the description of the crID and upID fields of the data escrow
to match that of the EPP specifications.  We can continue to debate our
interpretation of the EPP specification as it relates to the crID and upID
elements.  


>
>
>> 	€ 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
>