idnits 2.17.1 draft-ietf-eppext-tmch-smd-04.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 (January 04, 2016) is 3034 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' -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 January 04, 2016 5 Expires: July 7, 2016 7 Mark and Signed Mark Objects Mapping 8 draft-ietf-eppext-tmch-smd-04 10 Abstract 12 This document describes the format of a mark and a digitally signed 13 mark used by trademark holders for registering domain names during 14 the sunrise phase of generic Top Level Domains (gTLDs). 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on July 7, 2016. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Object Description . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Holder and Contacts objects . . . . . . . . . . . . . . . 4 54 2.2. Mark . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 2.3. Signed Mark . . . . . . . . . . . . . . . . . . . . . . . 9 56 2.4. Encoded Signed Mark . . . . . . . . . . . . . . . . . . . 13 57 3. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13 58 3.1. Signed Mark Schema . . . . . . . . . . . . . . . . . . . 13 59 3.2. Mark Schema . . . . . . . . . . . . . . . . . . . . . . . 15 60 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 61 4.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 21 62 4.2. Verisign Consolidated Top Level Domain (CTLD) SRS . . . . 22 63 4.3. Verisign .COM / .NET SRS . . . . . . . . . . . . . . . . 22 64 4.4. REngin v3.7 . . . . . . . . . . . . . . . . . . . . . . . 22 65 4.5. Uniregistry Corp. Shared Registry System (uSRS) . . . . . 23 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 25 71 8.2. Informative References . . . . . . . . . . . . . . . . . 26 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 74 1. Introduction 76 Domain Name Registries (DNRs) may operate in special modes for 77 certain periods of time enabling trademark holders to protect their 78 rights during the introduction of a Top Level Domain (TLD). 80 One of those special modes of operation is the Sunrise Period. The 81 Sunrise Period allows trademark holders an advance opportunity to 82 register domain names corresponding to their trademarks before names 83 are generally available to the public. 85 This specification was defined as part of the development of the 86 ICANN Trademark Clearinghouse (TMCH). The ICANN TMCH is a global 87 repository for trademark data used by DNRs, registrars and trademark 88 holders during the registration process of domain names. 90 This document describes a mapping of the common elements found in 91 trademark data (Mark). A digitally signed Mark (Signed Mark) format 92 is defined in order to support digital signatures on the Mark object. 93 Finally a mapping for encoding the Signed Mark is defined. 95 This specification is intended to be used in the gTLD space, but 96 nothing precudle the use of this format by other entities. 98 The detailed requirements regarding the public key infrastructure, 99 authorized validators, and other architectural details must be 100 defined based on the local policy of the entities using this 101 specification. In the case of gTLDs, the detailed architectural 102 requirements regarding the use of this specification are defined in 103 the Rights Protection Mechanism Requirements document ([ICANN-TMCH]). 105 The objects specified in this document can be referenced by 106 application protocols like the Extensible Provisioning Protocol 107 (EPP), defined in [RFC5730]. 109 1.1. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 XML (EXtensible Markup Language) is case sensitive. Unless stated 116 otherwise, XML specifications and examples provided in this document 117 MUST be interpreted in the character case presented in order to 118 develop a conforming implementation. 120 "signedMark-1.0" is used as an abbreviation for 121 "urn:ietf:params:xml:ns:signedMark-1.0". The XML namespace prefix 122 "smd" is used, but implementations MUST NOT depend on it and instead 123 employ a proper namespace-aware XML parser and serializer to 124 interpret and output the XML documents. 126 "mark-1.0" is used as an abbreviation for 127 "urn:ietf:params:xml:ns:mark-1.0". The XML namespace prefix "mark" 128 is used, but implementations MUST NOT depend on it and instead employ 129 a proper namespace-aware XML parser and serializer to interpret and 130 output the XML documents. 132 2. Object Description 134 This section defines the Mark and Signed Mark objects. Empty complex 135 element types and abstract elements are defined to support additional 136 Mark and Signed Mark definition using XML schema substitution groups. 137 Support for replacement through the XML schema substitution groups is 138 included in the description of the objects. 140 This section defines some elements as OPTIONAL, the elements not 141 defined as OPTIONAL are REQUIRED to be included in the appropriate 142 objects. 144 The following elements are defined as telephone numbers: 145 , and . The representation of 146 telephone numbers in this specification is derived from structures 147 defined in [ITU.E164.2005]. Telephone numbers described in this 148 mapping are character strings that MUST begin with a plus sign ("+", 149 ASCII value 0x002B), followed by a country code defined in 150 [ITU.E164.2005], followed by a dot (".", ASCII value 0x002E), 151 followed by a sequence of digits representing the telephone number. 152 An optional "x" attribute is provided to note telephone extension 153 information. 155 The following elements are defined as email addresses: 156 and . Email address syntax is defined in [RFC5322]. 158 2.1. Holder and Contacts objects 160 Marks are linked to Holder objects and optionally linked to Contact 161 objects. This section defines the and 162 objects. 164 o The child elements of include: 166 * A element that contains the name of the holder. At 167 least one of and MUST be specified, and 168 is OPTIONAL if is specified. 170 * A element that contains the name of the organization 171 holder of the mark. At least one of and 172 MUST be specified, and is OPTIONAL if is 173 specified. 175 * A element that contains the address information of 176 the holder of a mark. A contains the following 177 child elements: 179 + One, two or three OPTIONAL elements that 180 contains the organization's street address. 182 + A element that contains the organization's city. 184 + An OPTIONAL element that contains the 185 organization's state or province. 187 + An OPTIONAL element that contains the 188 organization's postal code. 190 + A element that contains the organization's country 191 code. This a two-character code from [ISO3166-2]. 193 * An OPTIONAL element that contains the 194 organization's voice telephone number. 196 * An OPTIONAL element that contains the organization's 197 facsimile telephone number. 199 * An OPTIONAL element that contains the email 200 address of the holder. 202 o The child elements of include: 204 * A element that contains name of the responsible 205 person. 207 * An OPTIONAL element that contains the name of the 208 organization of the contact. 210 * A element that contains the address information of 211 the contact. A contains the following child 212 elements: 214 + One, two or three OPTIONAL elements that 215 contains the contact's street address. 217 + A element that contains the contact's city. 219 + An OPTIONAL element that contains the contact's 220 state or province. 222 + An OPTIONAL element that contains the contact's 223 postal code. 225 + A element that contains the contact's country 226 code. This a two-character code from [ISO3166-2]. 228 * A element that contains the contact's voice 229 telephone number. 231 * An OPTIONAL element that contains the contact's 232 facsimile telephone number. 234 * A element that contains the contact's email 235 address. 237 2.2. Mark 239 A element that describes an applicant's prior right to a 240 given domain name. 242 A element substitutes for the 243 abstract element to define a concrete definition of a mark. The 244 element can be replaced by other mark definitions 245 using the XML schema substitution groups feature. 247 The child elements of the element include: 249 One or more , and 250 elements that contains the detailed information of marks. 252 o A element that contains the following child 253 elements: 255 * A element that contains an identifier of the mark. 256 The identifier MUST be globally unique in relation to the 257 repository of marks. A value is a concatenation of 258 the local identifier, followed by a hyphen ("-", ASCII value 259 0x002D), followed by the issuer identifier. 261 * A element that contains the mark text string. 263 * One or more elements that contains the 264 information of the holder of the mark. An "entitlement" 265 attribute is used to identify the entitlement of the holder, 266 possible values are: owner, assignee and licensee. 268 * Zero or more OPTIONAL elements that contains the 269 information of the representative of the mark registration. A 270 "type" attribute is used to identify the type of contact, 271 possible values are: owner, agent or thirdparty. 273 * A element that contains the two-character 274 code of the jurisdiction where the trademark was registered. 275 This is a two-character code from [WIPO.ST3]. 277 * Zero or more OPTIONAL elements that contain the 278 WIPO Nice Classification class numbers of the mark as defined 279 in the WIPO Nice Classification [WIPO-NICE-CLASSES]. 281 * Zero or more OPTIONAL elements that contain the 282 A-label form (as defined in [RFC5890]) of the label that 283 correspond to the . 285 * A element that contains the full 286 description of the goods and services mentioned in the mark 287 registration document. 289 * An OPTIONAL element that contains the trademark 290 application ID registered in the trademark office. 292 * An OPTIONAL element that contains the date the 293 trademark was applied for. 295 * A element that contains the trademark 296 registration number registered in the trademark office. 298 * A element that contains the date the trademark 299 was registered. 301 * An OPTIONAL element that contains the expiration 302 date of the trademark. 304 o A element that contains the following child 305 elements: 307 * A element that contains an identifier of the mark. 308 The identifier MUST be globally unique in relation to the 309 repository of marks. A value is a concatenation of 310 the local identifier, followed by a hyphen ("-", ASCII value 311 0x002D), followed by the issuer identifier. 313 * A element that contains the mark text string. 315 * One or more elements that contains the 316 information of the holder of the mark. An "entitlement" 317 attribute is used to identify the entitlement of the holder, 318 possible values are: owner, assignee and licensee. 320 * Zero or more OPTIONAL elements that contains the 321 information of the representative of the mark registration. A 322 "type" attribute is used to identify the type of contact, 323 possible values are: owner, agent or thirdparty. 325 * One or more elements that contain the 326 countries and region of the country where the mark is 327 protected. The element contains the 328 following child elements: 330 + A element that contains the two-character code of 331 the country in which the mark is protected. This is a two- 332 character code from [ISO3166-2]. 334 + An OPTIONAL element that contains the name of 335 a city, state, province or other geographic region of 336 in which the mark is protected. 338 + Zero or more OPTIONAL elements that contains 339 the two-character code of the countries of the ruling. This 340 is a two-character code from [ISO3166-2]. 342 * Zero or more OPTIONAL elements that contain the 343 A-label form (as defined in [RFC5890]) of the label that 344 correspond to the . 346 * A element that contains the full 347 description of the goods and services mentioned in the mark 348 registration document. 350 * A element that contains the number of the mark of 351 the treaty or statute. 353 * A element that contains the date of protection 354 of the mark. 356 * A element that contains the title of the treaty or 357 statute. 359 * A element that contains the execution date of 360 the treaty or statute. 362 o A element that contains the following child elements: 364 * A element that contains an identifier of the mark. 365 The identifier MUST be globally unique in relation to the 366 repository of marks. A value is a concatenation of 367 the local identifier, followed by a hyphen ("-", ASCII value 368 0x002D), followed by the issuer identifier. 370 * A element that contains the mark text string. 372 * One or more elements that contains the 373 information of the holder of the mark. An "entitlement" 374 attribute is used to identify the entitlement of the holder, 375 possible values are: owner, assignee and licensee. 377 * Zero or more OPTIONAL elements that contains the 378 information of the representative of the mark registration. A 379 "type" attribute is used to identify the type of contact, 380 possible values are: owner, agent or thirdparty. 382 * Zero or more OPTIONAL elements that contain the 383 A-label form (as defined in [RFC5890]) of the label that 384 correspond to the . 386 * A element that contains the full 387 description of the goods and services mentioned in the mark 388 registration document. 390 * A element that contains the reference number of 391 the court's opinion. 393 * A element that contains the date of protection 394 of the mark. 396 * A element that contains the two-character code of the 397 country where the court is located. This a two-character code 398 from [ISO3166-2]. 400 * Zero or more OPTIONAL elements that contains the 401 name of a city, state, province or other geographic region of 402 in which the mark is protected. In case 403 is specified a default-deny approach MUST be 404 assumed regarding the regions of a country. 406 * A element that contains the name of the court. 408 2.3. Signed Mark 410 The is the fragment of XML that is digitally signed 411 using XML Signature [XMLDSIG]. The includes a 412 required "id" attribute of type XSD ID for use with an IDREF URI from 413 the Signature element. 415 A element substitutes for the 416 abstract element to define a concrete 417 definition of a signed mark. The element 418 can be replaced by other signed mark definitions using the XML schema 419 substitution groups feature. 421 The child elements of the element include: 423 o The value is a concatenation of the local identifier, 424 followed by a hyphen ("-", ASCII value 0x002D), followed by the 425 issuer identifier. 427 o A element that contains the information of the 428 issuer of the mark registration. A "issuerID" attribute is used 429 to specify the issuer identifier. The child elements include: 431 * A element that contains the organization name of the 432 issuer. 434 * A element that contains the issuer customer support 435 email address. 437 * An OPTIONAL element that contains the HTTP or HTTPS 438 URL of the issuer's site. 440 * An OPTIONAL element that contains the issuer's 441 voice telephone number. 443 o A element that contains the creation date and time 444 of the signed mark. 446 o A element that contains the expiration date and 447 time of the signed mark. 449 o A element that contains the mark information as 450 defined in the Mark (Section 2.2) section. 452 o A XML Signature [XMLDSIG] for the . 453 Use of a namespace prefix, like "dsig", is recommended for the 454 "http://www.w3.org/TR/xmldsig-core/" elements. 456 The following is an example using the XML Signature 457 [XMLDSIG] to sign all of the elements of element. 459 460 462 0000001751376056503931-65535 463 464 ICANN TMCH TESTING TMV 465 notavailable@example.com 466 https://www.example.com 467 +32.000000 468 469 2013-08-09T13:55:03.931Z 470 2017-07-23T22:00:00.000Z 471 472 473 00052013734689731373468973-65535 474 Test & Validate 475 476 Ag corporation 477 478 1305 Bright Avenue 479 Arcadia 480 CA 481 90028 482 US 483 484 485 486 Tony Holland 487 Ag corporation 488 489 1305 Bright Avenue 490 Arcadia 491 CA 492 90028 493 US 494 495 +1.2025562302 496 +1.2025562301 497 info@agcorporation.com 498 499 US 500 15 501 testandvalidate 502 test---validate 503 testand-validate 504 test-et-validate 505 test-validate 506 test--validate 507 test-etvalidate 508 testetvalidate 509 testvalidate 510 testet-validate 511 guitar 512 1234 513 2012-12-31T23:00:00.000Z 514 515 516 517 518 520 522 523 524 526 527 529 wgyW3nZPoEfpptlhRILKnOQnbdtU6ArM7ShrAfHgDFg= 530 531 532 533 jMu4PfyQGiJBF0GWSEPFCJjmywCEqR2h4LD+ge6XQ+JnmKFFCuCZS/3SLKAx0L1w 534 QDFO2e0Y69k2G7/LGE37X3vOflobFM1oGwja8+GMVraoto5xAd4/AF7eHukgAymD 535 o9toxoa2h0yV4A4PmXzsU6S86XtCcUE+S/WM72nyn47zoUCzzPKHZBRyeWehVFQ+ 536 jYRMIAMzM57HHQA+6eaXefRvtPETgUO4aVIVSugc4OUAZZwbYcZrC6wOaQqqqAZi 537 30aPOBYbAvHMSmWSS+hFkbshomJfHxb97TD2grlYNrQIzqXk7WbHWy2SYdA+sI/Z 538 ipJsXNa6osTUw1CzA7jfwA== 539 540 541 542 543 MIIESTCCAzGgAwIBAgIBAjANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEL 544 MAkGA1UECBMCQ0ExFDASBgNVBAcTC0xvcyBBbmdlbGVzMRMwEQYDVQQKEwpJQ0FO 545 TiBUTUNIMRswGQYDVQQDExJJQ0FOTiBUTUNIIFRFU1QgQ0EwHhcNMTMwMjA4MDAw 546 MDAwWhcNMTgwMjA3MjM1OTU5WjBsMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0Ex 547 FDASBgNVBAcTC0xvcyBBbmdlbGVzMRcwFQYDVQQKEw5WYWxpZGF0b3IgVE1DSDEh 548 MB8GA1UEAxMYVmFsaWRhdG9yIFRNQ0ggVEVTVCBDRVJUMIIBIjANBgkqhkiG9w0B 549 AQEFAAOCAQ8AMIIBCgKCAQEAo/cwvXhbVYl0RDWWvoyeZpETVZVVcMCovUVNg/sw 550 WinuMgEWgVQFrz0xA04pEhXCFVv4evbUpekJ5buqU1gmQyOsCKQlhOHTdPjvkC5u 551 pDqa51Flk0TMaMkIQjs7aUKCmA4RG4tTTGK/EjR1ix8/D0gHYVRldy1YPrMP+ou7 552 5bOVnIos+HifrAtrIv4qEqwLL4FTZAUpaCa2BmgXfy2CSRQbxD5Or1gcSa3vurh5 553 sPMCNxqaXmIXmQipS+DuEBqMM8tldaN7RYojUEKrGVsNk5i9y2/7sjn1zyyUPf7v 554 L4GgDYqhJYWV61DnXgx/Jd6CWxvsnDF6scscQzUTEl+hywIDAQABo4H/MIH8MAwG 555 A1UdEwEB/wQCMAAwHQYDVR0OBBYEFPZEcIQcD/Bj2IFz/LERuo2ADJviMIGMBgNV 556 HSMEgYQwgYGAFO0/7kEh3FuEKS+Q/kYHaD/W6wihoWakZDBiMQswCQYDVQQGEwJV 557 UzELMAkGA1UECBMCQ0ExFDASBgNVBAcTC0xvcyBBbmdlbGVzMRMwEQYDVQQKEwpJ 558 Q0FOTiBUTUNIMRswGQYDVQQDExJJQ0FOTiBUTUNIIFRFU1QgQ0GCAQEwDgYDVR0P 559 AQH/BAQDAgeAMC4GA1UdHwQnMCUwI6AhoB+GHWh0dHA6Ly9jcmwuaWNhbm4ub3Jn 560 L3RtY2guY3JsMA0GCSqGSIb3DQEBCwUAA4IBAQB2qSy7ui+43cebKUKwWPrzz9y/ 561 IkrMeJGKjo40n+9uekaw3DJ5EqiOf/qZ4pjBD++oR6BJCb6NQuQKwnoAz5lE4Ssu 562 y5+i93oT3HfyVc4gNMIoHm1PS19l7DBKrbwbzAea/0jKWVzrvmV7TBfjxD3AQo1R 563 bU5dBr6IjbdLFlnO5x0G0mrG7x5OUPuurihyiURpFDpwH8KAH1wMcCpXGXFRtGKk 564 wydgyVYAty7otkl/z3bZkCVT34gPvF70sR6+QxUy8u0LzF5A/beYaZpxSYG31amL 565 AdXitTWFipaIGea9lEGFM0L9+Bg7XzNn4nVLXokyEB3bgS4scG6QznX23FGk 566 567 568 569 570 572 NOTE: The example shown above includes white-spaces for indentation 573 purposes. It is RECOMMENDED that SMDs do not include white-spaces 574 between the XML elements, in order to mitigate risks of invalidating 575 the digital signature when transferring of SMDs between applications 576 takes place. 578 NOTE: Exclusive XML canonicalization as defined in [XMLC14N] SHOULD 579 be used when generating the SMD. 581 NOTE: The digital signature algorithm used SHOULD be RSA-SHA256 582 [RFC4051]. The size of the RSA key SHOULD be at least 2048 bits. A 583 valid reason for choosing something else would be if RSA-SHA256 would 584 be deemed to not provide sufficient security. 586 2.4. Encoded Signed Mark 588 The element contains an encoded form of the 589 digitally signed element, described in Section 2.3, 590 with the encoding defined by the "encoding" attribute with the 591 default "encoding" value of "base64" [RFC4648]. 593 The following is an example of a element that 594 uses the default "base64" for encoding a element. 596 598 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWduZWRNYXJ 599 rIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRNYXJrLTEuMCIgaW 600 ... (base64 data elided for brevity) ... 601 PC9zbWQ6c2lnbmVkTWFyaz4= 602 604 3. Formal Syntax 606 Two schemas are presented here. The first schema is the schema for 607 the signed mark. The second schema is the schema for the mark. 609 The formal syntax presented here is a complete schema representation 610 of the object mapping suitable for automated validation of EPP XML 611 instances. The BEGIN and END tags are not part of the schema; they 612 are used to note the beginning and ending of the schema for URI 613 registration purposes. 615 3.1. Signed Mark Schema 617 Copyright (c) 2016 IETF Trust and the persons identified as authors 618 of the code. All rights reserved. 620 Redistribution and use in source and binary forms, with or without 621 modification, is permitted pursuant to, and subject to the license 622 terms contained in, the Simplified BSD License set forth in 623 Section 4.c of the IETF Trust's Legal Provisions Relating to IETF 624 Documents (http://trustee.ietf.org/license-info). 626 BEGIN 627 628 636 637 638 Schema for representing a Signed Trademark. 639 640 642 643 645 648 651 654 656 659 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 677 678 679 680 681 682 683 684 685 687 688 689 690 691 692 693 694 695 END 697 3.2. Mark Schema 699 Copyright (c) 2016 IETF Trust and the persons identified as authors 700 of the code. All rights reserved. 702 Redistribution and use in source and binary forms, with or without 703 modification, is permitted pursuant to, and subject to the license 704 terms contained in, the Simplified BSD License set forth in 705 Section 4.c of the IETF Trust's Legal Provisions Relating to IETF 706 Documents (http://trustee.ietf.org/license-info). 708 BEGIN 709 710 715 716 717 Schema for representing a Trademark, also referred to 718 as Mark. 719 720 722 725 728 731 734 737 739 742 743 744 745 746 748 751 753 754 755 756 758 759 760 761 762 763 764 765 766 767 768 770 771 772 773 774 775 776 777 778 779 780 782 783 784 785 786 788 790 791 793 795 796 797 798 799 800 801 802 804 805 806 807 808 810 812 814 816 817 818 819 820 821 822 824 825 826 827 828 830 832 834 835 836 837 838 840 841 842 844 847 848 849 850 851 852 853 854 855 857 860 861 862 863 864 866 867 869 872 873 874 875 876 878 881 882 883 884 885 887 890 891 892 893 894 895 896 898 901 902 903 904 905 906 907 910 911 912 913 914 916 919 920 921 922 923 924 925 927 930 931 932 933 934 936 937 938 939 940 941 942 944 945 946 947 948 949 950 951 952 END 954 4. Implementation Status 956 Note to RFC Editor: Please remove this section and the reference to 957 RFC 6982 [RFC6982] before publication. 959 This section records the status of known implementations of the 960 format defined by this specification at the time of posting of this 961 Internet-Draft, and is based on a proposal described in RFC 6982 962 [RFC6982]. The description of implementations in this section is 963 intended to assist the IETF in its decision processes in progressing 964 drafts to RFCs. Please note that the listing of any individual 965 implementation here does not imply endorsement by the IETF. 966 Furthermore, no effort has been spent to verify the information 967 presented here that was supplied by IETF contributors. This is not 968 intended as, and must not be construed to be, a catalog of available 969 implementations or their features. Readers are advised to note that 970 other implementations may exist. 972 According to RFC 6982 [RFC6982], "this will allow reviewers and 973 working groups to assign due consideration to documents that have the 974 benefit of running code, which may serve as evidence of valuable 975 experimentation and feedback that have made the implemented protocols 976 more mature. It is up to the individual working groups to use this 977 information as they see fit". 979 4.1. Verisign EPP SDK 981 Organization: Verisign Inc. 983 Name: Verisign EPP SDK 985 Description: The Verisign EPP SDK includes both a full client 986 implementation and a full server stub implementation of draft-ietf- 987 eppext-tmch-smd. 989 Level of maturity: Production 991 Coverage: All aspects of the draft-ietf-eppext-tmch-smd are 992 implemented. 994 Licensing: GNU Lesser General Public License 996 Contact: jgould@verisign.com 998 URL: http://www.verisigninc.com/en_US/channel-resources/domain- 999 registry-products/epp-sdks 1001 4.2. Verisign Consolidated Top Level Domain (CTLD) SRS 1003 Organization: Verisign Inc. 1005 Name: Verisign Consolidated Top Level Domain (CTLD) Shared Registry 1006 System (SRS) 1008 Description: The Verisign Consolidated Top Level Domain (CTLD) Shared 1009 Registry System (SRS) implements the server-side of draft-ietf- 1010 eppext-tmch-smd for a variety of Top Level Domains (TLD's). 1012 Level of maturity: Production 1014 Coverage: Implements parsing and validation of all aspects of draft- 1015 ietf-eppext-tmch-smd including the Signed Mark, the Encoded Signed 1016 Mark, and the contained Mark. Implements the encoding of the Mark in 1017 supporting the response of draft-ietf-eppext-launchphase. 1019 Licensing: Proprietary 1021 Contact: jgould@verisign.com 1023 4.3. Verisign .COM / .NET SRS 1025 Organization: Verisign Inc. 1027 Name: Verisign .COM / .NET Shared Registry System (SRS) 1029 Description: The Verisign Shared Registry System (SRS) for .COM, .NET 1030 and other IDN TLD's implements the server-side of draft-ietf-eppext- 1031 tmch-smd. 1033 Level of maturity: Operational Test Environment (OTE) 1035 Coverage: Implements parsing and validation of all aspects of draft- 1036 ietf-eppext-tmch-smd including the Signed Mark, the Encoded Signed 1037 Mark, and the contained Mark. 1039 Licensing: Proprietary 1041 Contact: jgould@verisign.com 1043 4.4. REngin v3.7 1045 Organisation: Domain Name Services (Pty) Ltd 1047 Name: REngin v3.7 1048 Description: Server side implementation only 1050 Level of maturity: Production 1052 Coverage: All aspects of draft-ietf-eppext-tmch-smd have been 1053 implemented 1055 Licensing: Proprietary Licensing with Maintenance Contracts 1057 Contact: info@dnservices.co.za 1059 URL: http://domain-name.services 1061 4.5. Uniregistry Corp. Shared Registry System (uSRS) 1063 Organization: Uniregistry Corp. 1065 Name: Uniregistry Corp. Shared Registry System (uSRS) 1067 Description: Uniregistry's Shared Registry System implements the 1068 server-side of draft-ietf-eppext-tmch-smd for its TLD registry. 1070 Level of maturity: Production 1072 Coverage: Implements parsing and validation of all aspects of draft- 1073 ietf-eppext-tmch-smd including the Signed Mark, the Encoded Signed 1074 Mark, and the contained Mark. Implements the encoding of the Mark in 1075 supporting the response of draft-ietf-eppext-launchphase. 1077 Licensing: Proprietary 1079 Contact: fobispo@uniregistry.link 1081 5. Acknowledgements 1083 Special thanks to Chris Wright for creating the first prototype of a 1084 SMD; James Gould, Wil Tan and Gavin Brown for creating the mark and 1085 SMD definitions in their EPP draft launch extension on which this 1086 draft is based. Portions of the security section were shamefully 1087 copied from RFC5105. The author would like to acknowledge the 1088 following individuals for their contributions to this document: Scott 1089 Hollenbeck and Jan Jansen. 1091 6. IANA Considerations 1093 This document uses URNs to describe XML namespaces and XML schemas 1094 conforming to a registry mechanism described in [RFC3688]. Two URI 1095 assignments have been registered by the IANA. 1097 Registration request for the signed mark namespace: 1099 URI: urn:ietf:params:xml:ns:signedMark-1.0 1101 Registrant Contact: IESG 1103 XML: None. Namespace URIs do not represent an XML specification. 1105 Registration request for the signed mark schema: 1107 URI: urn:ietf:params:xml:schema:signedMark-1.0 1109 Registrant Contact: IESG 1111 XML: See the "Formal Syntax" section of this document. 1113 Registration request for the mark namespace: 1115 URI: urn:ietf:params:xml:ns:mark-1.0 1117 Registrant Contact: IESG 1119 XML: None. Namespace URIs do not represent an XML specification. 1121 Registration request for the mark schema: 1123 URI: urn:ietf:params:xml:schema:mark-1.0 1125 Registrant Contact: IESG 1127 XML: See the "Formal Syntax" section of this document. 1129 7. Security Considerations 1131 The security of a Signed Mark object depends on the security of the 1132 underlying XML DSIG algorithms. As such, all the security 1133 considerations from [XMLDSIG] apply here as well. 1135 In the case of the ICANN Trademark Clearinghouse (TMCH), Signed Mark 1136 objects use the algorithms for digesting and signing recommended in 1137 this document. 1139 Signed Marks are used primarily for sunrise domain name registrations 1140 in gTLDs, but other third-parties might be using them. A party using 1141 Signed Marks should verify that the digital signature is valid based 1142 on local policy. In the case of gTLDs, the RPM Requirements document 1143 [ICANN-TMCH] defines such policy. 1145 8. References 1147 8.1. Normative References 1149 [ICANN-TMCH] 1150 ICANN, "ICANN Trademark Clearinghouse, Rights Protection 1151 Mechanism Requirements", 2013, 1152 . 1155 [ISO3166-2] 1156 ISO, "International Standard for country codes and codes 1157 for their subdivisions", 2006, 1158 . 1160 [ITU.E164.2005] 1161 International Telecommunication Union, "The international 1162 public telecommunication numbering plan", 2010, 1163 . 1165 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1166 Requirement Levels", BCP 14, RFC 2119, 1167 DOI 10.17487/RFC2119, March 1997, 1168 . 1170 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1171 DOI 10.17487/RFC3688, January 2004, 1172 . 1174 [RFC4051] Eastlake 3rd, D., "Additional XML Security Uniform 1175 Resource Identifiers (URIs)", RFC 4051, 1176 DOI 10.17487/RFC4051, April 2005, 1177 . 1179 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1180 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1181 . 1183 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1184 DOI 10.17487/RFC5322, October 2008, 1185 . 1187 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1188 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1189 . 1191 [RFC5890] Klensin, J., "Internationalized Domain Names for 1192 Applications (IDNA): Definitions and Document Framework", 1193 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1194 . 1196 [WIPO-NICE-CLASSES] 1197 WIPO, "WIPO Nice Classification", 2015, 1198 . 1200 [WIPO.ST3] 1201 WIPO, "Recommended standard on two-letter codes for the 1202 representation of states, other entities and 1203 intergovernmental organizations", March 2007, 1204 . 1206 [XMLC14N] W3C Recommendation, "Exclusive XML Canonicalization 1207 Version 1.0", 2002, 1208 . 1210 [XMLDSIG] W3C Recommendation, "XML Signature Syntax and Processing 1211 (Second Edition)", 2013, 1212 . 1214 8.2. Informative References 1216 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1217 Code: The Implementation Status Section", RFC 6982, 1218 DOI 10.17487/RFC6982, July 2013, 1219 . 1221 Author's Address 1223 Gustavo Lozano 1224 ICANN 1225 12025 Waterfront Drive, Suite 300 1226 Los Angeles 90292 1227 US 1229 Phone: +1.3103015800 1230 Email: gustavo.lozano@icann.org