idnits 2.17.1 draft-ietf-eppext-tmch-smd-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2016) is 2970 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ICANN-TMCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.E164.2005' ** Obsolete normative reference: RFC 4051 (Obsoleted by RFC 6931) -- Possible downref: Non-RFC (?) normative reference: ref. 'WIPO-NICE-CLASSES' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLC14N' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLDSIG' == Outdated reference: A later version (-01) exists of draft-ietf-eppext-tmch-func-spec-00 -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Lozano 3 Internet-Draft ICANN 4 Intended status: Standards Track March 9, 2016 5 Expires: September 10, 2016 7 Mark and Signed Mark Objects Mapping 8 draft-ietf-eppext-tmch-smd-06 10 Abstract 12 Domain Name Registries (DNRs) may operate in special modes for 13 certain periods of time enabling trademark holders to protect their 14 rights during the introduction of a Top Level Domain (TLD). 16 One of those special modes of operation is the Sunrise Period. The 17 Sunrise Period allows trademark holders an advance opportunity to 18 register domain names corresponding to their trademarks before names 19 are generally available to the public. 21 This document describes the format of a mark and a digitally signed 22 mark used by trademark holders for registering domain names during 23 the sunrise phase of generic Top Level Domains (gTLDs). Three types 24 of mark objects are defined in this specification: registered 25 trademarks, court-validated marks, and marks protected by statue or 26 treaty. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 10, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Object Description . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. Holder and Contacts objects . . . . . . . . . . . . . . . 4 66 2.2. Mark . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 2.3. Signed Mark . . . . . . . . . . . . . . . . . . . . . . . 9 68 2.4. Encoded Signed Mark . . . . . . . . . . . . . . . . . . . 13 69 3. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13 70 3.1. Signed Mark Schema . . . . . . . . . . . . . . . . . . . 13 71 3.2. Mark Schema . . . . . . . . . . . . . . . . . . . . . . . 15 72 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 73 4.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 21 74 4.2. Verisign Consolidated Top Level Domain (CTLD) SRS . . . . 22 75 4.3. Verisign .COM / .NET SRS . . . . . . . . . . . . . . . . 22 76 4.4. REngin v3.7 . . . . . . . . . . . . . . . . . . . . . . . 22 77 4.5. Uniregistry Corp. Shared Registry System (uSRS) . . . . . 23 78 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 25 83 8.2. Informative References . . . . . . . . . . . . . . . . . 26 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 86 1. Introduction 88 Domain Name Registries (DNRs) may operate in special modes for 89 certain periods of time enabling trademark holders to protect their 90 rights during the introduction of a Top Level Domain (TLD). 92 One of those special modes of operation is the Sunrise Period. The 93 Sunrise Period allows trademark holders an advance opportunity to 94 register domain names corresponding to their trademarks before names 95 are generally available to the public. 97 This specification was defined as part of the development of the 98 ICANN Trademark Clearinghouse (TMCH). The ICANN TMCH is a global 99 repository for trademark data used by DNRs, registrars and trademark 100 holders during the registration process of domain names. 102 This document describes a mapping of the common elements found in 103 trademark data. A digitally signed mark format is defined in order 104 to support digital signatures on the mark. Finally a mapping for 105 encoding the signed mark document is defined. 107 Three types of mark objects are defined in this specification: 108 registered trademarks, court-validated marks, and marks protected by 109 statue or treaty. 111 This specification is intended to be used in the gTLD space, but 112 nothing precludes the use of this format by other entities. 114 The detailed policy regarding the public key infrastructure (PKI), 115 authorized validators, and other requirements must be defined based 116 on the local policy of the entities using this specification. In the 117 case of gTLDs, the detailed policy regarding the use of this 118 specification is defined in the Rights Protection Mechanism 119 Requirements document (see [ICANN-TMCH]), and the PKI is defined in 120 [I-D.ietf-eppext-tmch-func-spec]. Implementations will need to 121 implement such a PKI (or an equivalent) in order for the signatures 122 defined in this document to have any useful semantics. 124 The objects specified in this document can be referenced by 125 application protocols like the Extensible Provisioning Protocol 126 (EPP), defined in [RFC5730]. 128 1.1. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [RFC2119]. 134 XML (EXtensible Markup Language) is case sensitive. Unless stated 135 otherwise, XML specifications and examples provided in this document 136 MUST be interpreted in the character case presented in order to 137 develop a conforming implementation. 139 "signedMark-1.0" is used as an abbreviation for 140 "urn:ietf:params:xml:ns:signedMark-1.0". The XML namespace prefix 141 "smd" is used, but implementations MUST NOT depend on it and instead 142 employ a proper namespace-aware XML parser and serializer to 143 interpret and output the XML documents. 145 "mark-1.0" is used as an abbreviation for 146 "urn:ietf:params:xml:ns:mark-1.0". The XML namespace prefix "mark" 147 is used, but implementations MUST NOT depend on it and instead employ 148 a proper namespace-aware XML parser and serializer to interpret and 149 output the XML documents. 151 2. Object Description 153 This section defines the Mark and Signed Mark objects. Empty complex 154 element types and abstract elements are defined to support additional 155 Mark and Signed Mark definitions using XML schema substitution 156 groups. Support for replacement through the XML schema substitution 157 groups is included in the description of the objects. 159 This section defines some elements as OPTIONAL. If an elements is 160 not defined as OPTIONAL, then it MUST be included in the object. 162 The following elements are defined as telephone numbers: 163 , and . The representation of 164 telephone numbers in this specification is derived from structures 165 defined in [ITU.E164.2005]. Telephone numbers described in this 166 mapping are character strings that MUST begin with a plus sign ("+", 167 ASCII value 0x002B), followed by a country code defined in 168 [ITU.E164.2005], followed by a dot (".", ASCII value 0x002E), 169 followed by a sequence of digits representing the telephone number. 170 An optional "x" attribute is provided to note telephone extension 171 information. 173 The following elements are defined as email addresses: 174 and . Email address syntax is defined in [RFC5322]. 176 2.1. Holder and Contacts objects 178 Marks are linked to Holder objects and optionally linked to Contact 179 objects. This section defines the and 180 objects. 182 o The child elements of include: 184 * A element that contains the name of the individual 185 holder of the mark. At least one of and 186 MUST be specified, and is OPTIONAL if is 187 specified. 189 * A element that contains the name of the organization 190 holder of the mark. At least one of and 191 MUST be specified, and is OPTIONAL if is 192 specified. 194 * A element that contains the address information of 195 the holder of a mark. A contains the following 196 child elements: 198 + One, two or three OPTIONAL elements that 199 contains the holder's street address. 201 + A element that contains the holder's city. 203 + An OPTIONAL element that contains the holder's 204 state or province. 206 + An OPTIONAL element that contains the holder's 207 postal code. 209 + A element that contains the holder's country code. 210 This a two-character code from [ISO3166-2]. 212 * An OPTIONAL element that contains the holder's 213 voice telephone number. 215 * An OPTIONAL element that contains the holder's 216 facsimile telephone number. 218 * An OPTIONAL element that contains the email 219 address of the holder. 221 o The child elements of include: 223 * A element that contains name of the responsible 224 person. 226 * An OPTIONAL element that contains the name of the 227 organization of the contact. 229 * A element that contains the address information of 230 the contact. A contains the following child 231 elements: 233 + One, two or three OPTIONAL elements that 234 contains the contact's street address. 236 + A element that contains the contact's city. 238 + An OPTIONAL element that contains the contact's 239 state or province. 241 + An OPTIONAL element that contains the contact's 242 postal code. 244 + A element that contains the contact's country 245 code. This a two-character code from [ISO3166-2]. 247 * A element that contains the contact's voice 248 telephone number. 250 * An OPTIONAL element that contains the contact's 251 facsimile telephone number. 253 * A element that contains the contact's email 254 address. 256 2.2. Mark 258 A element that describes an applicant's prior right to a 259 given domain name. 261 A element substitutes for the 262 abstract element to define a concrete definition of a mark. The 263 element can be replaced by other mark definitions 264 using the XML schema substitution groups feature. 266 The child elements of the element include: 268 One or more , and 269 elements that contains the detailed information of marks. 271 o A element that contains the following child 272 elements: 274 * A that uniquely identifies a mark in relation to a 275 repository of marks potentially maintained by more than one 276 issuer. A value is a concatenation of the local 277 identifier, followed by a hyphen ("-", ASCII value 0x002D), 278 followed by the issuer identifier. 280 * A element that contains the mark text string. 282 * One or more elements that contains the 283 information of the holder of the mark. An "entitlement" 284 attribute is used to identify the entitlement of the holder, 285 possible values are: owner, assignee and licensee. 287 * Zero or more OPTIONAL elements that contains the 288 information of the representative of the mark registration. A 289 "type" attribute is used to identify the type of contact, 290 possible values are: owner, agent or thirdparty. 292 * A element that contains the two-character 293 code of the jurisdiction where the trademark was registered. 294 This is a two-character code from [WIPO.ST3]. 296 * Zero or more OPTIONAL elements that contain the 297 WIPO Nice Classification class numbers of the mark as defined 298 in the WIPO Nice Classification [WIPO-NICE-CLASSES]. 300 * Zero or more OPTIONAL elements that contain the 301 A-label form (as defined in [RFC5890]) of the label that 302 correspond to the . 304 * A element that contains the full 305 description of the goods and services mentioned in the mark 306 registration document. 308 * An OPTIONAL element that contains the trademark 309 application ID registered in the trademark office. 311 * An OPTIONAL element that contains the date the 312 trademark was applied for. 314 * A element that contains the trademark 315 registration number registered in the trademark office. 317 * A element that contains the date the trademark 318 was registered. 320 * An OPTIONAL element that contains the expiration 321 date of the trademark. 323 o A element that contains the following child 324 elements: 326 * A , see definition in the section 327 above. 329 * A , see definition in the 330 section above. 332 * One or more , see definition in the 333 section above. 335 * Zero or more OPTIONAL , see definition in the 336 section above. 338 * One or more elements that contain the 339 countries and region of the country where the mark is 340 protected. The element contains the 341 following child elements: 343 + A element that contains the two-character code of 344 the country in which the mark is protected. This is a two- 345 character code from [ISO3166-2]. 347 + An OPTIONAL element that contains the name of 348 a city, state, province or other geographic region of 349 in which the mark is protected. 351 + Zero or more OPTIONAL elements that contains 352 the two-character code of the national territory in which 353 the statute or treaty is applicable. This is a two- 354 character code from [ISO3166-2]. 356 + Zero or more OPTIONAL , see definition in the 357 section above. 359 * A , see definition in the 360 section above. 362 * A element that contains the serial number of the 363 mark. 365 * A element that contains the date of protection 366 of the mark. 368 * A element that contains the title of the treaty or 369 statute. 371 * A element that contains the execution date of 372 the treaty or statute. 374 o A element that contains the following child elements: 376 * A , see definition in the section 377 above. 379 * A , see definition in the 380 section above. 382 * One or more , see definition in the 383 section above. 385 * Zero or more OPTIONAL , see definition in the 386 section above. 388 * Zero or more OPTIONAL , see definition in the 389 section above. 391 * A , see definition in the 392 section above. 394 * A element that contains the reference number of 395 the court's opinion. 397 * A element that contains the date of protection 398 of the mark. 400 * A element that contains the two-character code of the 401 country where the court is located. This a two-character code 402 from [ISO3166-2]. 404 * Zero or more OPTIONAL elements that contains the 405 name of a city, state, province or other geographic region of 406 in which the mark is protected. In case 407 is specified a default-deny approach MUST be 408 assumed regarding the regions of a country. 410 * A element that contains the name of the court. 412 2.3. Signed Mark 414 The is a digitally signed XML document using XML 415 Signature [XMLDSIG]. The XML document (SMD) 416 includes a required "id" attribute of type XSD ID for use with an 417 IDREF URI from the Signature element. The SMD might be transmitted 418 as part of an already XML based protocol, therefore exclusive XML 419 canonicalization as defined in [XMLC14N] MUST be used. 421 A element substitutes for the 422 abstract element to define a concrete 423 definition of a signed mark. The element 424 can be replaced by other signed mark definitions using the XML schema 425 substitution groups feature. 427 The child elements of the element include: 429 o The that uniquely identifies an SMD in relation to a 430 repository of SMDs potentially maintained by more than one issuer. 431 The value is a concatenation of the local identifier, 432 followed by a hyphen ("-", ASCII value 0x002D), followed by the 433 issuer identifier. 435 o A element that contains the information of the 436 issuer of the mark registration. A "issuerID" attribute is used 437 to specify the issuer identifier. The child elements include: 439 * A element that contains the organization name of the 440 issuer. 442 * A element that contains the issuer customer support 443 email address. 445 * An OPTIONAL element that contains the HTTP or HTTPS 446 URL of the issuer's site. 448 * An OPTIONAL element that contains the issuer's 449 voice telephone number. 451 o A element that contains the creation date and time 452 of the SMD. 454 o A element that contains the expiration date and 455 time of the SMD. 457 o A element that contains the mark information as 458 defined in the Mark (Section 2.2) section. 460 The following is an example of an SMD: 462 463 465 0000001751376056503931-65535 466 467 ICANN TMCH TESTING TMV 468 notavailable@example.com 469 https://www.example.com 470 +32.000000 471 472 2013-08-09T13:55:03.931Z 473 2017-07-23T22:00:00.000Z 474 475 476 00052013734689731373468973-65535 477 Test & Validate 478 479 Ag corporation 480 481 1305 Bright Avenue 482 Arcadia 483 CA 484 90028 485 US 486 487 488 489 Tony Holland 490 Ag corporation 491 492 1305 Bright Avenue 493 Arcadia 494 CA 495 90028 496 US 497 498 +1.2025562302 499 +1.2025562301 500 info@agcorporation.com 501 502 US 503 15 504 testandvalidate 505 test---validate 506 testand-validate 507 test-et-validate 508 test-validate 509 test--validate 510 test-etvalidate 511 testetvalidate 512 testvalidate 513 testet-validate 514 guitar 515 1234 516 2012-12-31T23:00:00.000Z 517 518 519 520 521 523 525 526 527 529 530 532 wgyW3nZPoEfpptlhRILKnOQnbdtU6ArM7ShrAfHgDFg= 533 534 535 536 jMu4PfyQGiJBF0GWSEPFCJjmywCEqR2h4LD+ge6XQ+JnmKFFCuCZS/3SLKAx0L1w 537 QDFO2e0Y69k2G7/LGE37X3vOflobFM1oGwja8+GMVraoto5xAd4/AF7eHukgAymD 538 o9toxoa2h0yV4A4PmXzsU6S86XtCcUE+S/WM72nyn47zoUCzzPKHZBRyeWehVFQ+ 539 jYRMIAMzM57HHQA+6eaXefRvtPETgUO4aVIVSugc4OUAZZwbYcZrC6wOaQqqqAZi 540 30aPOBYbAvHMSmWSS+hFkbshomJfHxb97TD2grlYNrQIzqXk7WbHWy2SYdA+sI/Z 541 ipJsXNa6osTUw1CzA7jfwA== 542 543 544 545 546 MIIESTCCAzGgAwIBAgIBAjANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEL 547 MAkGA1UECBMCQ0ExFDASBgNVBAcTC0xvcyBBbmdlbGVzMRMwEQYDVQQKEwpJQ0FO 548 TiBUTUNIMRswGQYDVQQDExJJQ0FOTiBUTUNIIFRFU1QgQ0EwHhcNMTMwMjA4MDAw 549 MDAwWhcNMTgwMjA3MjM1OTU5WjBsMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0Ex 550 FDASBgNVBAcTC0xvcyBBbmdlbGVzMRcwFQYDVQQKEw5WYWxpZGF0b3IgVE1DSDEh 551 MB8GA1UEAxMYVmFsaWRhdG9yIFRNQ0ggVEVTVCBDRVJUMIIBIjANBgkqhkiG9w0B 552 AQEFAAOCAQ8AMIIBCgKCAQEAo/cwvXhbVYl0RDWWvoyeZpETVZVVcMCovUVNg/sw 553 WinuMgEWgVQFrz0xA04pEhXCFVv4evbUpekJ5buqU1gmQyOsCKQlhOHTdPjvkC5u 554 pDqa51Flk0TMaMkIQjs7aUKCmA4RG4tTTGK/EjR1ix8/D0gHYVRldy1YPrMP+ou7 555 5bOVnIos+HifrAtrIv4qEqwLL4FTZAUpaCa2BmgXfy2CSRQbxD5Or1gcSa3vurh5 556 sPMCNxqaXmIXmQipS+DuEBqMM8tldaN7RYojUEKrGVsNk5i9y2/7sjn1zyyUPf7v 557 L4GgDYqhJYWV61DnXgx/Jd6CWxvsnDF6scscQzUTEl+hywIDAQABo4H/MIH8MAwG 558 A1UdEwEB/wQCMAAwHQYDVR0OBBYEFPZEcIQcD/Bj2IFz/LERuo2ADJviMIGMBgNV 559 HSMEgYQwgYGAFO0/7kEh3FuEKS+Q/kYHaD/W6wihoWakZDBiMQswCQYDVQQGEwJV 560 UzELMAkGA1UECBMCQ0ExFDASBgNVBAcTC0xvcyBBbmdlbGVzMRMwEQYDVQQKEwpJ 561 Q0FOTiBUTUNIMRswGQYDVQQDExJJQ0FOTiBUTUNIIFRFU1QgQ0GCAQEwDgYDVR0P 562 AQH/BAQDAgeAMC4GA1UdHwQnMCUwI6AhoB+GHWh0dHA6Ly9jcmwuaWNhbm4ub3Jn 563 L3RtY2guY3JsMA0GCSqGSIb3DQEBCwUAA4IBAQB2qSy7ui+43cebKUKwWPrzz9y/ 564 IkrMeJGKjo40n+9uekaw3DJ5EqiOf/qZ4pjBD++oR6BJCb6NQuQKwnoAz5lE4Ssu 565 y5+i93oT3HfyVc4gNMIoHm1PS19l7DBKrbwbzAea/0jKWVzrvmV7TBfjxD3AQo1R 566 bU5dBr6IjbdLFlnO5x0G0mrG7x5OUPuurihyiURpFDpwH8KAH1wMcCpXGXFRtGKk 567 wydgyVYAty7otkl/z3bZkCVT34gPvF70sR6+QxUy8u0LzF5A/beYaZpxSYG31amL 568 AdXitTWFipaIGea9lEGFM0L9+Bg7XzNn4nVLXokyEB3bgS4scG6QznX23FGk 569 570 571 572 573 575 NOTE: The example shown above includes white-spaces for indentation 576 purposes. It is RECOMMENDED that SMDs do not include white-spaces 577 between the XML elements, in order to mitigate risks of invalidating 578 the digital signature when transferring of SMDs between applications 579 takes place. 581 2.4. Encoded Signed Mark 583 The element contains an encoded form of an 584 SMD (described in Section 2.3), with the encoding defined by the 585 "encoding" attribute with the default "encoding" value of "base64" 586 [RFC4648]. 588 The following is an example of a element that 589 uses the default "base64" for encoding a element. 591 593 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWduZWRNYXJ 594 rIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRNYXJrLTEuMCIgaW 595 ... (base64 data elided for brevity) ... 596 PC9zbWQ6c2lnbmVkTWFyaz4= 597 599 3. Formal Syntax 601 Two schemas are presented here. The first schema is the schema for 602 the signed mark. The second schema is the schema for the mark. 604 The formal syntax presented here is a complete schema representation 605 of the object mapping suitable for automated validation of EPP XML 606 instances. The BEGIN and END tags are not part of the schema; they 607 are used to note the beginning and ending of the schema for URI 608 registration purposes. 610 3.1. Signed Mark Schema 612 Copyright (c) 2016 IETF Trust and the persons identified as authors 613 of the code. All rights reserved. 615 Redistribution and use in source and binary forms, with or without 616 modification, is permitted pursuant to, and subject to the license 617 terms contained in, the Simplified BSD License set forth in 618 Section 4.c of the IETF Trust's Legal Provisions Relating to IETF 619 Documents (http://trustee.ietf.org/license-info). 621 BEGIN 622 623 631 632 633 Schema for representing a Signed Trademark. 634 635 637 638 640 643 646 649 651 654 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 672 673 674 675 676 677 678 679 680 682 683 684 685 686 687 688 689 690 END 692 3.2. Mark Schema 694 Copyright (c) 2016 IETF Trust and the persons identified as authors 695 of the code. All rights reserved. 697 Redistribution and use in source and binary forms, with or without 698 modification, is permitted pursuant to, and subject to the license 699 terms contained in, the Simplified BSD License set forth in 700 Section 4.c of the IETF Trust's Legal Provisions Relating to IETF 701 Documents (http://trustee.ietf.org/license-info). 703 BEGIN 704 705 711 712 713 Schema for representing a Trademark, also referred to 714 as Mark. 715 716 718 721 724 727 730 733 735 738 739 740 741 742 744 747 749 750 751 752 754 755 756 757 758 759 760 761 762 763 764 766 767 768 769 770 771 772 773 774 775 776 778 779 780 781 782 784 786 787 789 791 792 793 794 795 796 797 798 800 801 802 803 804 806 808 810 812 813 814 815 816 817 818 820 821 822 823 824 826 828 830 831 832 833 834 836 837 838 840 843 844 845 846 847 848 849 850 851 852 855 856 857 858 859 861 862 864 867 868 869 870 871 873 876 877 878 879 880 882 885 886 887 888 889 890 891 893 896 897 898 899 901 902 904 907 908 909 910 911 913 916 917 918 919 920 921 922 924 927 928 929 930 931 933 934 935 936 937 938 939 941 942 943 944 945 946 947 948 949 END 951 4. Implementation Status 953 Note to RFC Editor: Please remove this section and the reference to 954 RFC 6982 [RFC6982] before publication. 956 This section records the status of known implementations of the 957 format defined by this specification at the time of posting of this 958 Internet-Draft, and is based on a proposal described in RFC 6982 959 [RFC6982]. The description of implementations in this section is 960 intended to assist the IETF in its decision processes in progressing 961 drafts to RFCs. Please note that the listing of any individual 962 implementation here does not imply endorsement by the IETF. 963 Furthermore, no effort has been spent to verify the information 964 presented here that was supplied by IETF contributors. This is not 965 intended as, and must not be construed to be, a catalog of available 966 implementations or their features. Readers are advised to note that 967 other implementations may exist. 969 According to RFC 6982 [RFC6982], "this will allow reviewers and 970 working groups to assign due consideration to documents that have the 971 benefit of running code, which may serve as evidence of valuable 972 experimentation and feedback that have made the implemented protocols 973 more mature. It is up to the individual working groups to use this 974 information as they see fit". 976 4.1. Verisign EPP SDK 978 Organization: Verisign Inc. 980 Name: Verisign EPP SDK 982 Description: The Verisign EPP SDK includes both a full client 983 implementation and a full server stub implementation of draft-ietf- 984 eppext-tmch-smd. 986 Level of maturity: Production 988 Coverage: All aspects of the draft-ietf-eppext-tmch-smd are 989 implemented. 991 Licensing: GNU Lesser General Public License 993 Contact: jgould@verisign.com 995 URL: http://www.verisigninc.com/en_US/channel-resources/domain- 996 registry-products/epp-sdks 998 4.2. Verisign Consolidated Top Level Domain (CTLD) SRS 1000 Organization: Verisign Inc. 1002 Name: Verisign Consolidated Top Level Domain (CTLD) Shared Registry 1003 System (SRS) 1005 Description: The Verisign Consolidated Top Level Domain (CTLD) Shared 1006 Registry System (SRS) implements the server-side of draft-ietf- 1007 eppext-tmch-smd for a variety of Top Level Domains (TLD's). 1009 Level of maturity: Production 1011 Coverage: Implements parsing and validation of all aspects of draft- 1012 ietf-eppext-tmch-smd including the Signed Mark, the Encoded Signed 1013 Mark, and the contained Mark. Implements the encoding of the Mark in 1014 supporting the response of draft-ietf-eppext-launchphase. 1016 Licensing: Proprietary 1018 Contact: jgould@verisign.com 1020 4.3. Verisign .COM / .NET SRS 1022 Organization: Verisign Inc. 1024 Name: Verisign .COM / .NET Shared Registry System (SRS) 1026 Description: The Verisign Shared Registry System (SRS) for .COM, .NET 1027 and other IDN TLD's implements the server-side of draft-ietf-eppext- 1028 tmch-smd. 1030 Level of maturity: Operational Test Environment (OTE) 1032 Coverage: Implements parsing and validation of all aspects of draft- 1033 ietf-eppext-tmch-smd including the Signed Mark, the Encoded Signed 1034 Mark, and the contained Mark. 1036 Licensing: Proprietary 1038 Contact: jgould@verisign.com 1040 4.4. REngin v3.7 1042 Organisation: Domain Name Services (Pty) Ltd 1044 Name: REngin v3.7 1045 Description: Server side implementation only 1047 Level of maturity: Production 1049 Coverage: All aspects of draft-ietf-eppext-tmch-smd have been 1050 implemented 1052 Licensing: Proprietary Licensing with Maintenance Contracts 1054 Contact: info@dnservices.co.za 1056 URL: http://domain-name.services 1058 4.5. Uniregistry Corp. Shared Registry System (uSRS) 1060 Organization: Uniregistry Corp. 1062 Name: Uniregistry Corp. Shared Registry System (uSRS) 1064 Description: Uniregistry's Shared Registry System implements the 1065 server-side of draft-ietf-eppext-tmch-smd for its TLD registry. 1067 Level of maturity: Production 1069 Coverage: Implements parsing and validation of all aspects of draft- 1070 ietf-eppext-tmch-smd including the Signed Mark, the Encoded Signed 1071 Mark, and the contained Mark. Implements the encoding of the Mark in 1072 supporting the response of draft-ietf-eppext-launchphase. 1074 Licensing: Proprietary 1076 Contact: fobispo@uniregistry.link 1078 5. Acknowledgements 1080 Special thanks to Chris Wright for creating the first prototype of a 1081 SMD; James Gould, Wil Tan and Gavin Brown for creating the mark and 1082 SMD definitions in their EPP draft launch extension on which this 1083 draft is based. Portions of the security section were shamefully 1084 copied from RFC5105. The author would like to acknowledge the 1085 following individuals for their contributions to this document: Scott 1086 Hollenbeck and Jan Jansen. 1088 6. IANA Considerations 1090 This document uses URNs to describe XML namespaces and XML schemas 1091 conforming to a registry mechanism described in [RFC3688]. Two URI 1092 assignments have been registered by the IANA. 1094 Registration request for the signed mark namespace: 1096 URI: urn:ietf:params:xml:ns:signedMark-1.0 1098 Registrant Contact: IESG 1100 XML: None. Namespace URIs do not represent an XML specification. 1102 Registration request for the signed mark schema: 1104 URI: urn:ietf:params:xml:schema:signedMark-1.0 1106 Registrant Contact: IESG 1108 XML: See the "Formal Syntax" section of this document. 1110 Registration request for the mark namespace: 1112 URI: urn:ietf:params:xml:ns:mark-1.0 1114 Registrant Contact: IESG 1116 XML: None. Namespace URIs do not represent an XML specification. 1118 Registration request for the mark schema: 1120 URI: urn:ietf:params:xml:schema:mark-1.0 1122 Registrant Contact: IESG 1124 XML: See the "Formal Syntax" section of this document. 1126 7. Security Considerations 1128 The security of a Signed Mark object depends on the security of the 1129 underlying XML DSIG algorithms. As such, all the security 1130 considerations from [XMLDSIG] apply here as well. 1132 The digital signature algorithm used in Signed Mark objects SHOULD be 1133 RSA-SHA256 [RFC4051]. The size of the RSA key SHOULD be at least 1134 2048 bits. A valid reason for choosing something else would be if 1135 RSA-SHA256 would be deemed to not provide sufficient security. 1137 In the case of the ICANN Trademark Clearinghouse (TMCH), Signed Mark 1138 objects use the algorithms for digesting and signing recommended in 1139 this document. 1141 Signed Marks are used primarily for sunrise domain name registrations 1142 in gTLDs, but other third parties might be using them. A party using 1143 Signed Marks should verify that the digital signature is valid based 1144 on local policy. In the case of gTLDs, the RPM Requirements document 1145 [ICANN-TMCH] defines such policy, and the PKI is defined in 1146 [I-D.ietf-eppext-tmch-func-spec]. Implementations will need to 1147 implement such a PKI (or an equivalent) in order for the signatures 1148 defined in this document to have any useful semantics. 1150 8. References 1152 8.1. Normative References 1154 [ICANN-TMCH] 1155 ICANN, "ICANN Trademark Clearinghouse, Rights Protection 1156 Mechanism Requirements", 2013, 1157 . 1160 [ISO3166-2] 1161 ISO, "International Standard for country codes and codes 1162 for their subdivisions", 2006, 1163 . 1165 [ITU.E164.2005] 1166 International Telecommunication Union, "The international 1167 public telecommunication numbering plan", 2010, 1168 . 1170 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1171 Requirement Levels", BCP 14, RFC 2119, 1172 DOI 10.17487/RFC2119, March 1997, 1173 . 1175 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1176 DOI 10.17487/RFC3688, January 2004, 1177 . 1179 [RFC4051] Eastlake 3rd, D., "Additional XML Security Uniform 1180 Resource Identifiers (URIs)", RFC 4051, 1181 DOI 10.17487/RFC4051, April 2005, 1182 . 1184 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1185 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1186 . 1188 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1189 DOI 10.17487/RFC5322, October 2008, 1190 . 1192 [RFC5890] Klensin, J., "Internationalized Domain Names for 1193 Applications (IDNA): Definitions and Document Framework", 1194 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1195 . 1197 [WIPO-NICE-CLASSES] 1198 WIPO, "WIPO Nice Classification", 2015, 1199 . 1201 [WIPO.ST3] 1202 WIPO, "Recommended standard on two-letter codes for the 1203 representation of states, other entities and 1204 intergovernmental organizations", March 2007, 1205 . 1207 [XMLC14N] W3C Recommendation, "Exclusive XML Canonicalization 1208 Version 1.0", 2002, 1209 . 1211 [XMLDSIG] W3C Recommendation, "XML Signature Syntax and Processing 1212 (Second Edition)", 2013, 1213 . 1215 8.2. Informative References 1217 [I-D.ietf-eppext-tmch-func-spec] 1218 Lozano, G., "TMCH functional specifications", draft-ietf- 1219 eppext-tmch-func-spec-00 (work in progress), October 2015. 1221 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1222 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1223 . 1225 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1226 Code: The Implementation Status Section", RFC 6982, 1227 DOI 10.17487/RFC6982, July 2013, 1228 . 1230 Author's Address 1231 Gustavo Lozano 1232 ICANN 1233 12025 Waterfront Drive, Suite 300 1234 Los Angeles 90292 1235 US 1237 Phone: +1.3103015800 1238 Email: gustavo.lozano@icann.org