ICANN/GNSO GNSO Email List Archives

[registrars]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [registrars] Information regarding Data Escrow

  • To: Tim Ruiz <tim@xxxxxxxxxxx>
  • Subject: Re: [registrars] Information regarding Data Escrow
  • From: Thomas Keller <tom@xxxxxxxxxx>
  • Date: Mon, 27 Aug 2007 10:58:16 +0200
  • Cc: Rob Hall <rob@xxxxxxxxxxxxx>, Tim Cole <tim.cole@xxxxxxxxx>, Mike Zupke <mike.zupke@xxxxxxxxx>, Jeffrey Eckhaus <jeckhaus@xxxxxxxxxxxx>, registrars@xxxxxxxxxxxxxx
  • In-reply-to: <20070826082904.4a871ae7d05d2c98d9abb595d392cd69.907bc2df09.wbe@email.secureserver.net>
  • Mail-followup-to: Thomas Keller <tom@xxxxxxxxxx>, Tim Ruiz <tim@xxxxxxxxxxx>, Rob Hall <rob@xxxxxxxxxxxxx>, Tim Cole <tim.cole@xxxxxxxxx>, Mike Zupke <mike.zupke@xxxxxxxxx>, Jeffrey Eckhaus <jeckhaus@xxxxxxxxxxxx>, registrars@xxxxxxxxxxxxxx
  • Organization: Schlund + Partner AG
  • References: <20070826082904.4a871ae7d05d2c98d9abb595d392cd69.907bc2df09.wbe@email.secureserver.net>
  • Sender: owner-registrars@xxxxxxxxxxxxxx
  • User-agent: Mutt/1.5.9i

If ICANN gets the keys there should be ways for them to verify samples.

Best,

tom

Am 26.08.2007 schrieb Tim Ruiz:
> > Hs anyone thought to ask Iron Mountain to give up their ICANN accreditation ? 
> 
> Not sure, but there was a question in the RFP related to that. Keep in
> mind that they already have structural and geographic seperation. The
> escrow services are in Atlanta and the registrar is in the DC area. That
> issue was addressed when they first became accredited.
> 
> As an alternative to giving up their accreditation perhaps they could do
> just the checksum or some other form of upload verification and only
> ICANN and the registrar would have the PGP keys. Some thought would have
> to be given to how ICANN would sample and verify in that case, but I
> think it could be worked out. Might be the way to go regardless of who
> gets the contract.
> 
> 
> Tim 
> 
> 
> 
> -------- Original Message --------
> Subject: RE: [registrars] Information regarding Data Escrow
> From: "Rob Hall" <rob@xxxxxxxxxxxxx>
> Date: Fri, August 24, 2007 12:06 pm
> To: "Jeffrey Eckhaus" <jeckhaus@xxxxxxxxxxxx>, 
> <registrars@xxxxxxxxxxxxxx>
> Cc: "Tim Cole" <tim.cole@xxxxxxxxx>,  "Mike Zupke"
> <mike.zupke@xxxxxxxxx>
> 
> 
> Jeff,
>  
> I believe that part of what Iron Mountain is doing is looking at the
> data randomly and verifying that it is complete and correct.  I think
> they have to report to ICANN that we have delivered properly formatted
> data, and that they look in detail at a subset of it for these purposes.
>  
> So while I think your idea is a great one, I don't think it could be
> applied here, as Iron Mountain would  need to have the keys.
>  
> Rob.
>  
> P.S.  Hs anyone thought to ask Iron Mountain to give up their ICANN
> accreditation ?    Seems to me that this contract is probably worth much
> more to them than the accreditation they are not using.   They might be
> willing to just give it up in order to win the contract, thus removing
> all competitive concerns.
>  
>  
>  
> From: owner-registrars@xxxxxxxxxxxxxx
> [mailto:owner-registrars@xxxxxxxxxxxxxx] On Behalf Of Jeffrey Eckhaus
> Sent: Friday, August 24, 2007 11:21 AM
> To: registrars@xxxxxxxxxxxxxx
> Cc: Tim Cole; Mike Zupke
> Subject: [registrars] Information regarding Data Escrow
> 
> 
>  
> All, 
>  
> I did not see this covered in the questionnaire from Iron Mountain, so
> maybe I missed this, but will there be a form of data encryption held by
> ICANN only? 
>  
> We have been thinking of solutions and one possible solution for the
> concerns of Iron Mountain looking at registrar data is using a form of
> public key cryptography, where the registrars are all given ICANN's
> public key and only ICANN holds the private key.  All of the registrars
> will encrypt their data with that public key, and in the event that this
> data is necessary, the encrypted data can be delivered to ICANN and they
> can use the private key to decrypt it.  This way, even if IRON Mountain
> does look at our data, it's useless to them in an encrypted form. Only
> ICANN can see the data
>  
> If this was covered then I apologize, but if not would like this to be
> considered and thoughts from other Registrars
>  
>  
>  
>  
> Thanks
>  
>  
> Jeff
>  
>  
>  
>  
> -----Original Message-----
> From: owner-registrars@xxxxxxxxxxxxxx
> [mailto:owner-registrars@xxxxxxxxxxxxxx] On Behalf Of Tim Ruiz
> Sent: Friday, August 17, 2007 10:36 AM
> To: registrars@xxxxxxxxxxxxxx
> Subject: RE: [registrars] FW: Information regarding Data Escrow
>  
> Agreed. All valid issues we'll also consider before selecting ICANN's
> agent or another. And the separation issue should likely be covered
> whether the agent is currently accredited as a registrar or not, since
> that could obviously change.
>  
> Tim 
>  
>  
> -------- Original Message --------
> Subject: RE: [registrars] FW: Information regarding Data Escrow
> From: "Nevett, Jonathon" <jnevett@xxxxxxxxxxxxxxxxxxxx>
> Date: Fri, August 17, 2007 8:58 am
> To: "Tim Ruiz" <tim@xxxxxxxxxxx>,  <registrars@xxxxxxxxxxxxxx>
>  
>  
> I am reserving my comments on the escrow program and on Iron Mountain
> until a draft contract is available for review. I appreciate that Iron
> Mountain has provided answers to a questionnaire about how it would
> protect our customer data and how it would address the perceived
> conflict or interest situation, but we don't know how that will
> translate into a contract. Will Iron Mountain agree contractually to
> some sort of structural separation between its registrar business and
> this escrow arrangement? What contractual warranties will Iron Mountain
> provide that it will protect our customer data and cover us in case of a
> breach? Similarly, if ICANN wants to access the data for checking
> purposes, what contractual warranties and protections will it provide to
> registrars in order to give us comfort that our customer data will be
> protected? Perhaps ICANN should be negotiating with the top two bidders
> to ensure that the contract is as competitive as possible.
>  
> Thanks.
>  
> Jon
> -----Original Message-----
> From: owner-registrars@xxxxxxxxxxxxxx
> [mailto:owner-registrars@xxxxxxxxxxxxxx] On Behalf Of Tim Ruiz
> Sent: Friday, August 17, 2007 8:46 AM
> To: registrars@xxxxxxxxxxxxxx
> Subject: RE: [registrars] FW: Information regarding Data Escrow
>  
> Larry, appreciate your concerns.
>  
> 1) Most likely, yes. Escrowing the beneficial user data behind
> private/proxied registrations is not required under the currently
> proposed process. But two points about that. First, speaking just for Go
> Daddy, while there are a large number of our domain names registered
> through Domains by Proxy the majority are not. Second, Domains by Proxy
> is willing to escrow the beneficial user data but not likely under the
> standard Escrow agreement. So that will be discussed with ICANN and
> hopefully worked out soon. And after our experience with assuming the
> RegisterFly names, I hope other registrars who offer private/proxied
> registrations will consider it as well.
>  
> 2) You're assuming that Iron Mountain is currently mining data? Our
> records show no evidence of that at all. I would suggest that before
> making any judgement you look closely at who Iron Mountain is how
> they've built their publicly traded company on a worldwide reputation of
> trust and security. Corp. Domain management is a small part of their
> overall business. It's hard to imagine them sacrificing that reputation
> for what little they might gain from data that is otherwise public
> anyway.
>  
> 3) I doubt that ICANN can select a provider that all registrars will be
> 100% happy with. So there is no requirement to use ICANN's selected
> agent. Some are going to use their own agent regardless. Is Iron
> Mountain more of a risk just because they are accredited any more so
> than another agent who isn't? You may have a different answer to that
> than we do. Fortunately, we'll all have a choice.
>  
> Bottom line, registrars are under fire right now due to recent events.
> We need to get this escrow thing figured out and implemented. If we
> delay with the idea that we need a process that 100% of us are 100%
> happy with it will never get done.
>  
>  
> Tim 
>  
>  
>  
> 
> 
> 
> 
> 

Gruss,

tom

(__)        
(OO)_____  
(oo)    /|\	A cow is not entirely full of
  | |--/ | *    milk some of it is hamburger!
  w w w  w  



<<< Chronological Index >>>    <<< Thread Index >>>