From nobody Fri Mar 4 07:33:58 2016 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122BA1A21BC; Fri, 4 Mar 2016 07:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Luh4OOhC12u; Fri, 4 Mar 2016 07:33:52 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C8931A21B1; Fri, 4 Mar 2016 07:33:49 -0800 (PST) Received: by mail-ig0-x234.google.com with SMTP id i18so21075538igh.1; Fri, 04 Mar 2016 07:33:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=43DaGjmqClyYeEmd4YBkC9hg78+AnwvlRwy8lOhn5yw=; b=oaMqFyjduEFVKCd+VPpfsn5e8Ekbh4jqwSllZCeQ3spHILxGZA9xXxEbWEDcXkIaAO nM1qa/0sOSIejKVBnHNHV+V8oAQJUYUTx47ON+yabilNFZpPGMaI82K7ruB2v9CR5NTl GmsCTrkG3XHbsLrBeQ73V481uZmlBugEAjF9k+rSDBpTvY9O4/pzloJwdEI7bepfEJkw OEkSd3vIzkWCQ6y4WIzjVCBOuX7F+YsCYMYo3ZEzYFMgPpEkNd9y3ExrM5VXffcb9Gi3 hCnGZrCKQ0NRcPAsgdr8V2a7S7HNRjZCtFKtGyaoB4CYbxOuMPd+2QhKBFa6OaTJ6b+u 2vnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=43DaGjmqClyYeEmd4YBkC9hg78+AnwvlRwy8lOhn5yw=; b=fnaWGHSrglLdGYfDTZszZzZX4HbLiFHyR97ETQSzAVFR/2s7spMZChmohfvkHeudOq C0SGhFSuH/zdLS/iOCdiZ9IPcF8jY0HQ4LoT3GugGURMvk4sOLpBtF+QLX2time/l7Dk 59BSgKR9jNQE/DCsf2C8FMj6TQQWehIiUfDZybtVsmSrmf2wvxQWmEkt5GHYQymkSLyR LZKNav7N+CjIDQBFyNbG2YztZhC2n2xmBT9I3cEyPpCFZFiMDrzw/6LwXHEO0L+Mw7rC rTvJuNQJK47Q6zOXQI52ecGVtFHS1ywqmORoFLr633/lup1i2Tt2N6sOomOUJY0uufLd 2J7Q== X-Gm-Message-State: AD7BkJJcpC1x+3lst8hlr/kntCe/hgzf2a0BWpVoE3ltTsYg2y3e4ITpzCdELU4ZCfnVg0m5fB8bd3EL5qSN/A== MIME-Version: 1.0 X-Received: by 10.50.23.80 with SMTP id k16mr4061894igf.81.1457105628488; Fri, 04 Mar 2016 07:33:48 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.36.59.133 with HTTP; Fri, 4 Mar 2016 07:33:48 -0800 (PST) In-Reply-To: <20160304145753.20582.72023.idtracker@ietfa.amsl.com> References: <20160304145753.20582.72023.idtracker@ietfa.amsl.com> Date: Fri, 4 Mar 2016 10:33:48 -0500 X-Google-Sender-Auth: m3AtLu-XQ6EwqI-nZn7djrktV78 Message-ID: From: Barry Leiba To: regext@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: eppext , "weirds@ietf.org Group" Subject: Re: [eppext] WG Action: Formed Registration Protocols Extensions (regext) X-BeenThere: eppext@ietf.org 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: Fri, 04 Mar 2016 15:33:54 -0000 The regext working group charter has been approved, and that replaces eppext and takes the RDAP follow-on work from weirds. All eppext and weirds subscribers were added to the regext list a while ago, and now, with the regext charter approved, I'll be asking the IT folks to start forwarding messages that are sent to the eppext and weirds mailing lists over to the regext mailing list, and we'll formally close the eppext working group. Everyone, please use in future. Barry, ART Director On Fri, Mar 4, 2016 at 9:57 AM, The IESG wrote: > A new IETF WG has been formed in the Applications and Real-Time Area. For > additional information, please contact the Area Directors or the WG > Chairs. > > Registration Protocols Extensions (regext) > ----------------------------------------------------------------------- > Current status: Proposed WG > > Chairs: > Jim Galvin > Antoin Verschuren > > Assigned Area Director: > Barry Leiba > > Applications and Real-Time Area Directors: > Barry Leiba > Ben Campbell > Alissa Cooper > > Mailing list: > Address: regext@ietf.org > To subscribe: https://www.ietf.org/mailman/listinfo/regext > Archive: https://mailarchive.ietf.org/arch/browse/regext/ > > Charter: https://datatracker.ietf.org/doc/charter-ietf-regext/ > > The Extensible Provisioning Protocol (EPP, Standard 69) is the > standard domain name provisioning protocol for top-level domain name > registries. To avoid many separate EPP extensions that provide > the same functions, it's important to coordinate and standardize EPP > extensions. > > The EPP Extensions (EPPEXT) working group completed its first goal of > creating an IANA registry of EPP extensions. The registration process > of the registry is documented in RFC7451. Extensions may be > registered for informational purposes as long as there is a published > specification that has been reviewed by a designated expert. > > The Registration Data Access Protocol (RDAP, RFCs 7480-7484) is the > proposed standard for retrieving registration metadata from both > domain name and Regional Internet Registries. To ensure interoperable > implementations it's important to coordinate and standardize > extensions and profiles to be used by registries. > > Extensions in both cases that are targeted for the Standards Track are > subject to more thorough review and open discussion within the IETF. > > In addition, commonality may be discovered in related extensions, > especially EPP extensions listed on the EPP extension registry, for > which it would makes sense to merge them into a single standard > extension everybody agrees on. > > The REGEXT working group is the home of the coordination effort for > standards track extensions. The selection of extensions for standards > track shall incorporate the following guidelines. > > 1. Proprietary documented extensions and individual submissions of > informational or experimental EPP extensions will follow the expert > review process as described in RFC7451 for inclusion in the EPP > extensions registry. These documents will not be part of the REGEXT > working group work or milestones. The working group may discuss or > advise on these documents. > > 2. Extensions that seek standards track status can be suggested for WG > adoption. If accepted by the working group then the development of > the standard may proceed. > > 3. When there are no more proposals for Standards-Track extensions, > the working group will either close or become dormant, with the > decision made in consultation with the responsible AD. The charter > will be reviewed by the end of 2017 and will be refreshed by > rechartering if there is still a reason to keep the working group > going. In any case, the mailing list will remain open and available > for the use of the expert review process as described in RFC7451. > > The working group will also identify the requirements for a > registration protocol that allows a third-party service provider to > exchange information with a registry without the need of a registrar > proxy in the middle of the exchange. These requirements will be > documented in an Informational RFC. > > The working group will focus initially on the backlog of EPP and RDAP > extensions. > > Milestones: > Mar 2016 - Submit for publication "Launch Phase Mapping for EPP" > Mar 2016 - Submit for publication "TMCH functional specifications" > Apr 2016 - Submit for publication "EPP and RDAP Status Mapping" > Apr 2016 - Submit for publication "Registry Fee Extension for EPP" > Apr 2016 - Submit for publication "Reseller Extension for EPP" > Apr 2016 - Submit for publication "EPP Reseller Mapping" > Jun 2016 - Submit for publication "Verification Code Extension for EPP" > Jun 2016 - Submit for publication "EPP China Name Verification Mapping" > Jun 2016 - Submit for publication "EPP Domain Name Mapping Extension > for Bundling Registration" > Oct 2016 - Submit for publication "Change Poll Extension for EPP" > Oct 2016 - Submit for publication "Allocation Token Extension for EPP" > Feb 2017 - Submit for publication draft-ietf-eppext-idnmap > Feb 2017 - Submit for publication "EPP IDN Table Mapping" > Feb 2017 - Submit for publication "CIRA IDN EPP Extension" > Jun 2017 - Submit for publication an informational RFC with > requirements for a registration protocol for third-party DNS providers > > From nobody Fri Mar 4 08:18:40 2016 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A44D1A0016; Fri, 4 Mar 2016 08:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbPtLMvz0uDd; Fri, 4 Mar 2016 08:18:34 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B265D1A0060; Fri, 4 Mar 2016 08:18:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3D979BE51; Fri, 4 Mar 2016 16:18:32 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShFLfS1nMOFF; Fri, 4 Mar 2016 16:18:32 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A24F9BE4D; Fri, 4 Mar 2016 16:18:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1457108312; bh=508UI+olH1FOFHrqAuClux+I92eSr+pqt0mtOgfS0J0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=G3pviCXlYXA+gLyxxm4G0fwi5mdJOrc+wgmtEIpjDtkKgYhiSXJn5woEJ7Bg9m9Wo wjZmS81dPrm/PL2YhNc+9ep17pvGAT9iVM+fvssEfWc7DeD88sjq8vB81QYITZgLWR 3iDmQ3M+KmfPtFF0sPHS58QlkwFvT03EUkj/D2y0= To: Gustavo Lozano , The IESG References: <20160215191046.25962.24626.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56D9B557.3020001@cs.tcd.ie> Date: Fri, 4 Mar 2016 16:18:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090204060907050800010707" Archived-At: Cc: "draft-ietf-eppext-tmch-smd@ietf.org" , "eppext-chairs@ietf.org" , "eppext@ietf.org" , "nkong@cnnic.cn" Subject: Re: [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 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 16:18:37 -0000 This is a cryptographically signed message in MIME format. --------------ms090204060907050800010707 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Gustavo, Sorry for the slow response... On 18/02/16 17:20, Gustavo Lozano wrote: > Thank you for your review Stephen, >=20 > Regarding the DISCUSS portion of your email: >=20 > Short story: in the case of the gTLD space, the information regarding t= he > PKI used for validating SMDs is defined here: > https://tools.ietf.org/html/draft-ietf-eppext-tmch-func-spec-00 (sectio= ns: > 4.1, 5.1.1.3, 5.1.2.3, 5.2.1, 5.2.2, 5.2.3.1, 5.2.3.2, 5.2.4, 5.2.5, 6.= 2, > 6.4). Sorry, but that is too short a story for me to grok it:-) >=20 > Long story: https://tools.ietf.org/html/draft-ietf-eppext-tmch-smd-04 (= SMD > draft) was conceived as a draft defining a mapping of the common elemen= ts > found in trademark data. The design goal is that the SMD draft > specification could be used by any entity (e.g. ccTLDs, gTLDs, trademar= k > validators <-> distribution channel) for mapping the tradermak data. Th= e > organizations using the digitally signed portion of the spec will need = to > define a PKI and the policy for that particular use-case scenario.=20 Right. The issue is what information about that PKI is needed in this draft. Without any, all we end up knowing is that the signature bits are ok, but nothing about their meaning. Now that could be a valid approach to take, but you'd need to say so and why say what else is needed to make an implementation of this usable. I'm also puzzled that the func-spec draft you mention above, in section 5.1.1.3, points to a specific root cert (presumably operated by icann?). Presumably that means that the func-spec is specific to what ICANN did and plan to do in future with gTLDs and the func-spec is not meant to be something generic that can be used by e.g. ccTLDs? > In the > case of new gTLDs, the [ICANN-TMCH] > ( ts-30sep13-en.pdf>) is the document (included by reference in the new g= TLD > contracts) defining the policy / technical requirements. The document > [ICANN-TMCH] links to > https://tools.ietf.org/html/draft-ietf-eppext-tmch-func-spec-00=20 I didn't see any mention of that I-D in [ICANN-TMCH] - are we looking at the right things? > 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 d= one > in the gTLD space. I included [ICANN-TMCH] to provide the context for t= he > creation of this spec, an as an example of how it was done for new gTLD= s. Right. The question is what information (about the PKI) is needed for this to be usable in general. Cheers, S. >=20 > Regarding the COMMENT portion of your email: >=20 > - 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). >=20 > [1] > https://www.ietf.org/mail-archive/web/secdir/current/msg06248.html >=20 > Gustavo - I think that I resolved all the issues raised in [1] in versi= on > 04 of the draft. >=20 > - "precudle" nice:-) >=20 >=20 > Gustavo - I will fix this :). >=20 > Regards, >=20 > Gustavo >=20 > On 2/15/16, 11:10, "Stephen Farrell" wrote:= >=20 >> 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 thi= s >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-eppext-tmch-smd/ >> >> >> >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> >> 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. >> >> >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> >> - 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] >> https://www.ietf.org/mail-archive/web/secdir/current/msg06248.html >> >> - "precudle" nice:-) >> >> --------------ms090204060907050800010707 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMDQx NjE4MzFaMC8GCSqGSIb3DQEJBDEiBCCVwgK0S1JbOJWjo8Ce6g76juZ9qoN1kKSsKqwF3JTL CTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCuF8I32/fDRDgYlgSN3li1T6esZgyVun1IfKh8P+BY1KhepaOodW3S Rey0RCPxSWYJFt0klp4dn+2glTmTNSnKKVaNWRoR0vN0aWsiG/pED9t18w7Fasfd2/gWRBs6 +GV+atogO0h9ItxSuaB/VRC27MBxDrxg6f1O7Yy0lH9pLdj05pgzQ7/9hb4HN4ta3zqDQo7Z E+Px3A0itIfjQqoSMR8izPmZ3DPgCkR57CYARj/N8YhEd+QOQsHPrw1CjdAcsDpBK+yXZReM b8fuFQgVMUNkMhbbAWj6ognjow2fphzt/7GJNXDI4qqHR1TZZHKzji4a3mZOSlAGHBK7txuM AAAAAAAA --------------ms090204060907050800010707-- From nobody Sat Mar 5 08:55:02 2016 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C65E1B3409; Sat, 5 Mar 2016 08:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ddcrj9ZUq7rT; Sat, 5 Mar 2016 08:55:00 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC5F91B3407; Sat, 5 Mar 2016 08:54:59 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Sat, 5 Mar 2016 08:54:57 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1130.005; Sat, 5 Mar 2016 08:54:57 -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: AQHRdv++XnUg2/6Y/UWABs4V0JwpkQ== Date: Sat, 5 Mar 2016 16:54:56 +0000 Message-ID: References: <20160215191046.25962.24626.idtracker@ietfa.amsl.com> <56D9B557.3020001@cs.tcd.ie> In-Reply-To: <56D9B557.3020001@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3540041689_11044260" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-eppext-tmch-smd@ietf.org" , "nkong@cnnic.cn" , "eppext@ietf.org" , "eppext-chairs@ietf.org" Subject: Re: [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 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 16:55:02 -0000 --B_3540041689_11044260 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Thank you Stephen, Comments inline. Regards, Gustavo On 3/4/16, 10:18, "Stephen Farrell" wrote: > >Hi Gustavo, > >Sorry for the slow response... > >On 18/02/16 17:20, Gustavo Lozano wrote: >> 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: >> https://tools.ietf.org/html/draft-ietf-eppext-tmch-func-spec-00 >>(sections: >> 4.1, 5.1.1.3, 5.1.2.3, 5.2.1, 5.2.2, 5.2.3.1, 5.2.3.2, 5.2.4, 5.2.5, >>6.2, >> 6.4). > >Sorry, but that is too short a story for me to grok it:-) > >> >> Long story: https://tools.ietf.org/html/draft-ietf-eppext-tmch-smd-04 >>(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. > >Right. The issue is what information about that PKI is needed in this >draft. Without any, all we end up knowing is that the signature bits >are ok, but nothing about their meaning. Now that could be a valid >approach to take, but you'd need to say so and why say what else is >needed to make an implementation of this usable. draft-ietf-eppext-tmch-smd-04 defines the format of the XML blob. In other words, it should be enough to syntactically validate the XML blob (with or without digital signatures). The definition of the PKI is an exercise for a party that wants to use this format, and digitally sign the XML blob. In the case of the ICANN-TMCH, the PKI is defined in draft-ietf-eppext-tmch-func-spec-00. I think that this is explained in the introduction, but the text may need to be tweaked? > >I'm also puzzled that the func-spec draft you mention above, in >section 5.1.1.3, points to a specific root cert (presumably operated by >icann?). Correct, the root cert mentioned in section 5.1.1.3 of draft-ietf-eppext-tmch-func-spec is used for validating the SMDs generated by the ICANN-TMCH. >Presumably that means that the func-spec is specific to >what ICANN did and plan to do in future with gTLDs and the func-spec >is not meant to be something generic that can be used by e.g. ccTLDs? Correct, draft-ietf-eppext-tmch-func-spec is specific to what ICANN did for the new gTLD program. An SMD generated by the ICANN-TMCH basically says: a validator using ICANN policies, validated that X is the holder of the mark Y. A ccTLD may want to use the same policies, and use the root cert provided by ICANN for validating the SMDs generated by the ICANN-TMCH. A ccTLD may want to use different policies, use the format defined in draft-ietf-eppext-tmch-smd-04, and if interested in using digital signatures, define its own PKI. > >> In the >> case of new gTLDs, the [ICANN-TMCH] >> >>(>en >> 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 >> https://tools.ietf.org/html/draft-ietf-eppext-tmch-func-spec-00 > >I didn't see any mention of that I-D in [ICANN-TMCH] - are we looking >at the right things? The draft is mentioned as draft-lozano-tmch-func-spec (see section 2.4.1). The draft was renamed as draft-ietf-eppext-tmch-func-spec when the EPPEXT WG accepted it as a WG document. > >> 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. > >Right. The question is what information (about the PKI) is needed for >this to be usable in general. > >Cheers, >S. > >> >> 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). >> >> [1] >> https://www.ietf.org/mail-archive/web/secdir/current/msg06248.html >> >> 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 :). >> >> Regards, >> >> Gustavo >> >> 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 >>>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: >>> https://datatracker.ietf.org/doc/draft-ietf-eppext-tmch-smd/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> >>> 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. >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> >>> - 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] >>> https://www.ietf.org/mail-archive/web/secdir/current/msg06248.html >>> >>> - "precudle" nice:-) >>> >>> > --B_3540041689_11044260 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITsQYJKoZIhvcNAQcCoIITojCCE54CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EX0wggb4MIIF4KADAgECAhAMNMzaaOCLlcX5TdjpURhNMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMzA1MDgwMDAw MDBaFw0xNjA1MDgxMjAwMDBaMIGiMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9u IGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczERMA8GA1UECxMIUmVnaXN0cnkxFzAV BgNVBAMTDkd1c3Rhdm8gTG96YW5vMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 3w18r+IUAk+jj+kX9oTY/E3q0GyAzR+0x8YvIlksG3cKpkVBqjAKnpZL+GaN98aXYqsIDo8g gctjo1fAx8QxgPkGeZ56EP5uaaN65I1guFa/mVTzSGg2WyXVMRjJmcLBBt//k9APKpvl4Qj4 o+ItgJAKcEA9mtErJB1UE6FtX6ubRd7l/t2BlYHaJLEmdtA4hXfE9TYiVSo4J8652aQ1ba7I g/Qzse32X4A6gm2w6EbEt7m8UVcH0pbxOXpi8Vvz1l6qG3+kxdtJUclg3os4mm0/Iz5glFzM a7OvDyGDbRZbL8ewlnsx3+mjNqDy2S5xNSYFKmdo65xJL1HItfJcSQIDAQABo4IDZzCCA2Mw HwYDVR0jBBgwFoAUFQASKxOYspkH7R7for5XDStnAs0wHQYDVR0OBBYEFDejkLO4b/vTq4z4 /ln0RuaCGgvuMCMGA1UdEQQcMBqBGGd1c3Rhdm8ubG96YW5vQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2 oDSGMmh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3Js MDigNqA0hjJodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0x LmNybDCCAcUGA1UdIASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEW Lmh0dHA6Ly93d3cuZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggr BgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIA dABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQA YQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMA IABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkA IABhAG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkA bgAgAGIAeQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNl cnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQC MAAwDQYJKoZIhvcNAQEFBQADggEBAGaf7RGm6z5gi7JPp8yiw4JQc1rNztSU2JyQfjy3XtFU rrkK3UhhhYKXVoTRL4bSEx2OTc7ejQ2uMNNKU0ew/hPWhx1jU3AMvf6f3FHFt8X/dAcse+TU QyHT822Kup802tVILAijiq+3SnpNoT2VbI1aw1M4lJpIUezERhbDSRkPXMdIK/nRl57KCXc/ PyM2AD4HvdT1OqXQ1j1baeooPcvofWewjD/WyHkpdVbQ+RJ7F1a9ndagERt4D1kTp1yiZwVH 8gKthT5JXVvA1yTOg8Z8nDl2c12SrVQcP/pIAz8VsTNFlIrcO22XGFfyIfj+WFeLkDJeMccK B1IlFAPPKO0wggbCMIIFqqADAgECAhAKBN8hdF1NK4zqM3IFAFDpMA0GCSqGSIb3DQEBBQUA MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5k aWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0w NjExMTAwMDAwMDBaFw0yMTExMTAwMDAwMDBaMGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxE aWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lD ZXJ0IEFzc3VyZWQgSUQgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOiC LZn5ysJClaWAc0Bw0p5WVFypxNJBBo/JM/xNRZFcgZ/tLJz4FlnfnrUkFcKYubR3SdyJxAra r8tea+2tsHEx6886QAxGTZPsi3o2CAOrDDT+GEmC/sfHMUiAfB6iD5IOUMnGh+s2P9gww/+m 9/uizW9zI/6sVgWQ8DIhFonGcIj5BZd9o8dD3QLoOz3tsUGj7T++25VIxO4es/K8DCuZ0MZd EkKB4YNugnM/JksUkK5ZZgrEjb7SzgaurYRvSISbT0C58Uzyr5j79s5AXVz2qPEvr+yJIvJr GGWxwXOt1/HYzx4KdFxCuGh+t9V3CidWfA9ipD8yFGCV/QcEogkCAwEAAaOCA28wggNrMA4G A1UdDwEB/wQEAwIBhjA7BgNVHSUENDAyBggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMD BggrBgEFBQcDBAYIKwYBBQUHAwgwggHGBgNVHSAEggG9MIIBuTCCAbUGC2CGSAGG/WwBAwAE MIIBpDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBv c2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAg AHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABl AHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQBy AHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABs AGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0 AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAPBgNVHRMB Af8EBTADAQH/MH0GCCsGAQUFBwEBBHEwbzAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DQUNlcnRz L0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNydDCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDov L2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0 aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDAd BgNVHQ4EFgQUFQASKxOYspkH7R7for5XDStnAs0wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGL p6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAIRhTkEeuHYEKrW274/yVYW5XVb+Cpjm5L1l in1AKdP8sV1F/Tq4KlszSyRczbm05HOtYV12rXQzimbVI69MH3JuRdl1QLuiO8+NSS/AQbDi KaNROENQmRSsMwY1Yol9d6lSB+VsIFe2gbpvvLPClO12AoDZfM6FqBzsx0NKS7FXz3LO3/Ul PMsiT/2fUtE3ywi7OD7g1T5veQmtW3wxs3c1w+Rj+WgKmAfnRjh3hNI+l7wKoKisJU9EbpHh 0lqva+8wHI2jREKzEIsj+tfmNXQ3rM/rq1gfyYgj/zbUB+o0akfqnZVsnilPU+3jK5UgTirP lmB6+CyA8JVSzimWgWIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3 DQEBBQUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBD QTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMT G0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK 3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lY GDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3La nmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0i rj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNj MGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuC MS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3 DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+Df wWdJs13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3 +owe3WLxvlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMN FG7zfx9jEB76jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB /DCCAfgCAQEwdjBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYD VQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1cmVkIElEIENB LTECEAw0zNpo4IuVxflN2OlRGE0wCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSXgz1x cVu+JsyOGQkgYSvaAsI+LjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xNjAzMDUxNjU0NDlaMA0GCSqGSIb3DQEBAQUABIIBAIlQ0wknrw6C4J2tkOMqiGyg CT9LQplTet/uGuVfcxlrdwGu8T1G8spIjkUEsZA5QkVt/UWfYVwXkbwGrUyLfJgDq7CmzGXp WkQKUN1jzgBXMgVe//pX+g83h72vhIUbcoIVquQLbh3rFJydaXumCPxD0y9xkNlq3m8puuJa WJAFLcS0wLlA/MlAIVDjPf2vmOR9/SDR55tYzrnys3cet0NoJWNt3KEih8Pyfn34795BkZBt mf5cACGF/0JA7xX6HGBuLiWBZVgjZ0ouStJxCMWO3IP8s7XkJbo2TPNtjHHswh2GGx8gwuuD ynGBsTYLmggDFgYybhQtkC4Na9hmVMk= --B_3540041689_11044260-- From nobody Mon Mar 7 07:57:38 2016 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C37B1B4346; Mon, 7 Mar 2016 07:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEjTSGB3QbSh; Mon, 7 Mar 2016 07:57:35 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFEB51B4288; Mon, 7 Mar 2016 07:57:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6930EBE4D; Mon, 7 Mar 2016 15:57:33 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AL6APwaTDRD; Mon, 7 Mar 2016 15:57:33 +0000 (GMT) Received: from [134.226.62.192] (cswireless62-192.scss.tcd.ie [134.226.62.192]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E1BEEBE33; Mon, 7 Mar 2016 15:57:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1457366253; bh=OMchDTl25WhPjhRon1Nq4V6/6lP8JoXG+7iMU9V8pis=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=KhIBDECRruSKwAHMv9s6+HxNN1y9kHxFP6DHTSx4MATapY6rtkTq8JxwBcB2jTbhN 8Z0EKJTtnH/6inDoTvGzwgZq8etZ20xWyR/2uOzk733XsgNdAgxe0PbKSNwIdXIz2+ btgCsWWRCYSXiMbbFQqEZhbtKynyCbXz3QpLpdsY= To: Gustavo Lozano , The IESG References: <20160215191046.25962.24626.idtracker@ietfa.amsl.com> <56D9B557.3020001@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56DDA4EC.7040402@cs.tcd.ie> Date: Mon, 7 Mar 2016 15:57:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070205040802090307050507" Archived-At: Cc: "draft-ietf-eppext-tmch-smd@ietf.org" , "nkong@cnnic.cn" , "eppext@ietf.org" , "eppext-chairs@ietf.org" Subject: Re: [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 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 15:57:37 -0000 This is a cryptographically signed message in MIME format. --------------ms070205040802090307050507 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 05/03/16 16:54, Gustavo Lozano wrote: > Thank you Stephen, >=20 > Comments inline. >=20 > Regards, > Gustavo >=20 > On 3/4/16, 10:18, "Stephen Farrell" wrote: >=20 >> >> Hi Gustavo, >> >> Sorry for the slow response... >> >> On 18/02/16 17:20, Gustavo Lozano wrote: >>> 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: >>> https://tools.ietf.org/html/draft-ietf-eppext-tmch-func-spec-00 >>> (sections: >>> 4.1, 5.1.1.3, 5.1.2.3, 5.2.1, 5.2.2, 5.2.3.1, 5.2.3.2, 5.2.4, 5.2.5, >>> 6.2, >>> 6.4). >> >> Sorry, but that is too short a story for me to grok it:-) >> >>> >>> Long story: https://tools.ietf.org/html/draft-ietf-eppext-tmch-smd-04= >>> (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, tradem= ark >>> validators <-> distribution channel) for mapping the tradermak data. = The >>> organizations using the digitally signed portion of the spec will nee= d >>> to >>> define a PKI and the policy for that particular use-case scenario. >> >> Right. The issue is what information about that PKI is needed in this >> draft. Without any, all we end up knowing is that the signature bits >> are ok, but nothing about their meaning. Now that could be a valid >> approach to take, but you'd need to say so and why say what else is >> needed to make an implementation of this usable. >=20 > draft-ietf-eppext-tmch-smd-04 defines the format of the XML blob. In ot= her > words, it should be enough to syntactically validate the XML blob (with= or > without digital signatures). The definition of the PKI is an exercise f= or > a party that wants to use this format, and digitally sign the XML blob.= In > the case of the ICANN-TMCH, the PKI is defined in > draft-ietf-eppext-tmch-func-spec-00. >=20 >=20 > I think that this is explained in the introduction, but the text may ne= ed > to be tweaked? Yes. Both the abstract and intro say that this document defines a thing called a "digitally signed mark" - some people would consider that to define such a thing, you do need to say how it relates to a PKI, or, in this case, to say that that is defined elsewhere and point at an example of such an elsewhere. >=20 >> >> I'm also puzzled that the func-spec draft you mention above, in >> section 5.1.1.3, points to a specific root cert (presumably operated b= y >> icann?).=20 >=20 > Correct, the root cert mentioned in section 5.1.1.3 of > draft-ietf-eppext-tmch-func-spec is used for validating the SMDs genera= ted > by the ICANN-TMCH. >=20 >> Presumably that means that the func-spec is specific to >> what ICANN did and plan to do in future with gTLDs and the func-spec >> is not meant to be something generic that can be used by e.g. ccTLDs? >=20 > Correct, draft-ietf-eppext-tmch-func-spec is specific to what ICANN did= > for the new gTLD program. An SMD generated by the ICANN-TMCH basically > says: a validator using ICANN policies, validated that X is the holder = of > the mark Y. A ccTLD may want to use the same policies, and use the root= > cert provided by ICANN for validating the SMDs generated by the > ICANN-TMCH. A ccTLD may want to use different policies, use the format > defined in draft-ietf-eppext-tmch-smd-04, and if interested in using > digital signatures, define its own PKI. I think you need that information or an equivalent in this document. The func-spec reference can be informative and not normative if you need to have this document as an RFC before the func-spec. (In that case you'd need to say something like "a PKI for using this with new gTLDs will also be defined by the EPPEXT WG in [func-spec]".) But I think it'd be better if this RFC and the func-spec one popped out together. >>> In the >>> case of new gTLDs, the [ICANN-TMCH] >>> >>> (>> en >>> 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 >>> https://tools.ietf.org/html/draft-ietf-eppext-tmch-func-spec-00 >> >> I didn't see any mention of that I-D in [ICANN-TMCH] - are we looking >> at the right things? >=20 > The draft is mentioned as draft-lozano-tmch-func-spec (see section 2.4.= 1). > The draft was renamed as draft-ietf-eppext-tmch-func-spec when the EPPE= XT > WG accepted it as a WG document. As I suggested above, I think you need to refer to func-spec from this draft. Doing so via the ICANN doc, via an expired I-D seems like a bad idea when you can do it directly. Cheers, S. >=20 >=20 >> >>> where the >>> technical requirements are specified. For example, a ccTLD may use th= is >>> 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. >> >> Right. The question is what information (about the PKI) is needed for >> this to be usable in general. >> >> Cheers, >> S. >> >>> >>> 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). >>> >>> [1] >>> https://www.ietf.org/mail-archive/web/secdir/current/msg06248.html >>> >>> 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 :). >>> >>> Regards, >>> >>> Gustavo >>> >>> On 2/15/16, 11:10, "Stephen Farrell" wrot= e: >>> >>>> 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 al= l >>>> email addresses included in the To and CC lines. (Feel free to cut t= his >>>> 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: >>>> https://datatracker.ietf.org/doc/draft-ietf-eppext-tmch-smd/ >>>> >>>> >>>> >>>> --------------------------------------------------------------------= -- >>>> DISCUSS: >>>> --------------------------------------------------------------------= -- >>>> >>>> >>>> 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. >>>> >>>> >>>> --------------------------------------------------------------------= -- >>>> COMMENT: >>>> --------------------------------------------------------------------= -- >>>> >>>> >>>> - 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] >>>> https://www.ietf.org/mail-archive/web/secdir/current/msg06248.html >>>> >>>> - "precudle" nice:-) >>>> >>>> >> --------------ms070205040802090307050507 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMDcx NTU3MzJaMC8GCSqGSIb3DQEJBDEiBCDWbM5QaDmthKC6KOOKQsFRZfIWLQoXgYohhL6fSv8v 1DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCFTBrKFk0J7pRcaLQCTrCbpIrTE8JfvQY1xs5hbhvXGjZtzVra9LGL E+QbArmLVdXSO50bZhnUatSz/YE6/w2qWAFhjjJzXmk9MkFbuVK4+waeYw41gfiHe3qaIIMt 8TTrzG5V+soeR3rAa2bfj4lEwv9wNNyBKBv6l+VDtHyNW+9lJlyq/9Ru1ND9cYcCoY2FArdF 4DjulJU7p01y4Vp8pcKdtQQ4R9bBsD0cflQpDYFziSIjrejidN+DCLqSeWgQTRoTcRc7r1jE 3vjnibJa16ouerNEBKU3Rv3jpiKJAfjGkRX77ow95cb8shPDQYiK+OWMnACSLFbbqkfP2/a4 AAAAAAAA --------------ms070205040802090307050507-- From nobody Wed Mar 9 10:02:32 2016 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CF412D85C; Wed, 9 Mar 2016 10:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JJkKEIVTcul; Wed, 9 Mar 2016 10:02:24 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7602412D7C3; Wed, 9 Mar 2016 10:02:24 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 9 Mar 2016 10:02:22 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1130.005; Wed, 9 Mar 2016 10:02: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: AQHRei3TFMvNWXALbEqmU069u77+Eg== Date: Wed, 9 Mar 2016 18:02:20 +0000 Message-ID: References: <20160215191046.25962.24626.idtracker@ietfa.amsl.com> <56D9B557.3020001@cs.tcd.ie> <56DDA4EC.7040402@cs.tcd.ie> In-Reply-To: <56DDA4EC.7040402@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3540391337_5171983" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-eppext-tmch-smd@ietf.org" , "nkong@cnnic.cn" , "eppext@ietf.org" , "eppext-chairs@ietf.org" Subject: Re: [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.17 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 18:02:27 -0000 --B_3540391337_5171983 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Thank you Stephan, I appreciate your input, I modified the following paragraph in the introduction section based on your suggestion, and added the tmch-func-spec I-D to the informative section. Do you think that the aforementioned changes solve your concerns? It's worth mentioning that I have not published a newer version of the I-D, because I want to know your thoughts first. - - start - - The detailed policy regarding the public key infrastructure (PKI), authorized validators, and other requirements must be defined based on the local policy of the entities using this specification. In the case of gTLDs, the detailed policy regarding the use of this specification is defined in the Rights Protection Mechanism Requirements document (see [ICANN-TMCH]), and the PKI is defined in [I-D.ietf-eppext-tmch-func-spec]. - - end - Regards, Gustavo On 3/7/16, 15:57, "Stephen Farrell" wrote: > >Hiya, > >On 05/03/16 16:54, Gustavo Lozano wrote: >> Thank you Stephen, >> >> Comments inline. >> >> Regards, >> Gustavo >> >> On 3/4/16, 10:18, "Stephen Farrell" wrote: >> >>> >>> Hi Gustavo, >>> >>> Sorry for the slow response... >>> >>> On 18/02/16 17:20, Gustavo Lozano wrote: >>>> 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: >>>> https://tools.ietf.org/html/draft-ietf-eppext-tmch-func-spec-00 >>>> (sections: >>>> 4.1, 5.1.1.3, 5.1.2.3, 5.2.1, 5.2.2, 5.2.3.1, 5.2.3.2, 5.2.4, 5.2.5, >>>> 6.2, >>>> 6.4). >>> >>> Sorry, but that is too short a story for me to grok it:-) >>> >>>> >>>> Long story: https://tools.ietf.org/html/draft-ietf-eppext-tmch-smd-04 >>>> (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. >>> >>> Right. The issue is what information about that PKI is needed in this >>> draft. Without any, all we end up knowing is that the signature bits >>> are ok, but nothing about their meaning. Now that could be a valid >>> approach to take, but you'd need to say so and why say what else is >>> needed to make an implementation of this usable. >> >> draft-ietf-eppext-tmch-smd-04 defines the format of the XML blob. In >>other >> words, it should be enough to syntactically validate the XML blob (with >>or >> without digital signatures). The definition of the PKI is an exercise >>for >> a party that wants to use this format, and digitally sign the XML blob. >>In >> the case of the ICANN-TMCH, the PKI is defined in >> draft-ietf-eppext-tmch-func-spec-00. >> >> >> I think that this is explained in the introduction, but the text may >>need >> to be tweaked? > >Yes. Both the abstract and intro say that this document defines a thing >called a "digitally signed mark" - some people would consider that to >define such a thing, you do need to say how it relates to a PKI, or, in >this case, to say that that is defined elsewhere and point at an example >of such an elsewhere. > >> >>> >>> I'm also puzzled that the func-spec draft you mention above, in >>> section 5.1.1.3, points to a specific root cert (presumably operated by >>> icann?). >> >> Correct, the root cert mentioned in section 5.1.1.3 of >> draft-ietf-eppext-tmch-func-spec is used for validating the SMDs >>generated >> by the ICANN-TMCH. >> >>> Presumably that means that the func-spec is specific to >>> what ICANN did and plan to do in future with gTLDs and the func-spec >>> is not meant to be something generic that can be used by e.g. ccTLDs? >> >> Correct, draft-ietf-eppext-tmch-func-spec is specific to what ICANN did >> for the new gTLD program. An SMD generated by the ICANN-TMCH basically >> says: a validator using ICANN policies, validated that X is the holder >>of >> the mark Y. A ccTLD may want to use the same policies, and use the root >> cert provided by ICANN for validating the SMDs generated by the >> ICANN-TMCH. A ccTLD may want to use different policies, use the format >> defined in draft-ietf-eppext-tmch-smd-04, and if interested in using >> digital signatures, define its own PKI. > >I think you need that information or an equivalent in this document. >The func-spec reference can be informative and not normative if you need >to have this document as an RFC before the func-spec. (In that case >you'd need to say something like "a PKI for using this with new gTLDs >will also be defined by the EPPEXT WG in [func-spec]".) But I think >it'd be better if this RFC and the func-spec one popped out together. > >>>> In the >>>> case of new gTLDs, the [ICANN-TMCH] >>>> >>>> >>>>(>>>em >>>> en >>>> 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 >>>> https://tools.ietf.org/html/draft-ietf-eppext-tmch-func-spec-00 >>> >>> I didn't see any mention of that I-D in [ICANN-TMCH] - are we looking >>> at the right things? >> >> The draft is mentioned as draft-lozano-tmch-func-spec (see section >>2.4.1). >> The draft was renamed as draft-ietf-eppext-tmch-func-spec when the >>EPPEXT >> WG accepted it as a WG document. > >As I suggested above, I think you need to refer to func-spec from this >draft. Doing so via the ICANN doc, via an expired I-D seems like a bad >idea when you can do it directly. > >Cheers, >S. > >> >> >>> >>>> 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. >>> >>> Right. The question is what information (about the PKI) is needed for >>> this to be usable in general. >>> >>> Cheers, >>> S. >>> >>>> >>>> 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). >>>> >>>> [1] >>>> https://www.ietf.org/mail-archive/web/secdir/current/msg06248.html >>>> >>>> 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 :). >>>> >>>> Regards, >>>> >>>> Gustavo >>>> >>>> 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 >>>>> 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: >>>>> https://datatracker.ietf.org/doc/draft-ietf-eppext-tmch-smd/ >>>>> >>>>> >>>>> >>>>> >>>>>---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> >>>>>---------------------------------------------------------------------- >>>>> >>>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>>---------------------------------------------------------------------- >>>>> COMMENT: >>>>> >>>>>---------------------------------------------------------------------- >>>>> >>>>> >>>>> - 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] >>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg06248.html >>>>> >>>>> - "precudle" nice:-) >>>>> >>>>> --B_3540391337_5171983 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITsQYJKoZIhvcNAQcCoIITojCCE54CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EX0wggb4MIIF4KADAgECAhAMNMzaaOCLlcX5TdjpURhNMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMzA1MDgwMDAw MDBaFw0xNjA1MDgxMjAwMDBaMIGiMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9u IGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczERMA8GA1UECxMIUmVnaXN0cnkxFzAV BgNVBAMTDkd1c3Rhdm8gTG96YW5vMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 3w18r+IUAk+jj+kX9oTY/E3q0GyAzR+0x8YvIlksG3cKpkVBqjAKnpZL+GaN98aXYqsIDo8g gctjo1fAx8QxgPkGeZ56EP5uaaN65I1guFa/mVTzSGg2WyXVMRjJmcLBBt//k9APKpvl4Qj4 o+ItgJAKcEA9mtErJB1UE6FtX6ubRd7l/t2BlYHaJLEmdtA4hXfE9TYiVSo4J8652aQ1ba7I g/Qzse32X4A6gm2w6EbEt7m8UVcH0pbxOXpi8Vvz1l6qG3+kxdtJUclg3os4mm0/Iz5glFzM a7OvDyGDbRZbL8ewlnsx3+mjNqDy2S5xNSYFKmdo65xJL1HItfJcSQIDAQABo4IDZzCCA2Mw HwYDVR0jBBgwFoAUFQASKxOYspkH7R7for5XDStnAs0wHQYDVR0OBBYEFDejkLO4b/vTq4z4 /ln0RuaCGgvuMCMGA1UdEQQcMBqBGGd1c3Rhdm8ubG96YW5vQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2 oDSGMmh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3Js MDigNqA0hjJodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0x LmNybDCCAcUGA1UdIASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEW Lmh0dHA6Ly93d3cuZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggr BgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIA dABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQA YQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMA IABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkA IABhAG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkA bgAgAGIAeQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNl cnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQC MAAwDQYJKoZIhvcNAQEFBQADggEBAGaf7RGm6z5gi7JPp8yiw4JQc1rNztSU2JyQfjy3XtFU rrkK3UhhhYKXVoTRL4bSEx2OTc7ejQ2uMNNKU0ew/hPWhx1jU3AMvf6f3FHFt8X/dAcse+TU QyHT822Kup802tVILAijiq+3SnpNoT2VbI1aw1M4lJpIUezERhbDSRkPXMdIK/nRl57KCXc/ PyM2AD4HvdT1OqXQ1j1baeooPcvofWewjD/WyHkpdVbQ+RJ7F1a9ndagERt4D1kTp1yiZwVH 8gKthT5JXVvA1yTOg8Z8nDl2c12SrVQcP/pIAz8VsTNFlIrcO22XGFfyIfj+WFeLkDJeMccK B1IlFAPPKO0wggbCMIIFqqADAgECAhAKBN8hdF1NK4zqM3IFAFDpMA0GCSqGSIb3DQEBBQUA MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5k aWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0w NjExMTAwMDAwMDBaFw0yMTExMTAwMDAwMDBaMGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxE aWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lD ZXJ0IEFzc3VyZWQgSUQgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOiC LZn5ysJClaWAc0Bw0p5WVFypxNJBBo/JM/xNRZFcgZ/tLJz4FlnfnrUkFcKYubR3SdyJxAra r8tea+2tsHEx6886QAxGTZPsi3o2CAOrDDT+GEmC/sfHMUiAfB6iD5IOUMnGh+s2P9gww/+m 9/uizW9zI/6sVgWQ8DIhFonGcIj5BZd9o8dD3QLoOz3tsUGj7T++25VIxO4es/K8DCuZ0MZd EkKB4YNugnM/JksUkK5ZZgrEjb7SzgaurYRvSISbT0C58Uzyr5j79s5AXVz2qPEvr+yJIvJr GGWxwXOt1/HYzx4KdFxCuGh+t9V3CidWfA9ipD8yFGCV/QcEogkCAwEAAaOCA28wggNrMA4G A1UdDwEB/wQEAwIBhjA7BgNVHSUENDAyBggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMD BggrBgEFBQcDBAYIKwYBBQUHAwgwggHGBgNVHSAEggG9MIIBuTCCAbUGC2CGSAGG/WwBAwAE MIIBpDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBv c2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAg AHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABl AHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQBy AHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABs AGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0 AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAPBgNVHRMB Af8EBTADAQH/MH0GCCsGAQUFBwEBBHEwbzAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DQUNlcnRz L0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNydDCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDov L2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0 aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDAd BgNVHQ4EFgQUFQASKxOYspkH7R7for5XDStnAs0wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGL p6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAIRhTkEeuHYEKrW274/yVYW5XVb+Cpjm5L1l in1AKdP8sV1F/Tq4KlszSyRczbm05HOtYV12rXQzimbVI69MH3JuRdl1QLuiO8+NSS/AQbDi KaNROENQmRSsMwY1Yol9d6lSB+VsIFe2gbpvvLPClO12AoDZfM6FqBzsx0NKS7FXz3LO3/Ul PMsiT/2fUtE3ywi7OD7g1T5veQmtW3wxs3c1w+Rj+WgKmAfnRjh3hNI+l7wKoKisJU9EbpHh 0lqva+8wHI2jREKzEIsj+tfmNXQ3rM/rq1gfyYgj/zbUB+o0akfqnZVsnilPU+3jK5UgTirP lmB6+CyA8JVSzimWgWIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3 DQEBBQUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBD QTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMT G0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK 3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lY GDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3La nmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0i rj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNj MGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuC MS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3 DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+Df wWdJs13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3 +owe3WLxvlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMN FG7zfx9jEB76jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB /DCCAfgCAQEwdjBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYD VQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1cmVkIElEIENB LTECEAw0zNpo4IuVxflN2OlRGE0wCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTgwowC t8lvXYaD9xdEeKFIIt4W9DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xNjAzMDkxODAyMTdaMA0GCSqGSIb3DQEBAQUABIIBADrvhce088cbDPN5S60CcQ7E G4DWg4tKopMaH3tby8YJ1Gx7DSklohm2yCQQmzNgCewkfe6StTi22xiT//2y4R38L10KbUR6 OCP85oOdWGraT9NXSIeP1XNxuZG+ktU0sIAwTDDtjqlQDb/eKAihP7TGTMRTaBFqpZ/HRoxF SKMzitJMpbynlbC863rq3L5E/458jI8QdKH6vMy7X0hW8VoqIuHkK0rWN3GWIjuV3+um3Tq1 m1xFncPeFl1VEE/iQcrN8vSq4zGTg6j+JoNZEwNw27gxcx9fy99rCozrJapWjiG7ea1y6NEw KjPBVtsazB3Cy8MP+gf7UANfWAvjolg= --B_3540391337_5171983-- From nobody Wed Mar 9 13:21:15 2016 Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4BC12D9FA; Wed, 9 Mar 2016 13:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hh6JckBY7MXF; Wed, 9 Mar 2016 13:21:04 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5835912D570; Wed, 9 Mar 2016 13:21:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F2F26BE80; Wed, 9 Mar 2016 21:21:02 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkmKBOEXpTYR; Wed, 9 Mar 2016 21:21:00 +0000 (GMT) Received: from [10.87.49.100] (unknown [86.46.19.12]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DFEF0BE7D; Wed, 9 Mar 2016 21:20:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1457558460; bh=U8NhzGtWt5PiJ6KImDs17wZzAIykJI0f/Zb9QVu0rak=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=KlDXo1PiLzw3JdOBvEYPPPhslhooeckZ597fOeM3Q2J6vdmHgXtaM5ybx+XDvpIWB oFTWT86nZWrNslQTDDt2Chm80r8W/NJ1XpBI+zYa835LuynwgLNSSctNK3htiQZZD8 zH4XJRwH/FUPSE8rUWu4DPnVdr1611P0oQ+/JsvU= To: Gustavo Lozano , The IESG References: <20160215191046.25962.24626.idtracker@ietfa.amsl.com> <56D9B557.3020001@cs.tcd.ie> <56DDA4EC.7040402@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56E093BB.1060906@cs.tcd.ie> Date: Wed, 9 Mar 2016 21:20:59 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040400030807000007000400" Archived-At: Cc: "draft-ietf-eppext-tmch-smd@ietf.org" , "nkong@cnnic.cn" , "eppext@ietf.org" , "eppext-chairs@ietf.org" Subject: Re: [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.17 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 21:21:07 -0000 This is a cryptographically signed message in MIME format. --------------ms040400030807000007000400 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/03/16 18:02, Gustavo Lozano wrote: > Thank you Stephan, I appreciate your input, >=20 > I modified the following paragraph in the introduction section based on= > your suggestion, and added the tmch-func-spec I-D to the informative > section. Do you think that the aforementioned changes solve your concer= ns? >=20 > It's worth mentioning that I have not published a newer version of the > I-D, because I want to know your thoughts first. >=20 > - - start - - > The detailed policy regarding the public key infrastructure (PKI), > authorized validators, and other requirements must be defined based on = the > local policy of the entities using this specification. In the case of > gTLDs, the detailed policy regarding the use of this specification is > defined in the Rights Protection Mechanism Requirements document (see > [ICANN-TMCH]), and the PKI is defined in [I-D.ietf-eppext-tmch-func-spe= c]. > - - end -=20 That's good but needs a little more I think, maybe like: "The detailed policy regarding the public key infrastructure (PKI), authorized validators, and other requirements must be defined based on the local policy of the entities using this specification. In the case of gTLDs, the detailed policy regarding the use of this specification is defined in the Rights Protection Mechanism Requirements document (see [ICANN-TMCH]), and the PKI is defined in [I-D.ietf-eppext-tmch-func-spec]. Implementations will need to implement such a PKI (or an equivalent) in order for the signatures defined in this document to have any useful semantics." I think you also need to say something similar in the security considerations section where you currently only point to ICANN-TMCH. You could do that by pointing back to the above text maybe. Cheers, S. >=20 > Regards, > Gustavo >=20 > On 3/7/16, 15:57, "Stephen Farrell" wrote: >=20 >> >> Hiya, >> >> On 05/03/16 16:54, Gustavo Lozano wrote: >>> Thank you Stephen, >>> >>> Comments inline. >>> >>> Regards, >>> Gustavo >>> >>> On 3/4/16, 10:18, "Stephen Farrell" wrote= : >>> >>>> >>>> Hi Gustavo, >>>> >>>> Sorry for the slow response... >>>> >>>> On 18/02/16 17:20, Gustavo Lozano wrote: >>>>> Thank you for your review Stephen, >>>>> >>>>> Regarding the DISCUSS portion of your email: >>>>> >>>>> Short story: in the case of the gTLD space, the information regardi= ng >>>>> the >>>>> PKI used for validating SMDs is defined here: >>>>> https://tools.ietf.org/html/draft-ietf-eppext-tmch-func-spec-00 >>>>> (sections: >>>>> 4.1, 5.1.1.3, 5.1.2.3, 5.2.1, 5.2.2, 5.2.3.1, 5.2.3.2, 5.2.4, 5.2.5= , >>>>> 6.2, >>>>> 6.4). >>>> >>>> Sorry, but that is too short a story for me to grok it:-) >>>> >>>>> >>>>> Long story: https://tools.ietf.org/html/draft-ietf-eppext-tmch-smd-= 04 >>>>> (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= =2E >>>>> The >>>>> organizations using the digitally signed portion of the spec will n= eed >>>>> to >>>>> define a PKI and the policy for that particular use-case scenario. >>>> >>>> Right. The issue is what information about that PKI is needed in thi= s >>>> draft. Without any, all we end up knowing is that the signature bits= >>>> are ok, but nothing about their meaning. Now that could be a valid >>>> approach to take, but you'd need to say so and why say what else is >>>> needed to make an implementation of this usable. >>> >>> draft-ietf-eppext-tmch-smd-04 defines the format of the XML blob. In >>> other >>> words, it should be enough to syntactically validate the XML blob (wi= th >>> or >>> without digital signatures). The definition of the PKI is an exercise= >>> for >>> a party that wants to use this format, and digitally sign the XML blo= b. >>> In >>> the case of the ICANN-TMCH, the PKI is defined in >>> draft-ietf-eppext-tmch-func-spec-00. >>> >>> >>> I think that this is explained in the introduction, but the text may >>> need >>> to be tweaked? >> >> Yes. Both the abstract and intro say that this document defines a thin= g >> called a "digitally signed mark" - some people would consider that to >> define such a thing, you do need to say how it relates to a PKI, or, i= n >> this case, to say that that is defined elsewhere and point at an examp= le >> of such an elsewhere. >> >>> >>>> >>>> I'm also puzzled that the func-spec draft you mention above, in >>>> section 5.1.1.3, points to a specific root cert (presumably operated= by >>>> icann?).=20 >>> >>> Correct, the root cert mentioned in section 5.1.1.3 of >>> draft-ietf-eppext-tmch-func-spec is used for validating the SMDs >>> generated >>> by the ICANN-TMCH. >>> >>>> Presumably that means that the func-spec is specific to >>>> what ICANN did and plan to do in future with gTLDs and the func-spec= >>>> is not meant to be something generic that can be used by e.g. ccTLDs= ? >>> >>> Correct, draft-ietf-eppext-tmch-func-spec is specific to what ICANN d= id >>> for the new gTLD program. An SMD generated by the ICANN-TMCH basicall= y >>> says: a validator using ICANN policies, validated that X is the holde= r >>> of >>> the mark Y. A ccTLD may want to use the same policies, and use the ro= ot >>> cert provided by ICANN for validating the SMDs generated by the >>> ICANN-TMCH. A ccTLD may want to use different policies, use the forma= t >>> defined in draft-ietf-eppext-tmch-smd-04, and if interested in using >>> digital signatures, define its own PKI. >> >> I think you need that information or an equivalent in this document. >> The func-spec reference can be informative and not normative if you ne= ed >> to have this document as an RFC before the func-spec. (In that case >> you'd need to say something like "a PKI for using this with new gTLDs >> will also be defined by the EPPEXT WG in [func-spec]".) But I think >> it'd be better if this RFC and the func-spec one popped out together. >> >>>>> In the >>>>> case of new gTLDs, the [ICANN-TMCH] >>>>> >>>>> >>>>> (>>>> em >>>>> en >>>>> ts-30sep13-en.pdf>) is the document (included by reference in the n= ew >>>>> gTLD >>>>> contracts) defining the policy / technical requirements. The docume= nt >>>>> [ICANN-TMCH] links to >>>>> https://tools.ietf.org/html/draft-ietf-eppext-tmch-func-spec-00 >>>> >>>> I didn't see any mention of that I-D in [ICANN-TMCH] - are we lookin= g >>>> at the right things? >>> >>> The draft is mentioned as draft-lozano-tmch-func-spec (see section >>> 2.4.1). >>> The draft was renamed as draft-ietf-eppext-tmch-func-spec when the >>> EPPEXT >>> WG accepted it as a WG document. >> >> As I suggested above, I think you need to refer to func-spec from this= >> draft. Doing so via the ICANN doc, via an expired I-D seems like a bad= >> idea when you can do it directly. >> >> Cheers, >> S. >> >>> >>> >>>> >>>>> 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 w= as >>>>> done >>>>> in the gTLD space. I included [ICANN-TMCH] to provide the context f= or >>>>> the >>>>> creation of this spec, an as an example of how it was done for new >>>>> gTLDs. >>>> >>>> Right. The question is what information (about the PKI) is needed fo= r >>>> this to be usable in general. >>>> >>>> Cheers, >>>> S. >>>> >>>>> >>>>> 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). >>>>> >>>>> [1] >>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg06248.html >>>>> >>>>> 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 :). >>>>> >>>>> Regards, >>>>> >>>>> Gustavo >>>>> >>>>> 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 >>>>>> 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= : >>>>>> https://datatracker.ietf.org/doc/draft-ietf-eppext-tmch-smd/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------= ---- >>>>>> DISCUSS: >>>>>> >>>>>> ------------------------------------------------------------------= ---- >>>>>> >>>>>> >>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------= ---- >>>>>> COMMENT: >>>>>> >>>>>> ------------------------------------------------------------------= ---- >>>>>> >>>>>> >>>>>> - 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] >>>>>> https://www.ietf.org/mail-archive/web/secdir/current/msg06248.html= >>>>>> >>>>>> - "precudle" nice:-) >>>>>> >>>>>> --------------ms040400030807000007000400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMDky MTIwNTlaMC8GCSqGSIb3DQEJBDEiBCCA6resDaXg/qCjQ3NTMuX17bEqVhzRlKZmBvXUtAIq wDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCZqK4NBZbRUMKV1wrlZYE8wdLOXimPVWfiKYlWs4JerBt2tWW0UoG7 mWoP3qU4UyTobzwpskmpE3adBoEE5Z5yCjFyQX30h6+6/2iH2cGFnwURWJ87TI2XBiVcBpxM /tCTWtBssPdLMoIbw1K6TjqVZxgamXKzkBpV1xEcftOpZPMRWRZIjoTPi9WgIKDxaoI9ALJR 3UNjDbipAC0E9wO4k8LGbvrQ4Xp/euUIdq4SakskgTA2JwTFf2+Uh6UG3+J1MKWqelI2dU+z PO1004gcVWnkOKmnx1DcR+SPAYob30qBghhBIk5HL0i9A8adkNFZ+x7ZufVPZvMBpmi/ZZ3L AAAAAAAA --------------ms040400030807000007000400-- From nobody Thu Mar 10 04:10:33 2016 Return-Path: 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 D887712D6E0; Thu, 10 Mar 2016 04:10:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160310121028.9104.60700.idtracker@ietfa.amsl.com> Date: Thu, 10 Mar 2016 04:10:28 -0800 Archived-At: Cc: eppext@ietf.org Subject: [eppext] I-D Action: draft-ietf-eppext-tmch-smd-06.txt X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.17 List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 12:10:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Provisioning Protocol Extensions of the IETF. Title : Mark and Signed Mark Objects Mapping Author : Gustavo Lozano Filename : draft-ietf-eppext-tmch-smd-06.txt Pages : 27 Date : 2016-03-10 Abstract: Domain Name Registries (DNRs) may operate in special modes for certain periods of time enabling trademark holders to protect their rights during the introduction of a Top Level Domain (TLD). One of those special modes of operation is the Sunrise Period. The Sunrise Period allows trademark holders an advance opportunity to register domain names corresponding to their trademarks before names are generally available to the public. This document describes the format of a mark and a digitally signed mark used by trademark holders for registering domain names during the sunrise phase of generic Top Level Domains (gTLDs). Three types of mark objects are defined in this specification: registered trademarks, court-validated marks, and marks protected by statue or treaty. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eppext-tmch-smd/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-eppext-tmch-smd-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-eppext-tmch-smd-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/