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

Gustavo Lozano <> Thu, 18 February 2016 17:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 22A2E1B3149; Thu, 18 Feb 2016 09:20:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t4rZsY9m-S3N; Thu, 18 Feb 2016 09:20:24 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3AA6E1B314F; Thu, 18 Feb 2016 09:20:24 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 18 Feb 2016 09:20:21 -0800
Received: from ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1130.005; Thu, 18 Feb 2016 09:20:21 -0800
From: Gustavo Lozano <>
To: Stephen Farrell <>, The IESG <>
Thread-Topic: Stephen Farrell's Discuss on draft-ietf-eppext-tmch-smd-04: (with DISCUSS and COMMENT)
Thread-Index: AQHRanCkrFsYsBamS0CJSQ5Aj4BPiw==
Date: Thu, 18 Feb 2016 17:20:20 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3538632017_545259"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>, "" <>, "" <>
Subject: Re: [eppext] Stephen Farrell's Discuss on draft-ietf-eppext-tmch-smd-04: (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, 18 Feb 2016 17:20:26 -0000

Thank you for your review Stephen,

Regarding the DISCUSS portion of your email:

Short story: in the case of the gTLD space, the information regarding the
PKI used for validating SMDs is defined here: (sections:
4.1,,, 5.2.1, 5.2.2,,, 5.2.4, 5.2.5, 6.2,

Long story: (SMD
draft) was conceived as a draft defining a mapping of the common elements
found in trademark data. The design goal is that the SMD draft
specification could be used by any entity (e.g. ccTLDs, gTLDs, trademark
validators <-> distribution channel) for mapping the tradermak data. The
organizations using the digitally signed portion of the spec will need to
define a PKI and the policy for that particular use-case scenario. In the
case of new gTLDs, the [ICANN-TMCH]
ts-30sep13-en.pdf>) is the document (included by reference in the new gTLD
contracts) defining the policy / technical requirements. The document
[ICANN-TMCH] links to where the
technical requirements are specified. For example, a ccTLD may use this
spec with different policy / technical requirements, therefore
[ICANN-TMCH] / draft-ietf-eppext-tmch-func-spec-00 is just how it was done
in the gTLD space. I included [ICANN-TMCH] to provide the context for the
creation of this spec, an as an example of how it was done for new gTLDs.

Regarding the COMMENT portion of your email:

- 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).


Gustavo - I think that I resolved all the issues raised in [1] in version
04 of the draft.

- "precudle" nice:-)

Gustavo - I will fix this :).



On 2/15/16, 11:10, "Stephen Farrell" <> wrote:

>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
>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).
>   [1]
>- "precudle" nice:-)