idnits 2.17.1 draft-ietf-eppext-tmch-smd-03.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 (September 28, 2015) is 3134 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. '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: 0 errors (**), 0 flaws (~~), 1 warning (==), 7 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 September 28, 2015 5 Expires: March 31, 2016 7 Mark and Signed Mark Objects Mapping 8 draft-ietf-eppext-tmch-smd-03 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 March 31, 2016. 33 Copyright Notice 35 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Object Description . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Holder and Contacts objects . . . . . . . . . . . . . . . 3 54 2.2. Mark . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.3. Signed Mark . . . . . . . . . . . . . . . . . . . . . . . 8 56 2.4. Encoded Signed Mark . . . . . . . . . . . . . . . . . . . 12 57 2.5. Appendix A. base64 encoded signedMark . . . . . . . . . . 12 58 3. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 59 3.1. Signed Mark Schema . . . . . . . . . . . . . . . . . . . 15 60 3.2. Mark Schema . . . . . . . . . . . . . . . . . . . . . . . 17 61 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 62 4.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 24 63 4.2. Verisign Consolidated Top Level Domain (CTLD) SRS . . . . 24 64 4.3. Verisign .COM / .NET SRS . . . . . . . . . . . . . . . . 25 65 4.4. REngin v3.7 . . . . . . . . . . . . . . . . . . . . . . . 25 66 4.5. Uniregistry Corp. Shared Registry System (uSRS) . . . . . 25 67 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 68 6. Change History . . . . . . . . . . . . . . . . . . . . . . . 26 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 29 73 9.2. Informative References . . . . . . . . . . . . . . . . . 30 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 76 1. Introduction 78 This document describes the format of a mark and a digitally signed 79 mark, used to construct a Signed Mark Data (SMD) file, required by 80 the Internet Corporation for Assigned Names and Numbers (ICANN) 81 Trademark Clearinghouse, Rights Protection Mechanism (RPM) 82 Requirements defined in [ICANN-TMCH]. This document provides a 83 framework that can be referenced by application protocols like the 84 Extensible Provisioning Protocol (EPP), defined in [RFC5730]. 86 1.1. Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 XML is case sensitive. Unless stated otherwise, XML specifications 93 and examples provided in this document MUST be interpreted in the 94 character case presented in order to develop a conforming 95 implementation. 97 "signedMark-1.0" is used as an abbreviation for 98 "urn:ietf:params:xml:ns:signedMark-1.0". The XML namespace prefix 99 "smd" is used, but implementations MUST NOT depend on it and instead 100 employ a proper namespace-aware XML parser and serializer to 101 interpret and output the XML documents. 103 "mark-1.0" is used as an abbreviation for 104 "urn:ietf:params:xml:ns:mark-1.0". The XML namespace prefix "mark" 105 is used, but implementations MUST NOT depend on it and instead employ 106 a proper namespace-aware XML parser and serializer to interpret and 107 output the XML documents. 109 2. Object Description 111 This section defines the objects associated with marks and signed 112 marks. Empty complex element types and abstract elements are defined 113 to support additional mark and signed mark definition using XSD 114 substitution groups. Support for replacement through the XSD 115 substitution groups is included in the descriptions of the objects. 117 2.1. Holder and Contacts objects 119 Marks are linked to Holder objects and optionally linked to Contacts 120 objects. This section defines the and 121 objects. 123 o The child elements of include: 125 * An OPTIONAL element that contains the name of the 126 holder. A MUST be specified in case is 127 not specified. 129 * An OPTIONAL element that contains the name of the 130 organization holder of the mark. A MUST be 131 specified in case is not specified. 133 * A element that contains the address information of 134 the holder of a mark. A contains the following 135 child elements: 137 + One, two or three OPTIONAL elements that 138 contains the organization's street address. 140 + A element that contains the organization's city. 142 + An OPTIONAL element that contains the 143 organization's state or province. 145 + An OPTIONAL element that contains the 146 organization's postal code. 148 + A element that contains the organization's country 149 code. This a two-character code from [ISO3166-2]. 151 * An OPTIONAL element that contains the 152 organization's voice telephone number. 154 * An OPTIONAL element that contains the organization's 155 facsimile telephone number. 157 * An OPTIONAL element that contains the email 158 address of the holder. 160 o The child elements of include: 162 * A element that contains name of the responsible 163 person. 165 * An OPTIONAL element that contains the name of the 166 organization of the contact. 168 * A element that contains the address information of 169 the contact. A contains the following child 170 elements: 172 + One, two or three OPTIONAL elements that 173 contains the contact's street address. 175 + A element that contains the contact's city. 177 + An OPTIONAL element that contains the contact's 178 state or province. 180 + An OPTIONAL element that contains the contact's 181 postal code. 183 + A element that contains the contact's country 184 code. This a two-character code from [ISO3166-2]. 186 * A element that contains the contact's voice 187 telephone number. 189 * An OPTIONAL element that contains the contact's 190 facsimile telephone number. 192 * A element that contains the contact's email 193 address. 195 2.2. Mark 197 A element that describes an applicant's prior right to a 198 given domain name. 200 A element substitutes for the 201 abstract element to define a concrete definition of a mark. The 202 element can be replaced by other mark definitions 203 using the XML schema substitution groups feature. 205 The child elements of the element include: 207 One or more , and 208 elements that contains the detailed information of marks. 210 o A element that contains the following child 211 elements. 213 * A element that contains an identifier of the mark. 214 The identifier MUST be globally unique in relation to the 215 repository of marks. A value is a concatenation of 216 the local identifier, followed by a hyphen ("-", ASCII value 217 0x002D), followed by the issuer identifier. 219 * A element that contains the mark text string. 221 * One or more elements that contains the 222 information of the holder of the mark. An "entitlement" 223 attribute is used to identify the entitlement of the holder, 224 possible values are: owner, assignee and licensee. 226 * Zero or more OPTIONAL elements that contains the 227 information of the representative of the mark registration. A 228 "type" attribute is used to identify the type of contact, 229 possible values are: owner, agent or thirdparty. 231 * A element that contains the two-character 232 code of the jurisdiction where the trademark was registered. 233 This is a two-character code from [WIPO.ST3]. 235 * Zero or more OPTIONAL elements that contain the 236 WIPO Nice Classification class numbers of the mark as defined 237 in the WIPO Nice Classification [WIPO-NICE-CLASSES]. 239 * Zero or more OPTIONAL elements that contain the 240 A-label form (as defined in [RFC5890]) of the label that 241 correspond to the . 243 * A element that contains the full 244 description of the goods and services mentioned in the mark 245 registration document. 247 * An OPTIONAL element that contains the trademark 248 application ID registered in the trademark office. 250 * An OPTIONAL element that contains the date the 251 trademark was applied for. 253 * A element that contains the trademark 254 registration number registered in the trademark office. 256 * A element that contains the date the trademark 257 was registered. 259 * An OPTIONAL element that contains the expiration 260 date of the trademark. 262 o A element that contains the following child 263 elements. 265 * A element that contains an identifier of the mark. 266 The identifier MUST be globally unique in relation to the 267 repository of marks. A value is a concatenation of 268 the local identifier, followed by a hyphen ("-", ASCII value 269 0x002D), followed by the issuer identifier. 271 * A element that contains the mark text string. 273 * One or more elements that contains the 274 information of the holder of the mark. An "entitlement" 275 attribute is used to identify the entitlement of the holder, 276 possible values are: owner, assignee and licensee. 278 * Zero or more OPTIONAL elements that contains the 279 information of the representative of the mark registration. A 280 "type" attribute is used to identify the type of contact, 281 possible values are: owner, agent or thirdparty. 283 * One or more elements that contain the 284 countries and region of the country where the mark is 285 protected. The element contains the 286 following child elements: 288 + A element that contains the two-character code of 289 the country in which the mark is protected. This is a two- 290 character code from [ISO3166-2]. 292 + An OPTIONAL element that contains the name of 293 a city, state, province or other geographic region of 294 in which the mark is protected. 296 + Zero or more OPTIONAL elements that contains 297 the two-character code of the countries of the ruling. This 298 is a two-character code from [ISO3166-2]. 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 * A element that contains the number of the mark of 309 the treaty or statute. 311 * A element that contains the date of protection 312 of the mark. 314 * A element that contains the title of the treaty or 315 statute. 317 * A element that contains the execution date of 318 the treaty or statute. 320 o A element that contains the following child elements. 322 * A element that contains an identifier of the mark. 323 The identifier MUST be globally unique in relation to the 324 repository of marks. A value is a concatenation of 325 the local identifier, followed by a hyphen ("-", ASCII value 326 0x002D), followed by the issuer identifier. 328 * A element that contains the mark text string. 330 * One or more elements that contains the 331 information of the holder of the mark. An "entitlement" 332 attribute is used to identify the entitlement of the holder, 333 possible values are: owner, assignee and licensee. 335 * Zero or more OPTIONAL elements that contains the 336 information of the representative of the mark registration. A 337 "type" attribute is used to identify the type of contact, 338 possible values are: owner, agent or thirdparty. 340 * Zero or more OPTIONAL elements that contain the 341 A-label form (as defined in [RFC5890]) of the label that 342 correspond to the . 344 * A element that contains the full 345 description of the goods and services mentioned in the mark 346 registration document. 348 * A element that contains the reference number of 349 the court's opinion. 351 * A element that contains the date of protection 352 of the mark. 354 * A element that contains the two-character code of the 355 country where the court is located. This a two-character code 356 from [ISO3166-2]. 358 * Zero or more OPTIONAL elements that contains the 359 name of a city, state, province or other geographic region of 360 in which the mark is protected. In case 361 is specified a default-deny approach MUST be 362 assumed regarding the regions of a country. 364 * A element that contains the name of the court. 366 2.3. Signed Mark 368 The is the fragment of XML that is digitally signed 369 using XML Signature [XMLDSIG]. The includes a 370 required "id" attribute of type XSD ID for use with an IDREF URI from 371 the Signature element. The certificate of the issuer MAY be issued 372 by a Certificate Authority (CA) that can be chained with the issuer's 373 certificate by the validating client. 375 A element substitutes for the 376 abstract element to define a concrete 377 definition of a signed mark. The element 378 can be replaced by other signed mark definitions using the XML schema 379 substitution groups feature. 381 The child elements of the element include: 383 o The value is a concatenation of the local identifier, 384 followed by a hyphen ("-", ASCII value 0x002D), followed by the 385 issuer identifier. 387 o A element that contains the information of the 388 issuer of the mark registration. A "issuerID" attribute is used 389 to specify the issuer identifier. The child elements include: 391 * A element that contains the organization name of the 392 issuer. 394 * A element that contains the issuer customer support 395 email address. 397 * An OPTIONAL element that contains the HTTP URL of the 398 issuer's site. 400 * An OPTIONAL element that contains the issuer's 401 voice telephone number. 403 o A element that contains the creation date and time 404 of the signed mark. 406 o A element that contains the expiration date and 407 time of the signed mark. 409 o A element that contains the mark information as 410 defined in the Mark (Section 2.2) section. 412 o A XML Signature [XMLDSIG] for the . 413 Use of a namespace prefix, like "dsig", is recommended for the 414 "http://www.w3.org/TR/xmldsig-core/" elements. 416 The following is an example using the XML Signature 417 [XMLDSIG] to sign all of the elements of element. 419 420 422 0000001751376056503931-65535 423 424 ICANN TMCH TESTING TMV 425 notavailable@example.com 426 http://www.example.com 427 +32.000000 428 429 2013-08-09T13:55:03.931Z 430 2017-07-23T22:00:00.000Z 431 432 433 00052013734689731373468973-65535 434 Test & Validate 435 436 Ag corporation 437 438 1305 Bright Avenue 439 Arcadia 440 CA 441 90028 442 US 443 444 445 446 Tony Holland 447 Ag corporation 448 449 1305 Bright Avenue 450 Arcadia 451 CA 452 90028 453 US 454 455 +1.2025562302 456 +1.2025562301 457 info@agcorporation.com 458 459 US 460 15 461 testandvalidate 462 test---validate 463 testand-validate 464 test-et-validate 465 test-validate 466 test--validate 467 test-etvalidate 468 testetvalidate 469 testvalidate 470 testet-validate 471 guitar 472 1234 473 2012-12-31T23:00:00.000Z 474 475 476 477 478 481 483 484 485 487 488 490 wgyW3nZPoEfpptlhRILKnOQnbdtU6ArM7ShrAfHgDFg= 491 492 493 494 jMu4PfyQGiJBF0GWSEPFCJjmywCEqR2h4LD+ge6XQ+JnmKFFCuCZS/3SLKAx0L1w 495 QDFO2e0Y69k2G7/LGE37X3vOflobFM1oGwja8+GMVraoto5xAd4/AF7eHukgAymD 496 o9toxoa2h0yV4A4PmXzsU6S86XtCcUE+S/WM72nyn47zoUCzzPKHZBRyeWehVFQ+ 497 jYRMIAMzM57HHQA+6eaXefRvtPETgUO4aVIVSugc4OUAZZwbYcZrC6wOaQqqqAZi 498 30aPOBYbAvHMSmWSS+hFkbshomJfHxb97TD2grlYNrQIzqXk7WbHWy2SYdA+sI/Z 499 ipJsXNa6osTUw1CzA7jfwA== 500 501 502 503 504 MIIESTCCAzGgAwIBAgIBAjANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEL 505 MAkGA1UECBMCQ0ExFDASBgNVBAcTC0xvcyBBbmdlbGVzMRMwEQYDVQQKEwpJQ0FO 506 TiBUTUNIMRswGQYDVQQDExJJQ0FOTiBUTUNIIFRFU1QgQ0EwHhcNMTMwMjA4MDAw 507 MDAwWhcNMTgwMjA3MjM1OTU5WjBsMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0Ex 508 FDASBgNVBAcTC0xvcyBBbmdlbGVzMRcwFQYDVQQKEw5WYWxpZGF0b3IgVE1DSDEh 509 MB8GA1UEAxMYVmFsaWRhdG9yIFRNQ0ggVEVTVCBDRVJUMIIBIjANBgkqhkiG9w0B 510 AQEFAAOCAQ8AMIIBCgKCAQEAo/cwvXhbVYl0RDWWvoyeZpETVZVVcMCovUVNg/sw 511 WinuMgEWgVQFrz0xA04pEhXCFVv4evbUpekJ5buqU1gmQyOsCKQlhOHTdPjvkC5u 512 pDqa51Flk0TMaMkIQjs7aUKCmA4RG4tTTGK/EjR1ix8/D0gHYVRldy1YPrMP+ou7 513 5bOVnIos+HifrAtrIv4qEqwLL4FTZAUpaCa2BmgXfy2CSRQbxD5Or1gcSa3vurh5 514 sPMCNxqaXmIXmQipS+DuEBqMM8tldaN7RYojUEKrGVsNk5i9y2/7sjn1zyyUPf7v 515 L4GgDYqhJYWV61DnXgx/Jd6CWxvsnDF6scscQzUTEl+hywIDAQABo4H/MIH8MAwG 516 A1UdEwEB/wQCMAAwHQYDVR0OBBYEFPZEcIQcD/Bj2IFz/LERuo2ADJviMIGMBgNV 517 HSMEgYQwgYGAFO0/7kEh3FuEKS+Q/kYHaD/W6wihoWakZDBiMQswCQYDVQQGEwJV 518 UzELMAkGA1UECBMCQ0ExFDASBgNVBAcTC0xvcyBBbmdlbGVzMRMwEQYDVQQKEwpJ 519 Q0FOTiBUTUNIMRswGQYDVQQDExJJQ0FOTiBUTUNIIFRFU1QgQ0GCAQEwDgYDVR0P 520 AQH/BAQDAgeAMC4GA1UdHwQnMCUwI6AhoB+GHWh0dHA6Ly9jcmwuaWNhbm4ub3Jn 521 L3RtY2guY3JsMA0GCSqGSIb3DQEBCwUAA4IBAQB2qSy7ui+43cebKUKwWPrzz9y/ 522 IkrMeJGKjo40n+9uekaw3DJ5EqiOf/qZ4pjBD++oR6BJCb6NQuQKwnoAz5lE4Ssu 523 y5+i93oT3HfyVc4gNMIoHm1PS19l7DBKrbwbzAea/0jKWVzrvmV7TBfjxD3AQo1R 524 bU5dBr6IjbdLFlnO5x0G0mrG7x5OUPuurihyiURpFDpwH8KAH1wMcCpXGXFRtGKk 525 wydgyVYAty7otkl/z3bZkCVT34gPvF70sR6+QxUy8u0LzF5A/beYaZpxSYG31amL 526 AdXitTWFipaIGea9lEGFM0L9+Bg7XzNn4nVLXokyEB3bgS4scG6QznX23FGk 527 528 529 530 531 533 NOTE: The example shown above includes white-spaces for indentation 534 purposes. It is RECOMMENDED that SMDs do not include white-spaces 535 between the XML elements, in order to mitigate risks of invalidating 536 the digital signature when transferring of SMDs between applications 537 takes place. 539 NOTE: Exclusive XML canonicalization as defined in [XMLC14N] SHOULD 540 be used when generating the SMD. SHA256 as suggested by [RFC6194] 541 and RSA-SHA256 SHOULD be used for digesting and signing respectively. 542 The size of the RSA key SHOULD be at least 2048 bits. 544 2.4. Encoded Signed Mark 546 The element contains an encoded form of the 547 digitally signed element, described in Section 2.3, 548 with the encoding defined by the "encoding" attribute with the 549 default "encoding" value of "base64". The "base64" encoded text of 550 the element MUST conform to [RFC2045]. A 551 full example of a element is presented in 552 Appendix A. 554 2.5. Appendix A. base64 encoded signedMark 556 The following is an example of a element that 557 uses the default "base64" for encoding a element. 559 561 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWduZWRNYXJ 562 rIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRNYXJrLTEuMCIgaW 563 Q9Il84Yzk0ZjRmMS1jZTlmLTRjOTAtOTUzMS01MzE1ZDIzY2EzYmQiPgogIDxzbWQ6aWQ+M 564 DAwMDAwMTc1MTM3NjA1NjUwMzkzMS02NTUzNTwvc21kOmlkPgogIDxzbWQ6aXNzdWVySW5m 565 byBpc3N1ZXJJRD0iNjU1MzUiPgogICAgPHNtZDpvcmc+SUNBTk4gVE1DSCBURVNUSU5HIFR 566 NVjwvc21kOm9yZz4KICAgIDxzbWQ6ZW1haWw+bm90YXZhaWxhYmxlQGV4YW1wbGUuY29tPC 567 9zbWQ6ZW1haWw+CiAgICA8c21kOnVybD5odHRwOi8vd3d3LmV4YW1wbGUuY29tPC9zbWQ6d 568 XJsPgogICAgPHNtZDp2b2ljZT4rMzIuMDAwMDAwPC9zbWQ6dm9pY2U+CiAgPC9zbWQ6aXNz 569 dWVySW5mbz4KICA8c21kOm5vdEJlZm9yZT4yMDEzLTA4LTA5VDEzOjU1OjAzLjkzMVo8L3N 570 tZDpub3RCZWZvcmU+CiAgPHNtZDpub3RBZnRlcj4yMDE3LTA3LTIzVDIyOjAwOjAwLjAwMF 571 o8L3NtZDpub3RBZnRlcj4KICA8bWFyazptYXJrIHhtbG5zOm1hcms9InVybjppZXRmOnBhc 572 mFtczp4bWw6bnM6bWFyay0xLjAiPgogICAgPG1hcms6dHJhZGVtYXJrPgogICAgICA8bWFy 573 azppZD4wMDA1MjAxMzczNDY4OTczMTM3MzQ2ODk3My02NTUzNTwvbWFyazppZD4KICAgICA 574 gPG1hcms6bWFya05hbWU+VGVzdCAmYW1wOyBWYWxpZGF0ZTwvbWFyazptYXJrTmFtZT4KIC 575 AgICAgPG1hcms6aG9sZGVyIGVudGl0bGVtZW50PSJvd25lciI+CiAgICAgICAgPG1hcms6b 576 3JnPkFnIGNvcnBvcmF0aW9uPC9tYXJrOm9yZz4KICAgICAgICA8bWFyazphZGRyPgogICAg 577 ICAgICAgPG1hcms6c3RyZWV0PjEzMDUgQnJpZ2h0IEF2ZW51ZTwvbWFyazpzdHJlZXQ+CiA 578 gICAgICAgICA8bWFyazpjaXR5PkFyY2FkaWE8L21hcms6Y2l0eT4KICAgICAgICAgIDxtYX 579 JrOnNwPkNBPC9tYXJrOnNwPgogICAgICAgICAgPG1hcms6cGM+OTAwMjg8L21hcms6cGM+C 580 iAgICAgICAgICA8bWFyazpjYz5VUzwvbWFyazpjYz4KICAgICAgICA8L21hcms6YWRkcj4K 581 ICAgICAgPC9tYXJrOmhvbGRlcj4KICAgICAgPG1hcms6Y29udGFjdCB0eXBlPSJhZ2VudCI 582 +CiAgICAgICAgPG1hcms6bmFtZT5Ub255IEhvbGxhbmQ8L21hcms6bmFtZT4KICAgICAgIC 583 A8bWFyazpvcmc+QWcgY29ycG9yYXRpb248L21hcms6b3JnPgogICAgICAgIDxtYXJrOmFkZ 584 HI+CiAgICAgICAgICA8bWFyazpzdHJlZXQ+MTMwNSBCcmlnaHQgQXZlbnVlPC9tYXJrOnN0 585 cmVldD4KICAgICAgICAgIDxtYXJrOmNpdHk+QXJjYWRpYTwvbWFyazpjaXR5PgogICAgICA 586 gICAgPG1hcms6c3A+Q0E8L21hcms6c3A+CiAgICAgICAgICA8bWFyazpwYz45MDAyODwvbW 587 FyazpwYz4KICAgICAgICAgIDxtYXJrOmNjPlVTPC9tYXJrOmNjPgogICAgICAgIDwvbWFya 588 zphZGRyPgogICAgICAgIDxtYXJrOnZvaWNlPisxLjIwMjU1NjIzMDI8L21hcms6dm9pY2U+ 589 CiAgICAgICAgPG1hcms6ZmF4PisxLjIwMjU1NjIzMDE8L21hcms6ZmF4PgogICAgICAgIDx 590 tYXJrOmVtYWlsPmluZm9AYWdjb3Jwb3JhdGlvbi5jb208L21hcms6ZW1haWw+CiAgICAgID 591 wvbWFyazpjb250YWN0PgogICAgICA8bWFyazpqdXJpc2RpY3Rpb24+VVM8L21hcms6anVya 592 XNkaWN0aW9uPgogICAgICA8bWFyazpjbGFzcz4xNTwvbWFyazpjbGFzcz4KICAgICAgPG1h 593 cms6bGFiZWw+dGVzdGFuZHZhbGlkYXRlPC9tYXJrOmxhYmVsPgogICAgICA8bWFyazpsYWJ 594 lbD50ZXN0LS0tdmFsaWRhdGU8L21hcms6bGFiZWw+CiAgICAgIDxtYXJrOmxhYmVsPnRlc3 595 RhbmQtdmFsaWRhdGU8L21hcms6bGFiZWw+CiAgICAgIDxtYXJrOmxhYmVsPnRlc3QtZXQtd 596 mFsaWRhdGU8L21hcms6bGFiZWw+CiAgICAgIDxtYXJrOmxhYmVsPnRlc3QtdmFsaWRhdGU8 597 L21hcms6bGFiZWw+CiAgICAgIDxtYXJrOmxhYmVsPnRlc3QtLXZhbGlkYXRlPC9tYXJrOmx 598 hYmVsPgogICAgICA8bWFyazpsYWJlbD50ZXN0LWV0dmFsaWRhdGU8L21hcms6bGFiZWw+Ci 599 AgICAgIDxtYXJrOmxhYmVsPnRlc3RldHZhbGlkYXRlPC9tYXJrOmxhYmVsPgogICAgICA8b 600 WFyazpsYWJlbD50ZXN0dmFsaWRhdGU8L21hcms6bGFiZWw+CiAgICAgIDxtYXJrOmxhYmVs 601 PnRlc3RldC12YWxpZGF0ZTwvbWFyazpsYWJlbD4KICAgICAgPG1hcms6Z29vZHNBbmRTZXJ 602 2aWNlcz5ndWl0YXI8L21hcms6Z29vZHNBbmRTZXJ2aWNlcz4KICAgICAgPG1hcms6cmVnTn 603 VtPjEyMzQ8L21hcms6cmVnTnVtPgogICAgICA8bWFyazpyZWdEYXRlPjIwMTItMTItMzFUM 604 jM6MDA6MDAuMDAwWjwvbWFyazpyZWdEYXRlPgogICAgPC9tYXJrOnRyYWRlbWFyaz4KICA8 605 L21hcms6bWFyaz4KPGRzOlNpZ25hdHVyZSB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmc 606 vMjAwMC8wOS94bWxkc2lnIyIgSWQ9Il81ODg5YzM5Zi1jMzM3LTQ0NzctOTU1Ni05NTNiZT 607 A5Y2NkMTgiPjxkczpTaWduZWRJbmZvPjxkczpDYW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ 608 29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+PGRz 609 OlNpZ25hdHVyZU1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQ 610 veG1sZHNpZy1tb3JlI3JzYS1zaGEyNTYiLz48ZHM6UmVmZXJlbmNlIFVSST0iI184Yzk0Zj 611 RmMS1jZTlmLTRjOTAtOTUzMS01MzE1ZDIzY2EzYmQiPjxkczpUcmFuc2Zvcm1zPjxkczpUc 612 mFuc2Zvcm0gQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcj 613 ZW52ZWxvcGVkLXNpZ25hdHVyZSIvPjxkczpUcmFuc2Zvcm0gQWxnb3JpdGhtPSJodHRwOi8 614 vd3d3LnczLm9yZy8yMDAxLzEwL3htbC1leGMtYzE0biMiLz48L2RzOlRyYW5zZm9ybXM+PG 615 RzOkRpZ2VzdE1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQve 616 G1sZW5jI3NoYTI1NiIvPjxkczpEaWdlc3RWYWx1ZT5IdUdKYlZCWkVaVGlFelB2d0NObVFs 617 NmFMZEExWHo1QzAzdnhDWFBIZW1BPTwvZHM6RGlnZXN0VmFsdWU+PC9kczpSZWZlcmVuY2U 618 +PGRzOlJlZmVyZW5jZSBVUkk9IiNfMWRlNTg5OGMtNmY3Ny00ZDViLTlkZDgtMzE4MWM5MT 619 E3Yzk3Ij48ZHM6VHJhbnNmb3Jtcz48ZHM6VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL 620 3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+PC9kczpUcmFuc2Zvcm1zPjxk 621 czpEaWdlc3RNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3h 622 tbGVuYyNzaGEyNTYiLz48ZHM6RGlnZXN0VmFsdWU+NHBiU0M2M2xObVBxelc3TDBNRDBxZ0 623 5GNHc5SUE3YXQ3OWxEVE5VZjBndz08L2RzOkRpZ2VzdFZhbHVlPjwvZHM6UmVmZXJlbmNlP 624 jwvZHM6U2lnbmVkSW5mbz48ZHM6U2lnbmF0dXJlVmFsdWUgSWQ9Il9hODAwZmIwNS02NjRh 625 LTQ2OTItYjM5MS04OTM4NTlhNTM0OGQiPlc5VHAxQ09HeEk4dlZQNkZONEdpYlhtc3RRM1Z 626 0bmpSZVN3VVdicFZCTEtmenZ1L1c1OGNoOUdxdnRQTm9HZTdXOXVvQUt0U1J0MUkKMzdPeD 627 IwQmVQb2xGdWZmekVVR3NGMHBETkRoWmNiRUdEMlVWRTBpYnhIRkVDUU13d0ppK1NVb2ora 628 3JIWmRXM0FybmNaZ0RkMkhXZgpudVJZSmVucnpCS2k2RG1YVlVRYlhXRFVkbGxzcjlDSmtB 629 THYrd0s2V2RweE9Na0NTc2E0WUU2bEVNTjVXNGhzUXFlZ2N6ZGkwdUZ0CnZxQ2JLVnM3RTJ 630 3c0VIZC94aUxzbldZNEUxNWdLNnI0UW9tWHJqdFI0ZkFyZ1lMTnRLK09NRCt6UktNeGNuNV 631 F2QzJVeHlzNUV6RHcKNmhlenYrdXBxTldkRjRYL2lCNW1JY25DMzAraVBpY3lDb2JHUlE9P 632 TwvZHM6U2lnbmF0dXJlVmFsdWU+PGRzOktleUluZm8gSWQ9Il8xZGU1ODk4Yy02Zjc3LTRk 633 NWItOWRkOC0zMTgxYzkxMTdjOTciPjxkczpYNTA5RGF0YT48ZHM6WDUwOUNlcnRpZmljYXR 634 lPk1JSUZMekNDQkJlZ0F3SUJBZ0lnTHJBYmV2b2FlNTJ5M2Y2QzJ0QjBTbjNwN1hKbTBUMD 635 JGb2d4S0NmTmhYb3dEUVlKS29aSWh2Y04KQVFFTEJRQXdmREVMTUFrR0ExVUVCaE1DVlZNe 636 FBEQTZCZ05WQkFvVE0wbHVkR1Z5Ym1WMElFTnZjbkJ2Y21GMGFXOXVJR1p2Y2lCQgpjM05w 637 WjI1bFpDQk9ZVzFsY3lCaGJtUWdUblZ0WW1WeWN6RXZNQzBHQTFVRUF4TW1TVU5CVGs0Z1Z 638 ISmhaR1Z0WVhKcklFTnNaV0Z5CmFXNW5hRzkxYzJVZ1VHbHNiM1FnUTBFd0hoY05NVE13Tm 639 pJMk1EQXdNREF3V2hjTk1UZ3dOakkxTWpNMU9UVTVXakNCanpFTE1Ba0cKQTFVRUJoTUNRa 640 1V4SURBZUJnTlZCQWdURjBKeWRYTnpaV3h6TFVOaGNHbDBZV3dnVW1WbmFXOXVNUkV3RHdZ 641 RFZRUUhFd2hDY25WegpjMlZzY3pFUk1BOEdBMVVFQ2hNSVJHVnNiMmwwZEdVeE9EQTJCZ05 642 WQkFNVEwwbERRVTVPSUZSTlEwZ2dRWFYwYUc5eWFYcGxaQ0JVCmNtRmtaVzFoY21zZ1VHbH 643 NiM1FnVm1Gc2FXUmhkRzl5TUlJQklqQU5CZ2txaGtpRzl3MEJBUUVGQUFPQ0FROEFNSUlCQ 644 2dLQ0FRRUEKeGxwM0twWUhYM1d5QXNGaFNrM0x3V2ZuR2x4blVERnFGWkEzVW91TVlqL1hp 645 Z2JNa05lRVhJamxrUk9LVDRPUEdmUngvTEF5UmxRUQpqQ012NHFoYmtjWDFwN2FyNjNmbHE 646 0U1pOVmNsMTVsN2gwdVQ1OEZ6U2ZubHowdTVya0hmSkltRDQzK21hUC84Z3YzNkZSMjdqVz 647 hSCjl3WTRoaytXczRJQjBpRlNkOFNYdjFLcjh3L0ptTVFTRGtpdUcrUmZJaXVid1EvZnk3R 648 WtqNVFXaFBadyttTXhOS25IVUx5M3hZejIKTHdWZmZ0andVdWVhY3ZxTlJDa01YbENsT0FE 649 cWZUOG9TWm9lRFhlaEh2bFBzTENlbUdCb1RLdXJza0lTNjlGMHlQRUg1Z3plMEgrZgo4RlJ 650 Pc0lvS1NzVlEzNEI0Uy9qb0U2N25wc0pQVGRLc05QSlR5UUlEQVFBQm80SUJoekNDQVlNd0 651 RBWURWUjBUQVFIL0JBSXdBREFkCkJnTlZIUTRFRmdRVW9GcFk3NnA1eW9ORFJHdFFwelZ1U 652 jgxVVdRMHdnY1lHQTFVZEl3U0J2akNCdTRBVXc2MCtwdFlSQUVXQVhEcFgKU29wdDNERU5u 653 bkdoZ1lDa2ZqQjhNUXN3Q1FZRFZRUUdFd0pWVXpFOE1Eb0dBMVVFQ2hNelNXNTBaWEp1Wlh 654 RZ1EyOXljRzl5WVhScApiMjRnWm05eUlFRnpjMmxuYm1Wa0lFNWhiV1Z6SUdGdVpDQk9kVz 655 FpWlhKek1TOHdMUVlEVlFRREV5WkpRMEZPVGlCVWNtRmtaVzFoCmNtc2dRMnhsWVhKcGJtZ 656 G9iM1Z6WlNCUWFXeHZkQ0JEUVlJZ0xyQWJldm9hZTUyeTNmNkMydEIwU24zcDdYSm0wVDAy 657 Rm9neEtDZk4KaFhrd0RnWURWUjBQQVFIL0JBUURBZ2VBTURRR0ExVWRId1F0TUNzd0thQW5 658 vQ1dHSTJoMGRIQTZMeTlqY213dWFXTmhibTR1YjNKbgpMM1J0WTJoZmNHbHNiM1F1WTNKc0 659 1FVUdBMVVkSUFRK01Ed3dPZ1lES2dNRU1ETXdNUVlJS3dZQkJRVUhBZ0VXSldoMGRIQTZMe 660 TkzCmQzY3VhV05oYm00dWIzSm5MM0JwYkc5MFgzSmxjRzl6YVhSdmNua3dEUVlKS29aSWh2 661 Y05BUUVMQlFBRGdnRUJBSWVEWVlKcjYwVzMKeTlRcyszelJWSTlrZWtLb201dmtIT2FsQjN 662 3SGFaSWFBRllwSTk4dFkwYVZOOWFHT04wdjZXUUYrbnZ6MUtSWlFiQXowMUJYdGFSSgo0bV 663 BrYXJoaHVMbjlOa0J4cDhIUjVxY2MrS0g3Z3Y2ci9jMGlHM2JDTkorUVNyN1FmKzVNbE1vN 664 npMNVVkZFUvVDJqaWJNWENqL2YyCjFRdzN4OVFnb3lYTEZKOW96YUxnUTlSTWtMbE9temtD 665 QWlYTjVBYjQzYUo5ZjdOMmdFMk5uUmpOS21tQzlBQlEwVFJ3RUtWTGhWbDEKVUdxQ0hKM0F 666 sQlhXSVhONXNqUFFjRC8rbkhlRVhNeFl2bEF5cXhYb0QzTVd0UVZqN2oyb3FsYWtPQk1nRz 667 grcTJxWWxtQnRzNEZOaQp3NzQ4SWw1ODZIS0JScXhIdFpkUktXMlZxYVE9PC9kczpYNTA5Q 668 2VydGlmaWNhdGU+PC9kczpYNTA5RGF0YT48L2RzOktleUluZm8+PC9kczpTaWduYXR1cmU+ 669 PC9zbWQ6c2lnbmVkTWFyaz4= 670 672 3. Formal Syntax 674 Two schemas are presented here. The first schema is the schema for 675 the signed mark. The second schema is the schema for the mark. 677 The formal syntax presented here is a complete schema representation 678 of the object mapping suitable for automated validation of EPP XML 679 instances. The BEGIN and END tags are not part of the schema; they 680 are used to note the beginning and ending of the schema for URI 681 registration purposes. 683 3.1. Signed Mark Schema 685 Copyright (c) 2012 IETF Trust and the persons identified as authors 686 of the code. All rights reserved. 688 Redistribution and use in source and binary forms, with or without 689 modification, are permitted provided that the following conditions 690 are met: 692 o Redistributions of source code must retain the above copyright 693 notice, this list of conditions and the following disclaimer. 695 o Redistributions in binary form must reproduce the above copyright 696 notice, this list of conditions and the following disclaimer in 697 the documentation and/or other materials provided with the 698 distribution. 700 o Neither the name of Internet Society, IETF or IETF Trust, nor the 701 names of specific contributors, may be used to endorse or promote 702 products derived from this software without specific prior written 703 permission. 705 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 706 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 707 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 708 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 709 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 710 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 711 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 712 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 713 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 714 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 715 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 717 BEGIN 718 719 727 728 729 Schema for representing a Signed Trademark. 730 731 733 735 738 741 744 747 749 752 754 755 756 757 758 759 760 761 762 763 764 765 767 768 769 771 772 773 774 775 776 777 778 779 781 782 783 784 785 786 787 788 789 END 791 3.2. Mark Schema 793 Copyright (c) 2012 IETF Trust and the persons identified as authors 794 of the code. All rights reserved. 796 Redistribution and use in source and binary forms, with or without 797 modification, are permitted provided that the following conditions 798 are met: 800 o Redistributions of source code must retain the above copyright 801 notice, this list of conditions and the following disclaimer. 803 o Redistributions in binary form must reproduce the above copyright 804 notice, this list of conditions and the following disclaimer in 805 the documentation and/or other materials provided with the 806 distribution. 808 o Neither the name of Internet Society, IETF or IETF Trust, nor the 809 names of specific contributors, may be used to endorse or promote 810 products derived from this software without specific prior written 811 permission. 813 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 814 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 815 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 816 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 817 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 818 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 819 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 820 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 821 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 822 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 823 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 825 BEGIN 826 827 833 834 835 Schema for representing a Trademark, also referred to 836 as Mark. 837 838 840 843 846 849 852 855 857 860 861 862 863 864 866 869 871 872 873 874 876 877 878 879 880 881 882 883 884 885 886 888 889 890 891 892 893 894 895 896 897 898 900 901 902 903 904 906 908 909 911 913 914 915 916 917 918 919 920 922 923 924 925 926 928 930 932 934 935 936 937 938 939 940 942 943 944 945 946 948 950 952 953 954 955 956 958 959 960 962 965 966 967 968 969 970 971 972 973 975 978 979 980 981 982 984 985 987 990 991 992 993 994 996 999 1000 1001 1002 1003 1004 1007 1008 1009 1010 1011 1012 1013 1015 1018 1019 1020 1021 1022 1023 1025 1028 1029 1030 1031 1032 1034 1037 1038 1039 1040 1041 1042 1043 1045 1048 1049 1050 1051 1053 1055 1056 1057 1058 1059 1060 1061 1063 1064 1065 1066 1067 1068 1069 1070 1071 END 1073 4. Implementation Status 1075 Note to RFC Editor: Please remove this section and the reference to 1076 RFC 6982 [RFC6982] before publication. 1078 This section records the status of known implementations of the 1079 format defined by this specification at the time of posting of this 1080 Internet-Draft, and is based on a proposal described in RFC 6982 1081 [RFC6982]. The description of implementations in this section is 1082 intended to assist the IETF in its decision processes in progressing 1083 drafts to RFCs. Please note that the listing of any individual 1084 implementation here does not imply endorsement by the IETF. 1085 Furthermore, no effort has been spent to verify the information 1086 presented here that was supplied by IETF contributors. This is not 1087 intended as, and must not be construed to be, a catalog of available 1088 implementations or their features. Readers are advised to note that 1089 other implementations may exist. 1091 According to RFC 6982 [RFC6982], "this will allow reviewers and 1092 working groups to assign due consideration to documents that have the 1093 benefit of running code, which may serve as evidence of valuable 1094 experimentation and feedback that have made the implemented protocols 1095 more mature. It is up to the individual working groups to use this 1096 information as they see fit". 1098 4.1. Verisign EPP SDK 1100 Organization: Verisign Inc. 1102 Name: Verisign EPP SDK 1104 Description: The Verisign EPP SDK includes both a full client 1105 implementation and a full server stub implementation of draft-ietf- 1106 eppext-tmch-smd. 1108 Level of maturity: Production 1110 Coverage: All aspects of the draft-ietf-eppext-tmch-smd are 1111 implemented. 1113 Licensing: GNU Lesser General Public License 1115 Contact: jgould@verisign.com 1117 URL: http://www.verisigninc.com/en_US/channel-resources/domain- 1118 registry-products/epp-sdks 1120 4.2. Verisign Consolidated Top Level Domain (CTLD) SRS 1122 Organization: Verisign Inc. 1124 Name: Verisign Consolidated Top Level Domain (CTLD) Shared Registry 1125 System (SRS) 1127 Description: The Verisign Consolidated Top Level Domain (CTLD) Shared 1128 Registry System (SRS) implements the server-side of draft-ietf- 1129 eppext-tmch-smd for a variety of Top Level Domains (TLD's). 1131 Level of maturity: Production 1133 Coverage: Implements parsing and validation of all aspects of draft- 1134 ietf-eppext-tmch-smd including the Signed Mark, the Encoded Signed 1135 Mark, and the contained Mark. Implements the encoding of the Mark in 1136 supporting the response of draft-ietf-eppext-launchphase. 1138 Licensing: Proprietary 1140 Contact: jgould@verisign.com 1142 4.3. Verisign .COM / .NET SRS 1144 Organization: Verisign Inc. 1146 Name: Verisign .COM / .NET Shared Registry System (SRS) 1148 Description: The Verisign Shared Registry System (SRS) for .COM, .NET 1149 and other IDN TLD's implements the server-side of draft-ietf-eppext- 1150 tmch-smd. 1152 Level of maturity: Operational Test Environment (OTE) 1154 Coverage: Implements parsing and validation of all aspects of draft- 1155 ietf-eppext-tmch-smd including the Signed Mark, the Encoded Signed 1156 Mark, and the contained Mark. 1158 Licensing: Proprietary 1160 Contact: jgould@verisign.com 1162 4.4. REngin v3.7 1164 Organisation: Domain Name Services (Pty) Ltd 1166 Name: REngin v3.7 1168 Description: Server side implementation only 1170 Level of maturity: Production 1172 Coverage: All aspects of draft-ietf-eppext-tmch-smd have been 1173 implemented 1175 Licensing: Proprietary Licensing with Maintenance Contracts 1177 Contact: info@dnservices.co.za 1179 URL: http://domain-name.services 1181 4.5. Uniregistry Corp. Shared Registry System (uSRS) 1183 Organization: Uniregistry Corp. 1185 Name: Uniregistry Corp. Shared Registry System (uSRS) 1187 Description: Uniregistry's Shared Registry System implements the 1188 server-side of draft-ietf-eppext-tmch-smd for its TLD registry. 1190 Level of maturity: Production 1192 Coverage: Implements parsing and validation of all aspects of draft- 1193 ietf-eppext-tmch-smd including the Signed Mark, the Encoded Signed 1194 Mark, and the contained Mark. Implements the encoding of the Mark in 1195 supporting the response of draft-ietf-eppext-launchphase. 1197 Licensing: Proprietary 1199 Contact: fobispo@uniregistry.link 1201 5. Acknowledgements 1203 Special thanks to Chris Wright for creating the first prototype of a 1204 SMD; James Gould, Wil Tan and Gavin Brown for creating the mark and 1205 SMD definitions in their EPP draft launch extension on which this 1206 draft is based. Portions of the security section were shamefully 1207 copied from RFC5105. Special suggestions that have been incorporated 1208 into this document were provided by Scott Hollenbeck. 1210 6. Change History 1212 [[RFC Editor: Please remove this section.]] 1214 Version draft-ietf-eppext-tmch-smd-02 to version draft-ietf-eppext- 1215 tmch-smd-03 1217 RFC6194 and RFC6982 moved to informative references section. 1219 Version draft-ietf-eppext-tmch-smd-01 to version draft-ietf-eppext- 1220 tmch-smd-02 1222 Security considerations section was updated. 1224 IANA considerations section was updated. 1226 Normative reference added for the ICANN Trademark Clearinghouse 1227 definition document. 1229 Editorial changes. 1231 Version draft-ietf-eppext-tmch-smd-00 to version draft-ietf-eppext- 1232 tmch-smd-01 1234 Implementation Status section added. 1236 Added type to the enconding element. 1238 Version draft-lozano-tmch-smd-03 to version draft-ietf-eppext-tmch- 1239 smd-00 1241 Internet-Draft resubmitted. 1243 Version 02 to version 03 1245 example is now aligned with ICANN test SMDs. 1247 example is replaced with a public ICANN 1248 test SMD. 1250 Several recommendations where added. 1252 Version 01 to version 02 1254 Change apID and regNum of trademark validated mark to token. 1256 Change refNum of treatyOrStatute validated mark to token. 1258 Change refNum of court validated mark to token. 1260 Version 00 to version 01 1262 Add missing email element to holderType. 1264 Change ruling from an attribute to an element. 1266 Version preview-01 to version 00 1268 signedMarkType now ref mark:abstractMark. 1270 Security section completed. 1272 Version preview-00 to preview-01 1274 Full example of an encodedSignedMark added. 1276 signedMark example now fully validates with XSD. 1278 Fixed labelType to allow two-character labels. 1280 Missing mark:protectionType added in the XSD. 1282 Issuer email is now required. 1284 7. IANA Considerations 1286 This document uses URNs to describe XML namespaces and XML schemas 1287 conforming to a registry mechanism described in [RFC3688]. Two URI 1288 assignments have been registered by the IANA. 1290 Registration request for the signed mark namespace: 1292 URI: urn:ietf:params:xml:ns:signedMark-1.0 1294 Registrant Contact: See the "Author's Address" section of this 1295 document. 1297 XML: None. Namespace URIs do not represent an XML specification. 1299 Registration request for the signed mark schema: 1301 URI: urn:ietf:params:xml:schema:signedMark-1.0 1303 Registrant Contact: See the "Author's Address" section of this 1304 document. 1306 XML: See the "Formal Syntax" section of this document. 1308 Registration request for the mark namespace: 1310 URI: urn:ietf:params:xml:ns:mark-1.0 1312 Registrant Contact: See the "Author's Address" section of this 1313 document. 1315 XML: None. Namespace URIs do not represent an XML specification. 1317 Registration request for the mark schema: 1319 URI: urn:ietf:params:xml:schema:mark-1.0 1321 Registrant Contact: See the "Author's Address" section of this 1322 document. 1324 XML: See the "Formal Syntax" section of this document. 1326 8. Security Considerations 1328 The security of a SMD file depends on the security of the underlying 1329 XML DSIG algorithms. As such, all the security considerations from 1330 [XMLDSIG] apply here as well. SMD files generated for the ICANN new 1331 gTLD program use the algorithms for digesting and signing recommended 1332 in this document. 1334 The SMD file is not encrypted. If local policy dictates that the 1335 information contained within the SMD file should be confidential, 1336 then this has to be handled through a different mechanism. 1338 SMD files are used primarily for sunrise domain name registrations in 1339 gTLDs, but other third-parties might be using SMD files. A party 1340 using a SMD file should verify that the SMD file is valid based on 1341 local policy. In the case of gTLDs, the RPM Requirements 1342 [ICANN-TMCH] defines such policy. 1344 9. References 1346 9.1. Normative References 1348 [ICANN-TMCH] 1349 ICANN, "ICANN Trademark Clearinghouse, Rights Protection 1350 Mechanism Requirements", 2013, 1351 . 1354 [ISO3166-2] 1355 ISO, "International Standard for country codes and codes 1356 for their subdivisions", 2006, 1357 . 1359 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1360 Extensions (MIME) Part One: Format of Internet Message 1361 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 1362 . 1364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1365 Requirement Levels", BCP 14, RFC 2119, 1366 DOI 10.17487/RFC2119, March 1997, 1367 . 1369 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1370 DOI 10.17487/RFC3688, January 2004, 1371 . 1373 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1374 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1375 . 1377 [RFC5890] Klensin, J., "Internationalized Domain Names for 1378 Applications (IDNA): Definitions and Document Framework", 1379 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1380 . 1382 [WIPO-NICE-CLASSES] 1383 WIPO, "WIPO Nice Classification", 2015, 1384 . 1386 [WIPO.ST3] 1387 WIPO, "Recommended standard on two-letter codes for the 1388 representation of states, other entities and 1389 intergovernmental organizations", March 2007, 1390 . 1392 [XMLC14N] W3C Recommendation, "Exclusive XML Canonicalization 1393 Version 1.0", 2002, 1394 . 1396 [XMLDSIG] W3C Recommendation, "XML Signature Syntax and Processing 1397 (Second Edition)", 2008, 1398 . 1400 9.2. Informative References 1402 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 1403 Considerations for the SHA-0 and SHA-1 Message-Digest 1404 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 1405 . 1407 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1408 Code: The Implementation Status Section", RFC 6982, 1409 DOI 10.17487/RFC6982, July 2013, 1410 . 1412 Author's Address 1413 Gustavo Lozano 1414 ICANN 1415 12025 Waterfront Drive, Suite 300 1416 Los Angeles 90292 1417 US 1419 Phone: +1.3103015800 1420 Email: gustavo.lozano@icann.org