--- 1/draft-ietf-regext-tmch-func-spec-01.txt 2016-10-04 16:15:55.729699383 -0700 +++ 2/draft-ietf-regext-tmch-func-spec-02.txt 2016-10-04 16:15:55.837702140 -0700 @@ -1,18 +1,18 @@ Internet Engineering Task Force G. Lozano Internet-Draft ICANN -Intended status: Standards Track June 8, 2016 -Expires: December 10, 2016 +Intended status: Informational October 3, 2016 +Expires: April 6, 2017 ICANN TMCH functional specifications - draft-ietf-regext-tmch-func-spec-01 + draft-ietf-regext-tmch-func-spec-02 Abstract This document describes the requirements, the architecture and the interfaces between the ICANN Trademark Clearinghouse (TMCH) and Domain Name Registries as well as between the ICANN TMCH and Domain Name Registrars for the provisioning and management of domain names during Sunrise and Trademark Claims Periods. Status of This Memo @@ -23,21 +23,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 10, 2016. + This Internet-Draft will expire on April 6, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -113,24 +113,24 @@ 6.3. List of Registered Domain Names (LORDN) file . . . . . . 34 6.3.1. LORDN Log file . . . . . . . . . . . . . . . . . . . 39 6.3.1.1. LORDN Log Result Codes . . . . . . . . . . . . . 41 6.4. Signed Mark Data (SMD) File . . . . . . . . . . . . . . . 45 6.5. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 46 6.6. Sunrise List (SURL) . . . . . . . . . . . . . . . . . . . 53 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 54 7.1. Trademark Claims Notice (TCN) . . . . . . . . . . . . . . 54 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 57 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 58 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 11.1. Normative References . . . . . . . . . . . . . . . . . . 58 - 11.2. Informative References . . . . . . . . . . . . . . . . . 58 + 11.2. Informative References . . . . . . . . . . . . . . . . . 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 60 1. Introduction 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). Along with the introduction of new generic TLDs (gTLD), two special modes came into effect: @@ -193,52 +193,51 @@ o CRL: Certificate Revocation List, see [RFC5280]. o CSV: Comma-Separated Values, see [RFC4180] o Date and time, datetime: Date and time are specified following the standard "Date and Time on the Internet specification", see [RFC3339]. o DN, Domain Name, domain name: see definition of Domain name in - [RFC7719]. In case of IDNs, the A-label form MUST be used, i.e. - each of the DNLs are an A-label or NR-LDH (see [RFC5890]). + [RFC7719]. o DNROID, DN Repository Object IDentifier: an identifier assigned by the Registry to each DN object that unequivocally identifies said DN object. For example, if a new DN object is created for a name that existed in the past, the DN objects will have different DNROIDs. - o DNL, Domain Name Label, see definition of Label in [RFC7719]. The - DNL is an A-label or NR-LDH. + o DNL, Domain Name Label, the DNL is an A-label or NR-LDH label (see + [RFC5890]). o DNL List: A list of DNLs that are covered by a PRM. o DNS: Domain Name System, see [RFC7719]. o Effective allocation: A DN is considered effectively allocated when the DN object for the DN has been created in the SRS of the Registry and has been assigned to the effective user. A DN object in status "pendingCreate" or any other status that precedes the first time a DN is assigned to an end-user is not considered an effective allocation. A DN object created internally by the Registry for subsequent delegation to another Registrant is not considered an effective allocation. o EPP: The Extensible Provisioning Protocol, see definition of EPP in [RFC7719]. o FQDN: Fully-Qualified Domain Name, see definition of FQDN in [RFC7719]. - o HTTP: Hypertext Transfer Protocol, see [RFC2616] + o HTTP: Hypertext Transfer Protocol, see [RFC7230] and [RFC7231]. o HTTPS: HTTP over TLS (Transport Layer Security), [RFC2818]. o IDN: Internationalized Domain Name, see definition of IDN in [RFC7719]. o Lookup Key: A random string of up to 51 chars from the set [a-zA- Z0-9/] to be used as the lookup key by Registrars to obtain the TCN using the CNIS. Lookup Keys are unique and are related to one DNL only. @@ -273,24 +272,23 @@ o Registrar, Domain Name Registrar: see definition of Registrar in [RFC7719]. o Registry, Domain Name Registry, Registry Operator: see definition of Registry in [RFC7719]. A Registry Operator is the contracting party with ICANN for the TLD. o SMD, Signed Mark Data: A cryptographically signed token issued by the TMV to the TMH to be used in the Sunrise Period to apply for a - DN that matches a DNL of a PRM; see also - [I-D.ietf-eppext-tmch-smd]. An SMD generated by an ICANN-approved - trademark validator (TMV) contains both the signed token and the - TMV's PKIX certificate. + DN that matches a DNL of a PRM; see also [RFC7848]. An SMD + generated by an ICANN-approved trademark validator (TMV) contains + both the signed token and the TMV's PKIX certificate. o SMD File: A file containing the SMD (see above) and some human readable data. The latter is usually ignored in the processing of the SMD File. See also Section 6.4. o SMD Revocation List: The SMD Revocation List is used by Registries (and optionally by Registrars) during the Sunrise Period to ensure that an SMD is still valid (i.e. not revoked). The SMD Revocation List has a similar function as CRLs used in PKI. @@ -597,22 +595,22 @@ o Fetch the SMD Revocation List via the sy interface (Section 4.3.11). o Fetch the DNL List from the TMDB via the dy interface (Section 4.3.3). o Upload the LORDN to the TMDB via the yd interface (Section 4.3.7). This access restriction MAY be applied by the TMDB in addition to - HTTP Basic access authentication (for credentials to be used, see - Section 5.1.1.1). + HTTP Basic access authentication (see [RFC7235]). For credentials to + be used, see Section 5.1.1.1. The TMDB MAY limit the number of IP addresses to be accepted per Registry Operator. 5.1.1.3. ICANN TMCH Trust Anchor Each Registry Operator MUST fetch the PKIX certificate ([RFC5280]) of the ICANN TMCH-CA (Trust Anchor) from < https://ca.icann.org/ tmch.crt > to be used: @@ -760,25 +758,24 @@ 5. The signature of the SMD (signed with the TMV certificate) is valid. 6. The datetime when the validation is done is within the validity period of the SMD based on and elements. 7. The SMD has not been revoked, i.e., is not contained in the SMD Revocation List. - 8. The leftmost DNL of the DN (A-label form in the case of IDNs) - being effectively allocated matches one of the labels - () elements in the SMD. For example, if the DN "xn-- - mgbachtv.xn--mgbh0fb" is being effectively allocated, the - leftmost DNL would be "xn--mgbachtv". + 8. The leftmost DNL of the DN being effectively allocated matches + one of the labels () elements in the SMD. For + example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being + effectively allocated, the leftmost DNL would be "xn--mgbachtv". These procedure apply to all DN effective allocations at the second level as well as to all other levels subordinate to the TLD that the Registry accepts registrations for. 5.2.3. TMDB Sunrise Services for Registries 5.2.3.1. SMD Revocation List A new SMD Revocation List MUST be published by the TMDB twice a day, @@ -1033,30 +1030,30 @@ the Registrar for a DN matching a DNL of a PRM, but the DNL was inserted (or re-inserted) for the first time into DNL List less than 24 hours ago, the registration MAY continue without this data and the tests listed below are not required to be performed. 2. The TCN has not expired (according to the expiration datetime sent by the Registrar). 3. The acceptance datetime is no more than 48 hours in the past, - or a different value defined by policy. + or a different value defined by ICANN policy. - 4. Using the leftmost DNL of the DN (A-label form in the case of - IDNs) being effectively allocated, the expiration datetime - provided by the Registrar, and the TMDB Notice Identifier - extracted from the TCNID provided by the Registrar compute the - TCN Checksum. Verify that the computed TCN Checksum match the - TCN Checksum present in the TCNID. For example, if the DN - "xn--mgbachtv.xn--mgbh0fb" is being effectively allocated, the - leftmost DNL would be "xn--mgbachtv". + 4. Using the leftmost DNL of the DN being effectively allocated, + the expiration datetime provided by the Registrar, and the + TMDB Notice Identifier extracted from the TCNID provided by + the Registrar compute the TCN Checksum. Verify that the + computed TCN Checksum match the TCN Checksum present in the + TCNID. For example, if the DN "xn--mgbachtv.xn--mgbh0fb" is + being effectively allocated, the leftmost DNL would be "xn-- + mgbachtv". These procedures apply to all DN registrations at the second level as well as to all other levels subordinate to the TLD that the Registry accepts registrations for. 5.3.3. TMBD Trademark Claims Services for Registries 5.3.3.1. Domain Name Label (DNL) List A new DNL List MUST be published by the TMDB twice a day, by 00:00:00 @@ -1121,47 +1118,47 @@ 4. Perform the minimum set of checks for verifying DN registrations. If any of these checks fails the Registrar MUST abort the DN registration. Each of these checks MUST be performed before the registration is sent to the Registry. Performing the minimum set of checks Registrars MUST verify that: 1. The datetime when the validation is done is within the TCN validity based on the and elements. - 2. The leftmost DNL of the DN (A-label form in the case of IDNs) - being effectively allocated matches the label - () element in the TCN. For example, if the - DN "xn--mgbachtv.xn--mgbh0fb" is being effectively allocated, - the leftmost DNL would be "xn--mgbachtv". + 2. The leftmost DNL of the DN being effectively allocated + matches the label () element in the TCN. For + example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being + effectively allocated, the leftmost DNL would be "xn-- + mgbachtv". 3. The Registrant has acknowledged (expressed his/her consent with) the TCN. 5. Record the date and time when the registrant acknowledged the TCN. 6. Send the registration to the Registry (ry interface, Section 4.3.5) and include the following information: * TCNID () * Expiration date of the TCN () * Acceptance datetime of the TCN. TCNs are generated twice a day. The expiration date () of each TCN MUST be set to 48 hours (or a - different value if defined by policy) in the future by the TMDB, - allowing the implementation of a cache by Registrars and enough time - for acknowledging the TCN. Registrars SHOULD implement a cache of - TCNs to minimize the number of queries sent to the TMDB. A cached + different value if defined by ICANN policy) in the future by the + TMDB, allowing the implementation of a cache by Registrars and enough + time for acknowledging the TCN. Registrars SHOULD implement a cache + of TCNs to minimize the number of queries sent to the TMDB. A cached TCN MUST be removed from the cache after the expiration date of the TCN as defined by . The TMDB MAY implement rate- limiting as one of the protection mechanisms to mitigate the risk of performance degradation. 5.3.5. TMBD Trademark Claims Services for Registrars 5.3.5.1. Claims Notice Information Service (CNIS) The TCNs are provided by the TMDB online and are fetched by the @@ -1198,27 +1195,27 @@ During the OPTIONAL (see [QLP-Addendum]) Qualified Launch Program (QLP) Period effective allocations of DNs to third parties could require that Registries and Registrars provide Sunrise and/or Trademark Claims services. If required, Registries and Registrars MUST provide Sunrise and/or Trademark Claims services as described in Section 5.2 and Section 5.3. The effective allocation scenarios are: - o If the leftmost DNL of the DN (A-label form in the case of IDNs) - being effectively allocated (QLP Name in this section) matches a - DNL in the SURL, and an SMD is provided, then Registries MUST - provide Sunrise Services (see Section 5.2) and the DN MUST be - reported in a Sunrise LORDN file during the QLP Period. For - example, if the DN "xn--mgbachtv.xn--mgbh0fb" is being effectively - allocated, the leftmost DNL would be "xn--mgbachtv". + o If the leftmost DNL of the DN being effectively allocated (QLP + Name in this section) matches a DNL in the SURL, and an SMD is + provided, then Registries MUST provide Sunrise Services (see + Section 5.2) and the DN MUST be reported in a Sunrise LORDN file + during the QLP Period. For example, if the DN "xn--mgbachtv.xn-- + mgbh0fb" is being effectively allocated, the leftmost DNL would be + "xn--mgbachtv". o If the QLP Name matches a DNL in the SURL but does not match a DNL in the DNL List, and an SMD is NOT provided (see section 2.2 of [QLP-Addendum]), then the DN MUST be reported in a Sunrise LORDN file using the special SMD-id "99999-99999" during the QLP Period. o If the QLP Name matches a DNL in the SURL and also matches a DNL in the DNL List, and an SMD is NOT provided (see section 2.2 of [QLP-Addendum]), then Registries MUST provide Trademark Claims services (see Section 5.3) and the DN MUST be reported in a @@ -1579,21 +1576,21 @@ * One or more lines with: ,,,,, Where: - , DN Repository Object IDentifier (DNROID) in the SRS. - , DN that was effectively allocated. For - IDNs, the A-Label form is used. + IDNs, the A-label form is used. - , SMD ID used for registration. - , IANA Registrar ID. - , date and time in UTC that the domain was effectively allocated. - OPTIONAL , date and time in UTC that the application was created. The @@ -1638,21 +1635,21 @@ * One or more lines with: ,,,,,, Where: - , DN Repository Object IDentifier (DNROID) in the SRS. - , DN that was effectively allocated. For - IDNs, the A-Label form is used. + IDNs, the A-label form is used. - , Trademark Claims Notice Identifier as specified in . - , IANA Registrar ID. - , date and time in UTC that the domain was effectively allocated. - , date and time in UTC @@ -1983,30 +1980,30 @@ purposes, i.e. any data outside these boundaries as well as the boundaries themselves MUST be ignored for validation purposes. The structure of the SMD File is as follows, all the elements are REQUIRED, and MUST appear in the specified order. 1. Marks: 2. smdID: - 3. U-labels: + 3. U-labels: 4. notBefore: 5. notAfter: 6. -----BEGIN ENCODED SMD----- - 7. + 7. 8. -----END ENCODED SMD----- Example of an SMD File: Marks: Example One smdID: 1-2 U-labels: example-one, exampleone notBefore: 2011-08-16 09:00 notAfter: 2012-08-16 09:00 -----BEGIN ENCODED SMD----- @@ -2056,27 +2053,27 @@ since 1970-01-01T00:00:00Z not counting leap seconds. For example, the conversion to Unix time of 2010-08-16T09:00:00.0Z is shown: unix_time(2010-08-16T09:00:00.0Z)=1281949200 The TMDB uses the and elements from the TCN along with the TMDB Notice Identifier to compute the TCN Checksum. - A Registry MUST use the leftmost DNL of the DN (A-label form in - the case of IDNs) being effectively allocated, the expiration - datetime of the TCN (provided by the Registrar) and the TMDB - Notice Identifier extracted from the TCNID (provided by the - Registrar) to compute the TCN Checksum. For example, if the DN - "xn--mgbachtv.xn--mgbh0fb" is being effectively allocated, the - leftmost DNL would be "xn--mgbachtv". + A Registry MUST use the leftmost DNL of the DN being + effectively allocated, the expiration datetime of the TCN + (provided by the Registrar) and the TMDB Notice Identifier + extracted from the TCNID (provided by the Registrar) to compute + the TCN Checksum. For example, if the DN "xn--mgbachtv.xn-- + mgbh0fb" is being effectively allocated, the leftmost DNL would + be "xn--mgbachtv". Example of computation of the TCN Checksum: CRC32(example-one12819492009223372036854775807)=370d0b7c o A element that contains the start of the validity date and time of the TCN. o A element that contains the expiration date and time of the TCN. @@ -2545,29 +2542,38 @@ provided by James Gould, James Mitchell and Francisco Arias. This document includes feedback received from the following individuals: Paul Hoffman. 9. IANA Considerations This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. One URI assignment have been registered by the IANA. - Registration request for the Trademark Claims Notice: + Registration request for the Trademark Claims Notice namespace: URI: urn:ietf:params:xml:ns:tmNotice-1.0 Registrant Contact: See the "Author's Address" section of this document. XML: None. Namespace URIs do not represent an XML specification. + Registration request for the Trademark Claims Notice XML schema: + + URI: urn:ietf:params:xml:ns:tmNotice-1.0 + + Registrant Contact: See the "Author's Address" section of this + document. + + XML: See Section 7.1 of this document. + 10. Security Considerations This specification uses HTTP Basic Authentication to provide a simple application-layer authentication service. HTTPS is used in all interfaces in order to protect against most common attacks. In addition, the client identifier is tied to a set of IP addresses that are allowed to connect to the interfaces described in this document, providing an extra security measure. The TMDB MUST provide credentials to the appropriate Registries and @@ -2576,74 +2582,67 @@ The TMDB MUST require the use of strong passwords by Registries and Registrars. The TMDB, Registries and Registrars MUST use the best practices described in RFC 7525 or its successors. 11. References 11.1. Normative References - [I-D.ietf-eppext-tmch-smd] - Lozano, G., "Mark and Signed Mark Objects Mapping", draft- - ietf-eppext-tmch-smd-06 (work in progress), March 2016. + [Claims50] + ICANN, "Implementation Notes: Trademark Claims Protection + for Previously Abused Names", July 2013, + . [MatchingRules] ICANN, "Memorandum on Implementing Matching Rules", September 2012, . + [QLP-Addendum] + ICANN, "Qualified Launch Program Addendum", April 2014, + . + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . -11.2. Informative References + [RFC7848] Lozano, G., "Mark and Signed Mark Objects Mapping", + RFC 7848, DOI 10.17487/RFC7848, June 2016, + . - [Claims50] - ICANN, "Implementation Notes: Trademark Claims Protection - for Previously Abused Names", July 2013, - . + [RPM-Requirements] + ICANN, "Rights Protection Mechanism Requirements", + September 2013, . + +11.2. Informative References [ICANN-GTLD-AGB-20120604] ICANN, "gTLD Applicant Guidebook Version 2012-06-04", June 2012, . [ISO3166-2] ISO, "International Standard for country codes and codes for their subdivisions", 2006, . - [QLP-Addendum] - ICANN, "Qualified Launch Program Addendum", April 2014, - . - - [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., - Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext - Transfer Protocol -- HTTP/1.1", RFC 2616, - DOI 10.17487/RFC2616, June 1999, - . - - [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., - Leach, P., Luotonen, A., and L. Stewart, "HTTP - Authentication: Basic and Digest Access Authentication", - RFC 2617, DOI 10.17487/RFC2617, June 1999, - . - [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- Separated Values (CSV) Files", RFC 4180, @@ -2663,29 +2662,39 @@ Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, DOI 10.17487/RFC7230, June 2014, + . + + [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Semantics and Content", RFC 7231, + DOI 10.17487/RFC7231, June 2014, + . + + [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Authentication", RFC 7235, + DOI 10.17487/RFC7235, June 2014, + . + [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, . - [RPM-Requirements] - ICANN, "Rights Protection Mechanism Requirements", - September 2013, . - [WIPO-NICE-CLASSES] WIPO, "WIPO Nice Classification", 2015, . [WIPO.ST3] WIPO, "Recommended standard on two-letter codes for the representation of states, other entities and intergovernmental organizations", March 2007, .