[eppext] Stephen Farrell's Discuss on draft-ietf-eppext-tmch-smd-04: (with DISCUSS and COMMENT)

"Stephen Farrell" <stephen.farrell@cs.tcd.ie> Mon, 15 February 2016 19:10 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: eppext@ietf.org
Delivered-To: eppext@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 857511ACEEA; Mon, 15 Feb 2016 11:10:46 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.14.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160215191046.25962.24626.idtracker@ietfa.amsl.com>
Date: Mon, 15 Feb 2016 11:10:46 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/YHDfO2QlW8C7S-JalABxPiN_Ww4>
Cc: draft-ietf-eppext-tmch-smd@ietf.org, eppext-chairs@ietf.org, eppext@ietf.org, nkong@cnnic.cn
Subject: [eppext] Stephen Farrell's Discuss on draft-ietf-eppext-tmch-smd-04: (with DISCUSS and COMMENT)
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Feb 2016 19:10:46 -0000

Stephen Farrell has entered the following ballot position for
draft-ietf-eppext-tmch-smd-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Section 7 points to [ICANN-TMCH] for signature validation policy
(I think, not quite sure). I did a quick scan (so I might have
missed it) of that document and did not find any mention of
security or signature validation, so what is an implementer
supposed to do, over and above just checking the cryptographic
correctness of the XMLDSIG? Note1: I'm not asking that all of
the details of how to construct a PKI for this functionality be
documented here, somewhere else is fine, but it doesn't seem to
be in [ICANN-TMCH] that I can see, so I don't know what I'd have
to implement, that'd get interop. Note2: I'm also not asking for
a US-DoD-scale super-huge PKI or RPKI to be specified here,
something simpler should work.


- Please see the secdir review [1] which raises a number of
significant points (including the DISCUSS above) and which
hasn't as far as I've seen gotten a response (apologies if I
missed that).


- "precudle" nice:-)