Subject: Re: [ietf-provreg] RFC5910 public client implementation

From: Jens Wagner <[email-masked]>
Date: Tue, 03 Aug 2010 16:59:27 +0200

Hi James,

we just implemented secDNS-1.0 and secDNS-1.1 into our EPP gateway.

It supports both Key Data and DS Data interfaces, as some tlds like .de 
or .eu require Key Data anyways. For other TLDs which require DS Data, 
it automatically creates it using the key data and SHA1 as digest type, 
if using the Key Data interface.

E.g. it accepts the following input

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <update>
      <domain:update xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>secdns.org</domain:name>
      </domain:update>
    </update>
    <extension>
    <secDNS:update xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1">
      <secDNS:rem>
        <secDNS:all>true</secDNS:all>
      </secDNS:rem>
      <secDNS:add>
        <secDNS:keyData>
          <secDNS:flags>256</secDNS:flags>
          <secDNS:protocol>3</secDNS:protocol>
          <secDNS:alg>1</secDNS:alg>
          <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
        </secDNS:keyData>
        <secDNS:keyData>
          <secDNS:flags>257</secDNS:flags>
          <secDNS:protocol>3</secDNS:protocol>
          <secDNS:alg>5</secDNS:alg>
          <secDNS:pubKey>AQPJ////5Q==</secDNS:pubKey>
        </secDNS:keyData>
      </secDNS:add>
    </secDNS:update>
    </extension>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

and creates two DS data record:

<secDNS:dsData>
    <secDNS:keyTag>65535</secDNS:keyTag>
    <secDNS:alg>1</secDNS:alg>
    <secDNS:digestType>1</secDNS:digestType>
    <secDNS:digest>1543C1BABEB5ECAF98774188032928B3CD18299A</secDNS:digest>
    <secDNS:keyData>
        <secDNS:flags>256</secDNS:flags>
        <secDNS:protocol>3</secDNS:protocol>
        <secDNS:alg>1</secDNS:alg>
        <secDNS:pubKey>AQPJ////4Q==</secDNS:pubKey>
    </secDNS:keyData>
</secDNS:dsData>
<secDNS:dsData>
    <secDNS:keyTag>46089</secDNS:keyTag>
    <secDNS:alg>5</secDNS:alg>
    <secDNS:digestType>1</secDNS:digestType>
    <secDNS:digest>2A515440A8AEA13F034191AB0D35DB1DDF7968E8</secDNS:digest>
    <secDNS:keyData>
        <secDNS:flags>257</secDNS:flags>
        <secDNS:protocol>3</secDNS:protocol>
        <secDNS:alg>5</secDNS:alg>
        <secDNS:pubKey>AQPJ////5Q==</secDNS:pubKey>
    </secDNS:keyData>
</secDNS:dsData>

Best,
- jens

James Gould schrieb:
> It's great to hear that the implementations are moving forward.  
>
> We're including support for RFC 5910 and 4310 as part our DNSSEC 
> release of .NET in September.  We updated our Java EPP SDK to include 
> support for both RFC 5910 and 4310 .  The EPP SDK also includes a 
> functional validating Stub Server that has specific test code for 
> supporting both the DS Data Interface and the Key Data Interface of 
> RFC 5910 as well as support for RFC 5910 and 4310 in parallel.  If 
> anyone is interested, the URL below includes some higher level SDK 
> information along with a link to the "Name Store/SRS Bundle" 
> distribution that has the RFC 5910 and 4310 support.  
>
> http://www.verisign.com/domain-name-services/current-registrars/epp-sdk/index.html
>
> Just curious if anyone is planning on supporting the Key Data 
> Interface of RFC 5910?
>
> -- 
>
>
> JG
>
> -------------------------------------------------------
> *James F. Gould
> **Principal Software Engineer
> *VeriSign Naming Services
> [email-masked]
> *Direct:* 703.948.3271
> *Mobile:* 703.628.7063
>
>  
> 21345 Ridgetop Circle
> LS2-2-1
> Dulles, VA 20166
>
> */Notice to Recipient:  /*/This e-mail contains confidential, 
> proprietary and/or Registry  Sensitive information intended solely for 
> the recipient and, thus may not be  retransmitted, reproduced or 
> disclosed without the prior written consent of  VeriSign Naming and 
> Directory Services.  *If you have received  this e-mail message in 
> error, please notify the sender immediately by  telephone or reply 
> e-mail and destroy the original message without making a  copy.* 
>  Thank you.
> /
>
> ------------------------------------------------------------------------
> *From: *Ulrich Wisser <[email-masked]>
> *Date: *Tue, 27 Jul 2010 07:51:09 -0400
> *To: *Frederico A C Neves <[email-masked]>
> *Cc: *EPP Provreg <[email-masked]>
> *Subject: *Re: [ietf-provreg] RFC5910 public client implementation
>
> Congrats!
>
> I'm working on the server implementation for .SE.
>
> /Ulrich
>
>
> --
> Help building the worlds most comprehensive list of judo dojos.
> Put your dojo on the list at http://JudoWorldMap.com
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> List run by majordomo software.  For (Un-)subscription and similar details
> send "help" to [email-masked]
>
>

-- 
Jens Wagner
Chief Executive Officer
HEXONET GmbH
Be Your Own Internet Services Provider

T: +49 6841 69 84 0
F: +49 6841 69 84 199
E: [email-masked]
W: http://www.hexonet.net

HEXONET GmbH, Talstrasse 27, 66424 Homburg, Germany.  CEO & General Manager: Jens Wagner, HRB 2839 (HOM), Amtsgericht Saarbrücken, VAT-ID: DE-138316882
HEXONET Services Inc., 1100 - 1200 West 73rd Avenue, Vancouver, B.C., V6P 6G5, Canada.  CSO & General Manager: Robert Birkner

This email and any files transmitted are confidential and intended only or the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached.

---

From: Oliver Peter <[email-masked]>
Date: Wed, 4 Aug 2010 10:28:37 +0200

On Tue, 03 Aug 2010 16:59:27 +0200

>         <secDNS:pubKey>AQPJ////5Q==</secDNS:pubKey>

Hm, that output above (<secDNS:infData> I guess?) depends on the
<extURI> elements specified by the client within the login frame, right?

In case of using Key Data Interface and specified
urn...secDNS-1.1 within <extURI> I think you have to return the
<secDNS:keyData> elements and not the resulting <secDNS:dsData>.

That's my understanding - please correct me if I'm wrong.

I think we will support the Key Data Interface - but not with
secDNS-1.0 backwards compatibility at the same time.  But the decision
hasn't been made yet.

-- 
Oliver PETER			<[email-masked]>
opDNS Internetdienstleistung	http://opdns.de
Alte Dorfstr. 17		D-93309 Kelheim-Weltenburg
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to [email-masked]

---

From: Jens Wagner <[email-masked]>
Date: Wed, 04 Aug 2010 11:40:12 +0200

Hi Oliver,

Am Mittwoch, den 04.08.2010, 10:28 +0200 schrieb Oliver Peter:
> > ... 

That's right. I just limited the output to the <secDNS:dsData> element,
as it's using the same syntax in both secDNS-1.0 and secDNS-1.1 (except
for <secDNS:maxSigLife>).

Our gateway returns secDNS-1.1 compatible <secDNS:infData>, if the
client included that namespace as an <extURI> on login.

> That's my understanding - please correct me if I'm wrong.

That is correct. We are just supporting the Key Data interface as an
input tool which autocreates DS Data, not sure if that's fully compliant
with section 4.

The one form we support accross all operations is the DS Data Interface
(this is neccessary to support the RFC 4310 in parallel). Some TLDs
require DS Data only, so don't want to force our customers to provide
Key Data if not required.

> secDNS-1.0 backwards compatibility at the same time.  But the decision

As long as you store the Key Data, you can internally convert to
secDNS-1.0 compatible DS Data on-the-fly.

Best,
 -jens

---

From: Maarten Bosteels <[email-masked]>
Date: Mon, 23 Aug 2010 21:01:46 +0200

Hello all,

We signed the .be zone on August 16 and we have a DNSSEC testbed available
for our registrars.
The EPP server on our test-system supports the Key Data interface of
RFC-5910.

We plan to go live with our implementation of RFC-5910 by October 2010.

Maarten Bosteels
Manager Software Development
http://www.dns.be

On Wed, Jul 28, 2010 at 9:26 PM, James Gould <[email-masked]> wrote:

>  It’s great to hear that the implementations are moving forward.
>
> We’re including support for RFC 5910 and 4310 as part our DNSSEC release of
> .NET in September.  We updated our Java EPP SDK to include support for both
> RFC 5910 and 4310 .  The EPP SDK also includes a functional validating Stub
> Server that has specific test code for supporting both the DS Data Interface
> and the Key Data Interface of RFC 5910 as well as support for RFC 5910 and
> 4310 in parallel.  If anyone is interested, the URL below includes some
> higher level SDK information along with a link to the “Name Store/SRS
> Bundle” distribution that has the RFC 5910 and 4310 support.
>
>
> Just curious if anyone is planning on supporting the Key Data Interface of
> RFC 5910?
>
> --
>
>
> JG
>
> *Notice to Recipient:  **This e-mail contains confidential, proprietary
> and/or Registry  Sensitive information intended solely for the recipient
> and, thus may not be  retransmitted, reproduced or disclosed without the
> prior written consent of  VeriSign Naming and Directory Services.  If you
> have received  this e-mail message in error, please notify the sender
> immediately by  telephone or reply e-mail and destroy the original message
> without making a  copy.  Thank you.
> *
>
> ------------------------------