ICANN ICANN Email List Archives

[gnso-irtp-pdp-jun08]


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

[gnso-irtp-pdp-jun08] FW: electronic authentication mechanisms

  • To: <Gnso-irtp-pdp-jun08@xxxxxxxxx>
  • Subject: [gnso-irtp-pdp-jun08] FW: electronic authentication mechanisms
  • From: "Mike Rodenbaugh" <icann@xxxxxxxxxxxxxx>
  • Date: Tue, 30 Sep 2008 07:32:03 -0700

Please see below info from Dave P. of ICANN Staff and SSAC.  I will continue
to follow on with Nominet as well.

 

Thanks,

Mike R.

 

  _____  

From: Dave Piscitello [mailto:dave.piscitello@xxxxxxxxx] 
Sent: Tuesday, September 30, 2008 5:19 AM
To: mike@xxxxxxxxxxxxxx
Subject: Re: electronic authentication mechanisms

 

Hi Mike,

Jay Daley is the CTO of Nominet, but he is not on SSAC. 
He is on the Registry Internet Security Group (RISG).

I have his email as 

I don't entirely understand the issues the IRTWG is attempting to address
and personally find these much less worrisome than the integrity and
authenticity of registrant communications with registrar, however,

There are several ways to authenticate any request as (a) non-repudiable,
i.e., the recipient is assured that the party claiming to be the originator
did indeed send this message, and (b) authentic, i.e., that the message the
recipient received is identical to the message the originator sent. Often,
confidentiality "comes with" these methods.

1.      PGP signed email - uses a signature technique that builds a web of
trust per client public key 
2.      S/MIME signed email - uses X.509 certs signed by a trusted 3rd party
(if everyone objected to using VeriSign or another public certificate
issuing authority ICANN could easily operate a CA) 
3.      Self-signed or proprietary secure email - all sorts of variants
here. In many of these applications, the vendor provides some proprietary
key generation so no external 3rd party or parties are used to verify the
keys. I only list it here for completeness, it's probably not a good choice
for registrars. 
4.      Signed hash of a transfer request "form" - Here, you use
public/private key pairs to sign the transfer authorization and these could
be self-signed, signed via a web of trust (PGP) or 3rd party (X.509). The
PGP variant is popular in the Open Source development community to provide
developers and adopters with some assurance that the source or executable
they obtain is authentic.  Registrars can send a "signed and hashed"
transfer request  as an email attachment - it's a digital equivalent to
attaching a fax image to an email message - and the receiving registrar can
verify its authenticity and origin. In this case, registrars don't have to
deploy a PGP or S/MIME capable email system but they all have to be able to
verify the digital signature and check the message hash of the PGP or S/MIME
documents (this is available as a application for Windows, *nix, Mac
Operating Systems).


On 9/29/08 8:48 PM, "Mike Rodenbaugh" <mike@xxxxxxxxxxxxxx> wrote:

Hi Dave,

Believe it or not, I also participate on the Inter-Registrar Transfer
Working Group.  We are trying to resolve whether 'electronic authentication
mechanisms' -- other than email -- could and/or should be deployed by
registrars in conducting transfers.  We understand from an earlier report
that Nominet may deploy and/or require PGP in order to authenticate a
transfer request.

I further understand that a member of SSAC is the Nominet CTO, but I don't
recall his name or otherwise know him.  Could you please put me in touch so
we can find our whether and how PGP is implemented, any public info about
how/why they came to that solution, and what other solutions were
considered?  Also, if you have any thoughts or other resources relevant to
this issue, please lmk!

Thanks,
Mike

Mike Rodenbaugh
Rodenbaugh Law
PO Box 7775 #55819
San Francisco, CA  94120
+1.415.254.4590





 



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

Privacy Policy | Terms of Service | Cookies Policy