Internet Engineering Task Force G. Lozano Internet-Draft ICANN Intended status: Standards Track February 18, 2016 Expires: August 21, 2016 Mark and Signed Mark Objects Mapping draft-ietf-eppext-tmch-smd-05 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 August 21, 2016. Lozano Expires August 21, 2016 [Page 1] Internet-Draft Mark and Signed Mark February 2016 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Object Description . . . . . . . . . . . . . . . . . . . . . 4 2.1. Holder and Contacts objects . . . . . . . . . . . . . . . 4 2.2. Mark . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Signed Mark . . . . . . . . . . . . . . . . . . . . . . . 9 2.4. Encoded Signed Mark . . . . . . . . . . . . . . . . . . . 13 3. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. Signed Mark Schema . . . . . . . . . . . . . . . . . . . 13 3.2. Mark Schema . . . . . . . . . . . . . . . . . . . . . . . 15 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 4.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 21 4.2. Verisign Consolidated Top Level Domain (CTLD) SRS . . . . 22 4.3. Verisign .COM / .NET SRS . . . . . . . . . . . . . . . . 22 4.4. REngin v3.7 . . . . . . . . . . . . . . . . . . . . . . . 22 4.5. Uniregistry Corp. Shared Registry System (uSRS) . . . . . 23 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1. Normative References . . . . . . . . . . . . . . . . . . 25 8.2. Informative References . . . . . . . . . . . . . . . . . 26 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 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). Lozano Expires August 21, 2016 [Page 2] Internet-Draft Mark and Signed Mark February 2016 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 specification was defined as part of the development of the ICANN Trademark Clearinghouse (TMCH). The ICANN TMCH is a global repository for trademark data used by DNRs, registrars and trademark holders during the registration process of domain names. This document describes a mapping of the common elements found in trademark data. A digitally signed mark format is defined in order to support digital signatures on the mark. Finally a mapping for encoding the signed mark document is defined. Three types of mark objects are defined in this specification: registered trademarks, court-validated marks, and marks protected by statue or treaty. This specification is intended to be used in the gTLD space, but nothing precludes the use of this format by other entities. The detailed requirements regarding the public key infrastructure, authorized validators, and other architectural details must be defined based on the local policy of the entities using this specification. In the case of gTLDs, the detailed architectural requirements regarding the use of this specification are defined in the Rights Protection Mechanism Requirements document ([ICANN-TMCH]). The objects specified in this document can be referenced by application protocols like the Extensible Provisioning Protocol (EPP), defined in [RFC5730]. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. XML (EXtensible Markup Language) is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation. "signedMark-1.0" is used as an abbreviation for "urn:ietf:params:xml:ns:signedMark-1.0". The XML namespace prefix "smd" is used, but implementations MUST NOT depend on it and instead Lozano Expires August 21, 2016 [Page 3] Internet-Draft Mark and Signed Mark February 2016 employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents. "mark-1.0" is used as an abbreviation for "urn:ietf:params:xml:ns:mark-1.0". The XML namespace prefix "mark" is used, but implementations MUST NOT depend on it and instead employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents. 2. Object Description This section defines the Mark and Signed Mark objects. Empty complex element types and abstract elements are defined to support additional Mark and Signed Mark definitions using XML schema substitution groups. Support for replacement through the XML schema substitution groups is included in the description of the objects. This section defines some elements as OPTIONAL. If an elements is not defined as OPTIONAL, then it MUST be included in the object. The following elements are defined as telephone numbers: , and . The representation of telephone numbers in this specification is derived from structures defined in [ITU.E164.2005]. Telephone numbers described in this mapping are character strings that MUST begin with a plus sign ("+", ASCII value 0x002B), followed by a country code defined in [ITU.E164.2005], followed by a dot (".", ASCII value 0x002E), followed by a sequence of digits representing the telephone number. An optional "x" attribute is provided to note telephone extension information. The following elements are defined as email addresses: and . Email address syntax is defined in [RFC5322]. 2.1. Holder and Contacts objects Marks are linked to Holder objects and optionally linked to Contact objects. This section defines the and objects. o The child elements of include: * A element that contains the name of the individual holder of the mark. At least one of and MUST be specified, and is OPTIONAL if is specified. Lozano Expires August 21, 2016 [Page 4] Internet-Draft Mark and Signed Mark February 2016 * A element that contains the name of the organization holder of the mark. At least one of and MUST be specified, and is OPTIONAL if is specified. * A element that contains the address information of the holder of a mark. A contains the following child elements: + One, two or three OPTIONAL elements that contains the holder's street address. + A element that contains the holder's city. + An OPTIONAL element that contains the holder's state or province. + An OPTIONAL element that contains the holder's postal code. + A element that contains the holder's country code. This a two-character code from [ISO3166-2]. * An OPTIONAL element that contains the holder's voice telephone number. * An OPTIONAL element that contains the holder's facsimile telephone number. * An OPTIONAL element that contains the email address of the holder. o The child elements of include: * A element that contains name of the responsible person. * An OPTIONAL element that contains the name of the organization of the contact. * A element that contains the address information of the contact. A contains the following child elements: + One, two or three OPTIONAL elements that contains the contact's street address. + A element that contains the contact's city. Lozano Expires August 21, 2016 [Page 5] Internet-Draft Mark and Signed Mark February 2016 + An OPTIONAL element that contains the contact's state or province. + An OPTIONAL element that contains the contact's postal code. + A element that contains the contact's country code. This a two-character code from [ISO3166-2]. * A element that contains the contact's voice telephone number. * An OPTIONAL element that contains the contact's facsimile telephone number. * A element that contains the contact's email address. 2.2. Mark A element that describes an applicant's prior right to a given domain name. A element substitutes for the abstract element to define a concrete definition of a mark. The element can be replaced by other mark definitions using the XML schema substitution groups feature. The child elements of the element include: One or more , and elements that contains the detailed information of marks. o A element that contains the following child elements: * A that uniquely identifies a mark in relation to a repository of marks potentially maintained by more than one issuer. A value is a concatenation of the local identifier, followed by a hyphen ("-", ASCII value 0x002D), followed by the issuer identifier. * A element that contains the mark text string. * One or more elements that contains the information of the holder of the mark. An "entitlement" attribute is used to identify the entitlement of the holder, possible values are: owner, assignee and licensee. Lozano Expires August 21, 2016 [Page 6] Internet-Draft Mark and Signed Mark February 2016 * Zero or more OPTIONAL elements that contains the information of the representative of the mark registration. A "type" attribute is used to identify the type of contact, possible values are: owner, agent or thirdparty. * A element that contains the two-character code of the jurisdiction where the trademark was registered. This is a two-character code from [WIPO.ST3]. * Zero or more OPTIONAL elements that contain the WIPO Nice Classification class numbers of the mark as defined in the WIPO Nice Classification [WIPO-NICE-CLASSES]. * Zero or more OPTIONAL elements that contain the A-label form (as defined in [RFC5890]) of the label that correspond to the . * A element that contains the full description of the goods and services mentioned in the mark registration document. * An OPTIONAL element that contains the trademark application ID registered in the trademark office. * An OPTIONAL element that contains the date the trademark was applied for. * A element that contains the trademark registration number registered in the trademark office. * A element that contains the date the trademark was registered. * An OPTIONAL element that contains the expiration date of the trademark. o A element that contains the following child elements: * A , see definition in the section above. * A , see definition in the section above. * One or more , see definition in the section above. Lozano Expires August 21, 2016 [Page 7] Internet-Draft Mark and Signed Mark February 2016 * Zero or more OPTIONAL , see definition in the section above. * One or more elements that contain the countries and region of the country where the mark is protected. The element contains the following child elements: + A element that contains the two-character code of the country in which the mark is protected. This is a two- character code from [ISO3166-2]. + An OPTIONAL element that contains the name of a city, state, province or other geographic region of in which the mark is protected. + Zero or more OPTIONAL elements that contains the two-character code of the national territory in which the statute or treaty is applicable. This is a two- character code from [ISO3166-2]. + Zero or more OPTIONAL , see definition in the section above. * A , see definition in the section above. * A element that contains the serial number of the mark. * A element that contains the date of protection of the mark. * A element that contains the title of the treaty or statute. * A element that contains the execution date of the treaty or statute. o A element that contains the following child elements: * A , see definition in the section above. * A , see definition in the section above. Lozano Expires August 21, 2016 [Page 8] Internet-Draft Mark and Signed Mark February 2016 * One or more , see definition in the section above. * Zero or more OPTIONAL , see definition in the section above. * Zero or more OPTIONAL , see definition in the section above. * A , see definition in the section above. * A element that contains the reference number of the court's opinion. * A element that contains the date of protection of the mark. * A element that contains the two-character code of the country where the court is located. This a two-character code from [ISO3166-2]. * Zero or more OPTIONAL elements that contains the name of a city, state, province or other geographic region of in which the mark is protected. In case is specified a default-deny approach MUST be assumed regarding the regions of a country. * A element that contains the name of the court. 2.3. Signed Mark The is a digitally signed XML document using XML Signature [XMLDSIG]. The XML document (SMD) includes a required "id" attribute of type XSD ID for use with an IDREF URI from the Signature element. The SMD might be transmitted as part of an already XML based protocol, therefore exclusive XML canonicalization as defined in [XMLC14N] MUST be used. A element substitutes for the abstract element to define a concrete definition of a signed mark. The element can be replaced by other signed mark definitions using the XML schema substitution groups feature. The child elements of the element include: Lozano Expires August 21, 2016 [Page 9] Internet-Draft Mark and Signed Mark February 2016 o The that uniquely identifies an SMD in relation to a repository of SMDs potentially maintained by more than one issuer. The value is a concatenation of the local identifier, followed by a hyphen ("-", ASCII value 0x002D), followed by the issuer identifier. o A element that contains the information of the issuer of the mark registration. A "issuerID" attribute is used to specify the issuer identifier. The child elements include: * A element that contains the organization name of the issuer. * A element that contains the issuer customer support email address. * An OPTIONAL element that contains the HTTP or HTTPS URL of the issuer's site. * An OPTIONAL element that contains the issuer's voice telephone number. o A element that contains the creation date and time of the SMD. o A element that contains the expiration date and time of the SMD. o A element that contains the mark information as defined in the Mark (Section 2.2) section. The following is an example of an SMD: 0000001751376056503931-65535 ICANN TMCH TESTING TMV notavailable@example.com https://www.example.com +32.000000 2013-08-09T13:55:03.931Z 2017-07-23T22:00:00.000Z 00052013734689731373468973-65535 Lozano Expires August 21, 2016 [Page 10] Internet-Draft Mark and Signed Mark February 2016 Test & Validate Ag corporation 1305 Bright Avenue Arcadia CA 90028 US Tony Holland Ag corporation 1305 Bright Avenue Arcadia CA 90028 US +1.2025562302 +1.2025562301 info@agcorporation.com US 15 testandvalidate test---validate testand-validate test-et-validate test-validate test--validate test-etvalidate testetvalidate testvalidate testet-validate guitar 1234 2012-12-31T23:00:00.000Z Lozano Expires August 21, 2016 [Page 11] Internet-Draft Mark and Signed Mark February 2016 wgyW3nZPoEfpptlhRILKnOQnbdtU6ArM7ShrAfHgDFg= jMu4PfyQGiJBF0GWSEPFCJjmywCEqR2h4LD+ge6XQ+JnmKFFCuCZS/3SLKAx0L1w QDFO2e0Y69k2G7/LGE37X3vOflobFM1oGwja8+GMVraoto5xAd4/AF7eHukgAymD o9toxoa2h0yV4A4PmXzsU6S86XtCcUE+S/WM72nyn47zoUCzzPKHZBRyeWehVFQ+ jYRMIAMzM57HHQA+6eaXefRvtPETgUO4aVIVSugc4OUAZZwbYcZrC6wOaQqqqAZi 30aPOBYbAvHMSmWSS+hFkbshomJfHxb97TD2grlYNrQIzqXk7WbHWy2SYdA+sI/Z ipJsXNa6osTUw1CzA7jfwA== MIIESTCCAzGgAwIBAgIBAjANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEL MAkGA1UECBMCQ0ExFDASBgNVBAcTC0xvcyBBbmdlbGVzMRMwEQYDVQQKEwpJQ0FO TiBUTUNIMRswGQYDVQQDExJJQ0FOTiBUTUNIIFRFU1QgQ0EwHhcNMTMwMjA4MDAw MDAwWhcNMTgwMjA3MjM1OTU5WjBsMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0Ex FDASBgNVBAcTC0xvcyBBbmdlbGVzMRcwFQYDVQQKEw5WYWxpZGF0b3IgVE1DSDEh MB8GA1UEAxMYVmFsaWRhdG9yIFRNQ0ggVEVTVCBDRVJUMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAo/cwvXhbVYl0RDWWvoyeZpETVZVVcMCovUVNg/sw WinuMgEWgVQFrz0xA04pEhXCFVv4evbUpekJ5buqU1gmQyOsCKQlhOHTdPjvkC5u pDqa51Flk0TMaMkIQjs7aUKCmA4RG4tTTGK/EjR1ix8/D0gHYVRldy1YPrMP+ou7 5bOVnIos+HifrAtrIv4qEqwLL4FTZAUpaCa2BmgXfy2CSRQbxD5Or1gcSa3vurh5 sPMCNxqaXmIXmQipS+DuEBqMM8tldaN7RYojUEKrGVsNk5i9y2/7sjn1zyyUPf7v L4GgDYqhJYWV61DnXgx/Jd6CWxvsnDF6scscQzUTEl+hywIDAQABo4H/MIH8MAwG A1UdEwEB/wQCMAAwHQYDVR0OBBYEFPZEcIQcD/Bj2IFz/LERuo2ADJviMIGMBgNV HSMEgYQwgYGAFO0/7kEh3FuEKS+Q/kYHaD/W6wihoWakZDBiMQswCQYDVQQGEwJV UzELMAkGA1UECBMCQ0ExFDASBgNVBAcTC0xvcyBBbmdlbGVzMRMwEQYDVQQKEwpJ Q0FOTiBUTUNIMRswGQYDVQQDExJJQ0FOTiBUTUNIIFRFU1QgQ0GCAQEwDgYDVR0P AQH/BAQDAgeAMC4GA1UdHwQnMCUwI6AhoB+GHWh0dHA6Ly9jcmwuaWNhbm4ub3Jn L3RtY2guY3JsMA0GCSqGSIb3DQEBCwUAA4IBAQB2qSy7ui+43cebKUKwWPrzz9y/ IkrMeJGKjo40n+9uekaw3DJ5EqiOf/qZ4pjBD++oR6BJCb6NQuQKwnoAz5lE4Ssu y5+i93oT3HfyVc4gNMIoHm1PS19l7DBKrbwbzAea/0jKWVzrvmV7TBfjxD3AQo1R bU5dBr6IjbdLFlnO5x0G0mrG7x5OUPuurihyiURpFDpwH8KAH1wMcCpXGXFRtGKk wydgyVYAty7otkl/z3bZkCVT34gPvF70sR6+QxUy8u0LzF5A/beYaZpxSYG31amL AdXitTWFipaIGea9lEGFM0L9+Bg7XzNn4nVLXokyEB3bgS4scG6QznX23FGk Lozano Expires August 21, 2016 [Page 12] Internet-Draft Mark and Signed Mark February 2016 NOTE: The example shown above includes white-spaces for indentation purposes. It is RECOMMENDED that SMDs do not include white-spaces between the XML elements, in order to mitigate risks of invalidating the digital signature when transferring of SMDs between applications takes place. 2.4. Encoded Signed Mark The element contains an encoded form of an SMD (described in Section 2.3), with the encoding defined by the "encoding" attribute with the default "encoding" value of "base64" [RFC4648]. The following is an example of a element that uses the default "base64" for encoding a element. PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWduZWRNYXJ rIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRNYXJrLTEuMCIgaW ... (base64 data elided for brevity) ... PC9zbWQ6c2lnbmVkTWFyaz4= 3. Formal Syntax Two schemas are presented here. The first schema is the schema for the signed mark. The second schema is the schema for the mark. The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The BEGIN and END tags are not part of the schema; they are used to note the beginning and ending of the schema for URI registration purposes. 3.1. Signed Mark Schema Copyright (c) 2016 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). Lozano Expires August 21, 2016 [Page 13] Internet-Draft Mark and Signed Mark February 2016 BEGIN Schema for representing a Signed Trademark. Lozano Expires August 21, 2016 [Page 14] Internet-Draft Mark and Signed Mark February 2016 END 3.2. Mark Schema Copyright (c) 2016 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). BEGIN Schema for representing a Trademark, also referred to Lozano Expires August 21, 2016 [Page 15] Internet-Draft Mark and Signed Mark February 2016 as Mark. Lozano Expires August 21, 2016 [Page 16] Internet-Draft Mark and Signed Mark February 2016 Lozano Expires August 21, 2016 [Page 17] Internet-Draft Mark and Signed Mark February 2016 Lozano Expires August 21, 2016 [Page 18] Internet-Draft Mark and Signed Mark February 2016 END Lozano Expires August 21, 2016 [Page 20] Internet-Draft Mark and Signed Mark February 2016 4. Implementation Status Note to RFC Editor: Please remove this section and the reference to RFC 6982 [RFC6982] before publication. This section records the status of known implementations of the format defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 6982 [RFC6982]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to RFC 6982 [RFC6982], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". 4.1. Verisign EPP SDK Organization: Verisign Inc. Name: Verisign EPP SDK Description: The Verisign EPP SDK includes both a full client implementation and a full server stub implementation of draft-ietf- eppext-tmch-smd. Level of maturity: Production Coverage: All aspects of the draft-ietf-eppext-tmch-smd are implemented. Licensing: GNU Lesser General Public License Contact: jgould@verisign.com URL: http://www.verisigninc.com/en_US/channel-resources/domain- registry-products/epp-sdks Lozano Expires August 21, 2016 [Page 21] Internet-Draft Mark and Signed Mark February 2016 4.2. Verisign Consolidated Top Level Domain (CTLD) SRS Organization: Verisign Inc. Name: Verisign Consolidated Top Level Domain (CTLD) Shared Registry System (SRS) Description: The Verisign Consolidated Top Level Domain (CTLD) Shared Registry System (SRS) implements the server-side of draft-ietf- eppext-tmch-smd for a variety of Top Level Domains (TLD's). Level of maturity: Production Coverage: Implements parsing and validation of all aspects of draft- ietf-eppext-tmch-smd including the Signed Mark, the Encoded Signed Mark, and the contained Mark. Implements the encoding of the Mark in supporting the response of draft-ietf-eppext-launchphase. Licensing: Proprietary Contact: jgould@verisign.com 4.3. Verisign .COM / .NET SRS Organization: Verisign Inc. Name: Verisign .COM / .NET Shared Registry System (SRS) Description: The Verisign Shared Registry System (SRS) for .COM, .NET and other IDN TLD's implements the server-side of draft-ietf-eppext- tmch-smd. Level of maturity: Operational Test Environment (OTE) Coverage: Implements parsing and validation of all aspects of draft- ietf-eppext-tmch-smd including the Signed Mark, the Encoded Signed Mark, and the contained Mark. Licensing: Proprietary Contact: jgould@verisign.com 4.4. REngin v3.7 Organisation: Domain Name Services (Pty) Ltd Name: REngin v3.7 Lozano Expires August 21, 2016 [Page 22] Internet-Draft Mark and Signed Mark February 2016 Description: Server side implementation only Level of maturity: Production Coverage: All aspects of draft-ietf-eppext-tmch-smd have been implemented Licensing: Proprietary Licensing with Maintenance Contracts Contact: info@dnservices.co.za URL: http://domain-name.services 4.5. Uniregistry Corp. Shared Registry System (uSRS) Organization: Uniregistry Corp. Name: Uniregistry Corp. Shared Registry System (uSRS) Description: Uniregistry's Shared Registry System implements the server-side of draft-ietf-eppext-tmch-smd for its TLD registry. Level of maturity: Production Coverage: Implements parsing and validation of all aspects of draft- ietf-eppext-tmch-smd including the Signed Mark, the Encoded Signed Mark, and the contained Mark. Implements the encoding of the Mark in supporting the response of draft-ietf-eppext-launchphase. Licensing: Proprietary Contact: fobispo@uniregistry.link 5. Acknowledgements Special thanks to Chris Wright for creating the first prototype of a SMD; James Gould, Wil Tan and Gavin Brown for creating the mark and SMD definitions in their EPP draft launch extension on which this draft is based. Portions of the security section were shamefully copied from RFC5105. The author would like to acknowledge the following individuals for their contributions to this document: Scott Hollenbeck and Jan Jansen. 6. IANA Considerations This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. Two URI assignments have been registered by the IANA. Lozano Expires August 21, 2016 [Page 23] Internet-Draft Mark and Signed Mark February 2016 Registration request for the signed mark namespace: URI: urn:ietf:params:xml:ns:signedMark-1.0 Registrant Contact: IESG XML: None. Namespace URIs do not represent an XML specification. Registration request for the signed mark schema: URI: urn:ietf:params:xml:schema:signedMark-1.0 Registrant Contact: IESG XML: See the "Formal Syntax" section of this document. Registration request for the mark namespace: URI: urn:ietf:params:xml:ns:mark-1.0 Registrant Contact: IESG XML: None. Namespace URIs do not represent an XML specification. Registration request for the mark schema: URI: urn:ietf:params:xml:schema:mark-1.0 Registrant Contact: IESG XML: See the "Formal Syntax" section of this document. 7. Security Considerations The security of a Signed Mark object depends on the security of the underlying XML DSIG algorithms. As such, all the security considerations from [XMLDSIG] apply here as well. The digital signature algorithm used in Signed Mark objects SHOULD be RSA-SHA256 [RFC4051]. The size of the RSA key SHOULD be at least 2048 bits. A valid reason for choosing something else would be if RSA-SHA256 would be deemed to not provide sufficient security. In the case of the ICANN Trademark Clearinghouse (TMCH), Signed Mark objects use the algorithms for digesting and signing recommended in this document. Lozano Expires August 21, 2016 [Page 24] Internet-Draft Mark and Signed Mark February 2016 Signed Marks are used primarily for sunrise domain name registrations in gTLDs, but other third-parties might be using them. A party using Signed Marks should verify that the digital signature is valid based on local policy. In the case of gTLDs, the RPM Requirements document [ICANN-TMCH] defines such policy. 8. References 8.1. Normative References [ICANN-TMCH] ICANN, "ICANN Trademark Clearinghouse, Rights Protection Mechanism Requirements", 2013, . [ISO3166-2] ISO, "International Standard for country codes and codes for their subdivisions", 2006, . [ITU.E164.2005] International Telecommunication Union, "The international public telecommunication numbering plan", 2010, . [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, . [RFC4051] Eastlake 3rd, D., "Additional XML Security Uniform Resource Identifiers (URIs)", RFC 4051, DOI 10.17487/RFC4051, April 2005, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . Lozano Expires August 21, 2016 [Page 25] Internet-Draft Mark and Signed Mark February 2016 [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [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, . [XMLC14N] W3C Recommendation, "Exclusive XML Canonicalization Version 1.0", 2002, . [XMLDSIG] W3C Recommendation, "XML Signature Syntax and Processing (Second Edition)", 2013, . 8.2. Informative References [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 6982, DOI 10.17487/RFC6982, July 2013, . Author's Address Gustavo Lozano ICANN 12025 Waterfront Drive, Suite 300 Los Angeles 90292 US Phone: +1.3103015800 Email: gustavo.lozano@icann.org Lozano Expires August 21, 2016 [Page 26]