Re: [eppext] Stephen Farrell's Discuss on draft-ietf-eppext-keyrelay-11: (with DISCUSS and COMMENT)

Rik Ribbers <> Thu, 17 December 2015 15:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 904D31B2EFD; Thu, 17 Dec 2015 07:59:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.085
X-Spam-Status: No, score=0.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gvU5vfVS3M14; Thu, 17 Dec 2015 07:59:44 -0800 (PST)
Received: from ( [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 83AEF1B2EFB; Thu, 17 Dec 2015 07:59:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt;; s=sidn-nl; c=relaxed/relaxed; h=from:to:cc:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-mailer:x-ms-exchange-messagesentrepresentingtype:x-ms-exchange-transport-fromentityheader:x-originating-ip:content-type:mime-version; bh=9Kip8O362v4AZe8LXHGJwXnHtDQkTVBD8X+0Wq3JUPc=; b=PYiH/GKTuW8B6z6XnjmTaTD7AC+apsFi+nu+SYOossF3RYUEv2ex2RDIH7UdtKcLUu0Psn4VlmD0KAQy7K5ZrW0glPpxpk/y3iUvMr+HMLUbMnWPiIG++vVssEdYn/Gu4Xtpt9cX2Pl056FdSUSN1C2JLpz0d2j5VBPY5hZQGX0ND+Y5t+MYXadcDMt2kGAq/gq3U1C69jb0h/OfTxfCUFLGpecd7YvWgxhMQ6laRTfNtgFoWZLcVEuC4lGDmd6VVrlGo81OcjmNBGrKcVchYdGzoTqRo8e0EOk+oqmnlAnipwS42OlKyeVeoATjuIB5rRz9wI5UcEfTukxsBmbzcg==
Received: from ka-mbx01.SIDN.local ([]) by with ESMTP id tBHFxdK6016649-tBHFxdK8016649 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Thu, 17 Dec 2015 16:59:39 +0100
Received: from ka-mbx02.SIDN.local ( by ka-mbx01.SIDN.local ( with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 17 Dec 2015 16:59:39 +0100
Received: from ka-mbx02.SIDN.local ([fe80::9855:369a:1ca4:6549]) by ka-mbx02.SIDN.local ([fe80::9855:369a:1ca4:6549%13]) with mapi id 15.00.1130.005; Thu, 17 Dec 2015 16:59:39 +0100
From: Rik Ribbers <>
To: Stephen Farrell <>
Thread-Topic: Stephen Farrell's Discuss on draft-ietf-eppext-keyrelay-11: (with DISCUSS and COMMENT)
Thread-Index: AQHRNy2OAbmkVtJdakmfp1OENAJ/hp7MajcAgALGfQCAABgJgA==
Date: Thu, 17 Dec 2015 15:59:39 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-mailer: Apple Mail (2.3112)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_FE7F777C-BF54-49AC-AF95-500B3F8F5181"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>, Ulrich Wisser <>, eppext <>, Marc Groeneweg <>, The IESG <>
Subject: Re: [eppext] Stephen Farrell's Discuss on draft-ietf-eppext-keyrelay-11: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Dec 2015 15:59:47 -0000

Hello Stephen,

counter proposal:

In this document we define an EPP extension to sent DNSSEC key material 
between EPP clients. This allows DNS operators to bootstrap automatically, reliable and 
securely the transfer of a domain name while keeping the DNSSEC chain of trust intact. 


> Ok, so it's option (a) which is fine. But don't you need to
> say that in the document? I initially assumed you were doing
> (b) which lead to a confusing read. I'd suggest adding a bit
> of text like this near the start:
> "This specification describes a way to use EPP to allow a
> gaining DNS operator to send new public keys to a losing
> DNS operator. Having those new keys signed in the DNS before
> transitioning to the gaining DNS operator means there need
> not be any gap in service when new private keys (at the gaining
> DNS operator) are used to sign DNS records. While there are
> other ways of managing keys during transitions, only this
> method is described in this specification."
> Cheers,
> S.