summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7848.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7848.txt')
-rw-r--r--doc/rfc/rfc7848.txt1347
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc7848.txt b/doc/rfc/rfc7848.txt
new file mode 100644
index 0000000..a874f16
--- /dev/null
+++ b/doc/rfc/rfc7848.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) G. Lozano
+Request for Comments: 7848 ICANN
+Category: Standards Track June 2016
+ISSN: 2070-1721
+
+
+ Mark and Signed Mark Objects Mapping
+
+Abstract
+
+ Domain Name Registries (DNRs) may operate in special modes for
+ certain periods of time, enabling trademark holders to protect their
+ rights during the introduction of a Top-Level Domain (TLD).
+
+ One of those special modes of operation is the Sunrise Period. The
+ Sunrise Period allows trademark holders an advance opportunity to
+ register domain names corresponding to their trademarks before names
+ are generally available to the public.
+
+ This document describes the format of a mark and a digitally signed
+ mark used by trademark holders for registering domain names during
+ the Sunrise Period of generic Top-Level Domains (gTLDs). Three types
+ of Mark objects are defined in this specification: registered
+ trademarks, court-validated marks, and marks protected by statue or
+ treaty.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7848.
+
+
+
+
+
+
+
+
+
+
+
+
+Lozano Standards Track [Page 1]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+Copyright Notice
+
+ Copyright (c) 2016 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Object Description . . . . . . . . . . . . . . . . . . . . . 4
+ 2.1. Holder and Contact Objects . . . . . . . . . . . . . . . 5
+ 2.2. Mark . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.3. Signed Mark . . . . . . . . . . . . . . . . . . . . . . . 10
+ 2.4. Encoded Signed Mark . . . . . . . . . . . . . . . . . . . 13
+ 3. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 3.1. Signed Mark Schema . . . . . . . . . . . . . . . . . . . 14
+ 3.2. Mark Schema . . . . . . . . . . . . . . . . . . . . . . . 15
+ 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 6.1. Normative References . . . . . . . . . . . . . . . . . . 22
+ 6.2. Informative References . . . . . . . . . . . . . . . . . 24
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lozano Standards Track [Page 2]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+1. Introduction
+
+ Domain Name Registries (DNRs) may operate in special modes for
+ certain periods of time enabling trademark holders to protect their
+ rights during the introduction of a Top-Level Domain (TLD).
+
+ One of those special modes of operation is the Sunrise Period. The
+ Sunrise Period allows trademark holders an advance opportunity to
+ register domain names corresponding to their trademarks before names
+ are generally available to the public.
+
+ This specification was defined as part of the development of the
+ ICANN Trademark Clearinghouse (TMCH). The ICANN TMCH is a global
+ repository for trademark data used by DNRs, registrars, and trademark
+ holders during the registration process of domain names.
+
+ This document describes a mapping of the common elements found in
+ trademark data. A digitally signed mark format is defined in order
+ to support digital signatures on the mark. Finally, a mapping for
+ encoding the signed mark document is defined.
+
+ Three types of Mark objects are defined in this specification:
+ registered trademarks, court-validated marks, and marks protected by
+ statue or treaty.
+
+ This specification is intended to be used in the gTLD space, but
+ nothing precludes the use of this format by other entities.
+
+ The detailed policy regarding the public key infrastructure (PKI),
+ authorized validators, and other requirements must be defined based
+ on the local policy of the entities using this specification. In the
+ case of gTLDs, the detailed policy regarding the use of this
+ specification is defined in the Rights Protection Mechanism
+ Requirements document (see [ICANN-TMCH]), and the PKI is defined in
+ [TMCH]. Implementations will need to implement such a PKI (or an
+ equivalent) in order for the signatures defined in this document to
+ have any useful semantics.
+
+ The objects specified in this document can be referenced by
+ application protocols like the Extensible Provisioning Protocol
+ (EPP), defined in [RFC5730].
+
+
+
+
+
+
+
+
+
+
+Lozano Standards Track [Page 3]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+1.1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+ XML (EXtensible Markup Language) is case sensitive. Unless stated
+ otherwise, XML specifications and examples provided in this document
+ MUST be interpreted in the character case presented in order to
+ develop a conforming implementation.
+
+ "signedMark-1.0" is used as an abbreviation for
+ "urn:ietf:params:xml:ns:signedMark-1.0". The XML namespace prefix
+ "smd" is used, but implementations MUST NOT depend on it and instead
+ employ a proper namespace-aware XML parser and serializer to
+ interpret and output the XML documents.
+
+ "mark-1.0" is used as an abbreviation for
+ "urn:ietf:params:xml:ns:mark-1.0". The XML namespace prefix "mark"
+ is used, but implementations MUST NOT depend on it and instead employ
+ a proper namespace-aware XML parser and serializer to interpret and
+ output the XML documents.
+
+2. Object Description
+
+ This section defines the Mark and Signed Mark objects. Empty complex
+ element types and abstract elements are defined to support additional
+ definitions using XML schema substitution groups. Support for
+ replacement through the XML schema substitution groups is included in
+ the description of the objects.
+
+ This section defines some elements as OPTIONAL. If an element is not
+ defined as OPTIONAL, then it MUST be included in the object.
+
+ The following elements are defined as telephone numbers:
+ <mark:voice>, <mark:fax>, and <smd:voice>. The representation of
+ telephone numbers in this specification is derived from structures
+ defined in [ITU.E164.2005]. Telephone numbers described in this
+ mapping are character strings that MUST begin with a plus sign ("+",
+ ASCII value 0x002B), followed by a country code defined in
+ [ITU.E164.2005], followed by a dot (".", ASCII value 0x002E),
+ followed by a sequence of digits representing the telephone number.
+ An optional "x" attribute is provided to note telephone extension
+ information.
+
+ The following elements are defined as email addresses: <mark:email>
+ and <smd:email>. Email address syntax is defined in [RFC5322].
+
+
+
+
+Lozano Standards Track [Page 4]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+2.1. Holder and Contact Objects
+
+ Marks are linked to Holder objects and optionally linked to Contact
+ objects. This section defines the <mark:holder> and <mark:contact>
+ objects.
+
+ o The child elements of <mark:holder> include:
+
+ * A <mark:name> element that contains the name of the individual
+ holder of the mark. At least one of <mark:name> and <mark:org>
+ MUST be specified, and <mark:name> is OPTIONAL if <mark:org> is
+ specified.
+
+ * A <mark:org> element that contains the name of the organization
+ holder of the mark. At least one of <mark:name> and <mark:org>
+ MUST be specified, and <mark:org> is OPTIONAL if <mark:name> is
+ specified.
+
+ * A <mark:addr> element that contains the address information of
+ the holder of a mark. A <mark:addr> contains the following
+ child elements:
+
+ + One, two, or three OPTIONAL <mark:street> elements that
+ contain the holder's street address.
+
+ + A <mark:city> element that contains the holder's city.
+
+ + An OPTIONAL <mark:sp> element that contains the holder's
+ state or province.
+
+ + An OPTIONAL <mark:pc> element that contains the holder's
+ postal code.
+
+ + A <mark:cc> element that contains the holder's country code.
+ This is a two-character code from [ISO3166-2].
+
+ * An OPTIONAL <mark:voice> element that contains the holder's
+ voice telephone number.
+
+ * An OPTIONAL <mark:fax> element that contains the holder's
+ facsimile telephone number.
+
+ * An OPTIONAL <mark:email> element that contains the email
+ address of the holder.
+
+
+
+
+
+
+
+Lozano Standards Track [Page 5]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+ o The child elements of <mark:contact> include:
+
+ * A <mark:name> element that contains the name of the responsible
+ person.
+
+ * An OPTIONAL <mark:org> element that contains the name of the
+ organization of the contact.
+
+ * A <mark:addr> element that contains the address information of
+ the contact. A <mark:addr> contains the following child
+ elements:
+
+ + One, two, or three OPTIONAL <mark:street> elements that
+ contain the contact's street address.
+
+ + A <mark:city> element that contains the contact's city.
+
+ + An OPTIONAL <mark:sp> element that contains the contact's
+ state or province.
+
+ + An OPTIONAL <mark:pc> element that contains the contact's
+ postal code.
+
+ + A <mark:cc> element that contains the contact's country
+ code. This is a two-character code from [ISO3166-2].
+
+ * A <mark:voice> element that contains the contact's voice
+ telephone number.
+
+ * An OPTIONAL <mark:fax> element that contains the contact's
+ facsimile telephone number.
+
+ * A <mark:email> element that contains the contact's email
+ address.
+
+2.2. Mark
+
+ A <mark:mark> element that describes an applicant's prior right to a
+ given domain name.
+
+ A <mark:mark> element substitutes for the <mark:abstractMark>
+ abstract element to define a concrete definition of a mark. The
+ <mark:abstractMark> element can be replaced by other mark definitions
+ using the XML schema substitution groups feature.
+
+
+
+
+
+
+
+Lozano Standards Track [Page 6]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+ The child elements of the <mark:mark> element include:
+
+ One or more <mark:trademark>, <mark:treatyOrStatute>, and
+ <mark:court> elements that contain the detailed information of marks.
+
+ o A <mark:trademark> element that contains the following child
+ elements:
+
+ * A <mark:id> that uniquely identifies a mark in relation to a
+ repository of marks potentially maintained by more than one
+ issuer. A <mark:id> value is a concatenation of the local
+ identifier, followed by a hyphen ("-", ASCII value 0x002D),
+ followed by the issuer identifier.
+
+ * A <mark:markName> element that contains the mark text string.
+
+ * One or more <mark:holder> elements that contain the information
+ of the holder of the mark. An "entitlement" attribute is used
+ to identify the entitlement of the holder; possible values are
+ "owner", "assignee", and "licensee".
+
+ * Zero or more OPTIONAL <mark:contact> elements that contain the
+ information of the representative of the mark registration. A
+ "type" attribute is used to identify the type of contact;
+ possible values are "owner", "agent", or "thirdparty".
+
+ * A <mark:jurisdiction> element that contains the two-character
+ code of the jurisdiction where the trademark was registered.
+ This is a two-character code from [WIPO.ST3].
+
+ * Zero or more OPTIONAL <mark:class> elements that contain the
+ World Intellectual Property Organization (WIPO) Nice
+ Classification class numbers of the mark as defined in the WIPO
+ Nice Classification [WIPO-NICE-CLASSES].
+
+ * Zero or more OPTIONAL <mark:label> elements that contain the
+ A-label form (as defined in [RFC5890]) of the label that
+ corresponds to the <mark:markName>.
+
+ * A <mark:goodsAndServices> element that contains the full
+ description of the goods and services from the document
+ certifying the registration of the mark.
+
+ * An OPTIONAL <mark:apId> element that contains the trademark
+ application ID registered in the trademark office.
+
+ * An OPTIONAL <mark:apDate> element that contains the date the
+ trademark was applied for.
+
+
+
+Lozano Standards Track [Page 7]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+ * A <mark:regNum> element that contains the trademark
+ registration number registered in the trademark office.
+
+ * A <mark:regDate> element that contains the date the trademark
+ was registered.
+
+ * An OPTIONAL <mark:exDate> element that contains the expiration
+ date of the trademark.
+
+ o A <mark:treatyOrStatute> element that contains the following child
+ elements:
+
+ * A <mark:id> element; see definition in the <mark:trademark>
+ section above.
+
+ * A <mark:markName> element; see definition in the
+ <mark:trademark> section above.
+
+ * One or more <mark:holder> elements; see definition in the
+ <mark:trademark> section above.
+
+ * Zero or more OPTIONAL <mark:contact> elements; see definition
+ in the <mark:trademark> section above.
+
+ * One or more <mark:protection> elements that contain the
+ countries and region of the country where the mark is
+ protected. The <mark:protection> element contains the
+ following child elements:
+
+ + A <mark:cc> element that contains the two-character code of
+ the country in which the mark is protected. This is a two-
+ character code from [ISO3166-2].
+
+ + An OPTIONAL <mark:region> element that contains the name of
+ a city, state, province, or other geographic region of
+ <mark:country> in which the mark is protected.
+
+ + Zero or more OPTIONAL <mark:ruling> elements that contain
+ the two-character code of the national territory in which
+ the statute or treaty is applicable. This is a two-
+ character code from [ISO3166-2].
+
+ + Zero or more OPTIONAL <mark:label> elements; see definition
+ in the <mark:trademark> section above.
+
+ * A <mark:goodsAndServices> element; see definition in the
+ <mark:trademark> section above.
+
+
+
+
+Lozano Standards Track [Page 8]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+ * A <mark:refNum> element that contains the serial number of the
+ mark.
+
+ * A <mark:proDate> element that contains the date of protection
+ of the mark.
+
+ * A <mark:title> element that contains the title of the treaty or
+ statute.
+
+ * A <mark:execDate> element that contains the execution date of
+ the treaty or statute.
+
+ o A <mark:court> element that contains the following child elements:
+
+ * A <mark:id> element; see definition in the <mark:trademark>
+ section above.
+
+ * A <mark:markName> element; see definition in the
+ <mark:trademark> section above.
+
+ * One or more <mark:holder> elements; see definition in the
+ <mark:trademark> section above.
+
+ * Zero or more OPTIONAL <mark:contact> elements; see definition
+ in the <mark:trademark> section above.
+
+ * Zero or more OPTIONAL <mark:label> elements; see definition in
+ the <mark:trademark> section above.
+
+ * A <mark:goodsAndServices> element; see definition in the
+ <mark:trademark> section above.
+
+ * A <mark:refNum> element that contains the reference number of
+ the court's opinion.
+
+ * A <mark:proDate> element that contains the date of protection
+ of the mark.
+
+ * A <mark:cc> element that contains the two-character code of the
+ country where the court is located. This is a two-character
+ code from [ISO3166-2].
+
+ * Zero or more OPTIONAL <mark:region> elements that contain the
+ name of a city, state, province, or other geographic region of
+ <mark:cc> in which the mark is protected. In case
+ <mark:region> is specified, a default-deny approach MUST be
+ assumed regarding the regions of a country.
+
+
+
+
+Lozano Standards Track [Page 9]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+ * A <mark:courtName> element that contains the name of the court.
+
+2.3. Signed Mark
+
+ The <smd:signedMark> is a digitally signed XML document using an XML
+ Signature [XMLDSIG]. The <smd:signedMark> XML document (SMD)
+ includes a required "id" attribute of type XML Schema Definition
+ (XSD) ID for use with an IDREF URI from the Signature element. The
+ SMD might be transmitted as part of a protocol already based on XML;
+ therefore, exclusive XML canonicalization as defined in [XMLC14N]
+ MUST be used.
+
+ A <smd:signedMark> element substitutes for the
+ <smd:abstractSignedMark> abstract element to define a concrete
+ definition of a signed mark. The <smd:abstractSignedMark> element
+ can be replaced by other signed mark definitions using the XML schema
+ substitution groups feature.
+
+ The child elements of the <smd:signedMark> element include:
+
+ o The <smd:id> element that uniquely identifies an SMD in relation
+ to a repository of SMDs potentially maintained by more than one
+ issuer. The <smd:id> value is a concatenation of the local
+ identifier, followed by a hyphen ("-", ASCII value 0x002D),
+ followed by the issuer identifier.
+
+ o A <smd:issuerInfo> element that contains the information of the
+ issuer of the mark registration. An "issuerID" attribute is used
+ to specify the issuer identifier. The child elements include:
+
+ * A <smd:org> element that contains the organization name of the
+ issuer.
+
+ * A <smd:email> element that contains the issuer customer support
+ email address.
+
+ * An OPTIONAL <smd:url> element that contains the HTTP or HTTPS
+ URL of the issuer's site.
+
+ * An OPTIONAL <smd:voice> element that contains the issuer's
+ voice telephone number.
+
+ o A <smd:notBefore> element that contains the creation date and time
+ of the SMD.
+
+ o A <smd:notAfter> element that contains the expiration date and
+ time of the SMD.
+
+
+
+
+Lozano Standards Track [Page 10]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+ o A <mark:mark> element that contains the mark information as
+ defined in Section 2.2.
+
+ The following is an example of an SMD:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <smd:signedMark xmlns:smd="urn:ietf:params:xml:ns:signedMark-1.0"
+ id="smd1">
+ <smd:id>0000001751376056503931-65535</smd:id>
+ <smd:issuerInfo issuerID="65535">
+ <smd:org>ICANN TMCH TESTING TMV</smd:org>
+ <smd:email>notavailable@example.com</smd:email>
+ <smd:url>https://www.example.com</smd:url>
+ <smd:voice>+32.000000</smd:voice>
+ </smd:issuerInfo>
+ <smd:notBefore>2013-08-09T13:55:03.931Z</smd:notBefore>
+ <smd:notAfter>2017-07-23T22:00:00.000Z</smd:notAfter>
+ <mark:mark xmlns:mark="urn:ietf:params:xml:ns:mark-1.0">
+ <mark:trademark>
+ <mark:id>00052013734689731373468973-65535</mark:id>
+ <mark:markName>Test &amp; Validate</mark:markName>
+ <mark:holder entitlement="owner">
+ <mark:org>Ag corporation</mark:org>
+ <mark:addr>
+ <mark:street>1305 Bright Avenue</mark:street>
+ <mark:city>Arcadia</mark:city>
+ <mark:sp>CA</mark:sp>
+ <mark:pc>90028</mark:pc>
+ <mark:cc>US</mark:cc>
+ </mark:addr>
+ </mark:holder>
+ <mark:contact type="agent">
+ <mark:name>Tony Holland</mark:name>
+ <mark:org>Ag corporation</mark:org>
+ <mark:addr>
+ <mark:street>1305 Bright Avenue</mark:street>
+ <mark:city>Arcadia</mark:city>
+ <mark:sp>CA</mark:sp>
+ <mark:pc>90028</mark:pc>
+ <mark:cc>US</mark:cc>
+ </mark:addr>
+ <mark:voice>+1.2025562302</mark:voice>
+ <mark:fax>+1.2025562301</mark:fax>
+ <mark:email>info@agcorporation.com</mark:email>
+ </mark:contact>
+ <mark:jurisdiction>US</mark:jurisdiction>
+ <mark:class>15</mark:class>
+ <mark:label>testandvalidate</mark:label>
+
+
+
+Lozano Standards Track [Page 11]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+ <mark:label>test---validate</mark:label>
+ <mark:label>testand-validate</mark:label>
+ <mark:label>test-et-validate</mark:label>
+ <mark:label>test-validate</mark:label>
+ <mark:label>test--validate</mark:label>
+ <mark:label>test-etvalidate</mark:label>
+ <mark:label>testetvalidate</mark:label>
+ <mark:label>testvalidate</mark:label>
+ <mark:label>testet-validate</mark:label>
+ <mark:goodsAndServices>guitar</mark:goodsAndServices>
+ <mark:regNum>1234</mark:regNum>
+ <mark:regDate>2012-12-31T23:00:00.000Z</mark:regDate>
+ </mark:trademark>
+ </mark:mark>
+ <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
+ <SignedInfo>
+ <CanonicalizationMethod
+ Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
+ <SignatureMethod
+ Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
+ <Reference URI="#smd1">
+ <Transforms>
+ <Transform
+ Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
+ </Transforms>
+ <DigestMethod
+ Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
+ <DigestValue>wgyW3nZPoEfpptlhRILKnOQnbdtU6ArM7ShrAfHgDFg=</DigestValue>
+ </Reference>
+ </SignedInfo>
+ <SignatureValue>
+ jMu4PfyQGiJBF0GWSEPFCJjmywCEqR2h4LD+ge6XQ+JnmKFFCuCZS/3SLKAx0L1w
+ QDFO2e0Y69k2G7/LGE37X3vOflobFM1oGwja8+GMVraoto5xAd4/AF7eHukgAymD
+ o9toxoa2h0yV4A4PmXzsU6S86XtCcUE+S/WM72nyn47zoUCzzPKHZBRyeWehVFQ+
+ jYRMIAMzM57HHQA+6eaXefRvtPETgUO4aVIVSugc4OUAZZwbYcZrC6wOaQqqqAZi
+ 30aPOBYbAvHMSmWSS+hFkbshomJfHxb97TD2grlYNrQIzqXk7WbHWy2SYdA+sI/Z
+ ipJsXNa6osTUw1CzA7jfwA==
+ </SignatureValue>
+ <KeyInfo>
+ <X509Data>
+ <X509Certificate>
+ MIIESTCCAzGgAwIBAgIBAjANBgkqhkiG9w0BAQsFADBiMQswCQYDVQQGEwJVUzEL
+ MAkGA1UECBMCQ0ExFDASBgNVBAcTC0xvcyBBbmdlbGVzMRMwEQYDVQQKEwpJQ0FO
+ TiBUTUNIMRswGQYDVQQDExJJQ0FOTiBUTUNIIFRFU1QgQ0EwHhcNMTMwMjA4MDAw
+ MDAwWhcNMTgwMjA3MjM1OTU5WjBsMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0Ex
+ FDASBgNVBAcTC0xvcyBBbmdlbGVzMRcwFQYDVQQKEw5WYWxpZGF0b3IgVE1DSDEh
+ MB8GA1UEAxMYVmFsaWRhdG9yIFRNQ0ggVEVTVCBDRVJUMIIBIjANBgkqhkiG9w0B
+ AQEFAAOCAQ8AMIIBCgKCAQEAo/cwvXhbVYl0RDWWvoyeZpETVZVVcMCovUVNg/sw
+
+
+
+Lozano Standards Track [Page 12]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+ WinuMgEWgVQFrz0xA04pEhXCFVv4evbUpekJ5buqU1gmQyOsCKQlhOHTdPjvkC5u
+ pDqa51Flk0TMaMkIQjs7aUKCmA4RG4tTTGK/EjR1ix8/D0gHYVRldy1YPrMP+ou7
+ 5bOVnIos+HifrAtrIv4qEqwLL4FTZAUpaCa2BmgXfy2CSRQbxD5Or1gcSa3vurh5
+ sPMCNxqaXmIXmQipS+DuEBqMM8tldaN7RYojUEKrGVsNk5i9y2/7sjn1zyyUPf7v
+ L4GgDYqhJYWV61DnXgx/Jd6CWxvsnDF6scscQzUTEl+hywIDAQABo4H/MIH8MAwG
+ A1UdEwEB/wQCMAAwHQYDVR0OBBYEFPZEcIQcD/Bj2IFz/LERuo2ADJviMIGMBgNV
+ HSMEgYQwgYGAFO0/7kEh3FuEKS+Q/kYHaD/W6wihoWakZDBiMQswCQYDVQQGEwJV
+ UzELMAkGA1UECBMCQ0ExFDASBgNVBAcTC0xvcyBBbmdlbGVzMRMwEQYDVQQKEwpJ
+ Q0FOTiBUTUNIMRswGQYDVQQDExJJQ0FOTiBUTUNIIFRFU1QgQ0GCAQEwDgYDVR0P
+ AQH/BAQDAgeAMC4GA1UdHwQnMCUwI6AhoB+GHWh0dHA6Ly9jcmwuaWNhbm4ub3Jn
+ L3RtY2guY3JsMA0GCSqGSIb3DQEBCwUAA4IBAQB2qSy7ui+43cebKUKwWPrzz9y/
+ IkrMeJGKjo40n+9uekaw3DJ5EqiOf/qZ4pjBD++oR6BJCb6NQuQKwnoAz5lE4Ssu
+ y5+i93oT3HfyVc4gNMIoHm1PS19l7DBKrbwbzAea/0jKWVzrvmV7TBfjxD3AQo1R
+ bU5dBr6IjbdLFlnO5x0G0mrG7x5OUPuurihyiURpFDpwH8KAH1wMcCpXGXFRtGKk
+ wydgyVYAty7otkl/z3bZkCVT34gPvF70sR6+QxUy8u0LzF5A/beYaZpxSYG31amL
+ AdXitTWFipaIGea9lEGFM0L9+Bg7XzNn4nVLXokyEB3bgS4scG6QznX23FGk
+ </X509Certificate>
+ </X509Data>
+ </KeyInfo>
+ </Signature>
+ </smd:signedMark>
+
+ NOTE: The example shown above includes white space for indentation
+ purposes. It is RECOMMENDED that SMDs do not include white space
+ between the XML elements, in order to mitigate risks of invalidating
+ the digital signature when transferring of SMDs between applications
+ takes place.
+
+2.4. Encoded Signed Mark
+
+ The <smd:encodedSignedMark> element contains an encoded form of an
+ SMD (described in Section 2.3), with the encoding defined by the
+ "encoding" attribute with the default "encoding" value of "base64"
+ [RFC4648].
+
+ The following is an example of a <smd:encodedSignedMark> element that
+ uses the default "base64" for encoding a <smd:signedMark> element.
+
+ <smd:encodedSignedMark
+ xmlns:smd="urn:ietf:params:xml:ns:signedMark-1.0">
+ PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNtZDpzaWduZWRNYXJ
+ rIHhtbG5zOnNtZD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpzaWduZWRNYXJrLTEuMCIgaW
+ ... (base64 data elided for brevity) ...
+ PC9zbWQ6c2lnbmVkTWFyaz4=
+ </smd:encodedSignedMark>
+
+
+
+
+
+
+Lozano Standards Track [Page 13]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+3. Formal Syntax
+
+ Two schemas are presented here. The first schema is the schema for
+ the Signed Mark object. The second schema is the schema for the Mark
+ object.
+
+ The formal syntax presented here is a complete schema representation
+ of the object mapping suitable for automated validation of EPP XML
+ instances. The BEGIN and END tags are not part of the schema; they
+ are used to note the beginning and ending of the schema for URI
+ registration purposes.
+
+3.1. Signed Mark Schema
+
+ BEGIN
+ <?xml version="1.0" encoding="UTF-8"?>
+ <schema
+ targetNamespace="urn:ietf:params:xml:ns:signedMark-1.0"
+ xmlns:smd="urn:ietf:params:xml:ns:signedMark-1.0"
+ xmlns:mark="urn:ietf:params:xml:ns:mark-1.0"
+ xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
+ xmlns="http://www.w3.org/2001/XMLSchema"
+ elementFormDefault="qualified">
+
+ <annotation>
+ <documentation>
+ Schema for representing a Signed Mark object.
+ </documentation>
+ </annotation>
+
+ <import namespace="urn:ietf:params:xml:ns:mark-1.0" />
+ <import namespace="http://www.w3.org/2000/09/xmldsig#" />
+
+ <!--
+ Abstract Signed Mark object for replacement via substitution.
+ -->
+ <element name="abstractSignedMark" type="smd:abstractSignedMarkType"
+ abstract="true"/>
+
+ <!--
+ Empty type for use in extending for a Signed Mark object.
+ -->
+ <complexType name="abstractSignedMarkType"/>
+
+ <element name="signedMark" type="smd:signedMarkType"
+ substitutionGroup="smd:abstractSignedMark"/>
+
+ <element name="encodedSignedMark" type="smd:encodedSignedMarkType"/>
+
+
+
+Lozano Standards Track [Page 14]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+ <complexType name="signedMarkType">
+ <complexContent>
+ <extension base="smd:abstractSignedMarkType">
+ <sequence>
+ <element name="id" type="mark:idType"/>
+ <element name="issuerInfo" type="smd:issuerInfoType"/>
+ <element name="notBefore" type="dateTime"/>
+ <element name="notAfter" type="dateTime"/>
+ <element ref="mark:abstractMark"/>
+ <element ref="dsig:Signature"/>
+ </sequence>
+ <attribute name="id" type="ID" use="required"/>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <complexType name="issuerInfoType">
+ <sequence>
+ <element name="org" type="token"/>
+ <element name="email" type="mark:minTokenType"/>
+ <element name="url" type="token" minOccurs="0"/>
+ <element name="voice" type="mark:e164Type" minOccurs="0"/>
+ </sequence>
+ <attribute name="issuerID" type="token" use="required"/>
+ </complexType>
+
+ <complexType name="encodedSignedMarkType">
+ <simpleContent>
+ <extension base="token">
+ <attribute name="encoding" type="token" default="base64"/>
+ </extension>
+ </simpleContent>
+ </complexType>
+ </schema>
+ END
+
+3.2. Mark Schema
+
+ BEGIN
+ <?xml version="1.0" encoding="UTF-8"?>
+ <schema
+ targetNamespace="urn:ietf:params:xml:ns:mark-1.0"
+ xmlns:mark="urn:ietf:params:xml:ns:mark-1.0"
+ xmlns="http://www.w3.org/2001/XMLSchema"
+ elementFormDefault="qualified">
+
+ <annotation>
+ <documentation>
+
+
+
+Lozano Standards Track [Page 15]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+ Schema for representing a Trademark, also referred to
+ as Mark.
+ </documentation>
+ </annotation>
+
+ <!--
+ Abstract Mark object for replacement via substitution.
+ -->
+ <element name="abstractMark" type="mark:abstractMarkType"
+ abstract="true"/>
+
+ <!--
+ <mark:mark> element definition
+ -->
+ <element name="mark" type="mark:markType"
+ substitutionGroup="mark:abstractMark"/>
+
+ <!--
+ Empty type for use in extending for a Mark object.
+ -->
+ <complexType name="abstractMarkType"/>
+
+ <!--
+ <mark:mark> child elements
+ -->
+ <complexType name="markType">
+ <complexContent>
+ <extension base="mark:abstractMarkType">
+ <sequence>
+ <element name="trademark" type="mark:trademarkType"
+ minOccurs="0" maxOccurs="unbounded"/>
+ <element name="treatyOrStatute"
+ type="mark:treatyOrStatuteType" minOccurs="0"
+ maxOccurs="unbounded"/>
+ <element name="court" type="mark:courtType" minOccurs="0"
+ maxOccurs="unbounded"/>
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <complexType name="holderType">
+ <sequence>
+ <element name="name" type="token" minOccurs="0"/>
+ <element name="org" type="token" minOccurs="0"/>
+ <element name="addr" type="mark:addrType"/>
+ <element name="voice" type="mark:e164Type" minOccurs="0"/>
+ <element name="fax" type="mark:e164Type" minOccurs="0"/>
+
+
+
+Lozano Standards Track [Page 16]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+ <element name="email" type="mark:minTokenType" minOccurs="0"/>
+ </sequence>
+ <attribute name="entitlement" type="mark:entitlementType"/>
+ </complexType>
+
+ <complexType name="contactType">
+ <sequence>
+ <element name="name" type="token"/>
+ <element name="org" type="token" minOccurs="0"/>
+ <element name="addr" type="mark:addrType"/>
+ <element name="voice" type="mark:e164Type"/>
+ <element name="fax" type="mark:e164Type" minOccurs="0"/>
+ <element name="email" type="mark:minTokenType"/>
+ </sequence>
+ <attribute name="type" type="mark:contactTypeType"/>
+ </complexType>
+
+ <complexType name="trademarkType">
+ <sequence>
+ <element name="id" type="mark:idType"/>
+ <element name="markName" type="token"/>
+ <element name="holder" type="mark:holderType"
+ maxOccurs="unbounded" />
+ <element name="contact" type="mark:contactType" minOccurs="0"
+ maxOccurs="unbounded"/>
+ <element name="jurisdiction" type="mark:ccType"/>
+ <element name="class" type="integer" minOccurs="0"
+ maxOccurs="unbounded"/>
+ <element name="label" type="mark:labelType" minOccurs="0"
+ maxOccurs="unbounded"/>
+ <element name="goodsAndServices" type="token" />
+ <element name="apId" type="token" minOccurs="0"/>
+ <element name="apDate" type="dateTime" minOccurs="0"/>
+ <element name="regNum" type="token"/>
+ <element name="regDate" type="dateTime"/>
+ <element name="exDate" type="dateTime" minOccurs="0"/>
+ </sequence>
+ </complexType>
+
+ <complexType name="treatyOrStatuteType">
+ <sequence>
+ <element name="id" type="mark:idType"/>
+ <element name="markName" type="token"/>
+ <element name="holder" type="mark:holderType"
+ maxOccurs="unbounded" />
+ <element name="contact" type="mark:contactType" minOccurs="0"
+ maxOccurs="unbounded"/>
+ <element name="protection" type="mark:protectionType"
+
+
+
+Lozano Standards Track [Page 17]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+ maxOccurs="unbounded"/>
+ <element name="label" type="mark:labelType" minOccurs="0"
+ maxOccurs="unbounded"/>
+ <element name="goodsAndServices" type="token" />
+ <element name="refNum" type="token"/>
+ <element name="proDate" type="dateTime"/>
+ <element name="title" type="token"/>
+ <element name="execDate" type="dateTime"/>
+ </sequence>
+ </complexType>
+
+ <complexType name="courtType">
+ <sequence>
+ <element name="id" type="mark:idType"/>
+ <element name="markName" type="token"/>
+ <element name="holder" type="mark:holderType"
+ maxOccurs="unbounded" />
+ <element name="contact" type="mark:contactType" minOccurs="0"
+ maxOccurs="unbounded"/>
+ <element name="label" type="mark:labelType" minOccurs="0"
+ maxOccurs="unbounded"/>
+ <element name="goodsAndServices" type="token" />
+ <element name="refNum" type="token"/>
+ <element name="proDate" type="dateTime"/>
+ <element name="cc" type="mark:ccType"/>
+ <element name="region" type="token" minOccurs="0"
+ maxOccurs="unbounded"/>
+ <element name="courtName" type="token"/>
+ </sequence>
+ </complexType>
+
+ <!--
+ Address (<mark:addr>) child elements
+ -->
+ <complexType name="addrType">
+ <sequence>
+ <element name="street" type="token" minOccurs="1" maxOccurs="3"/>
+ <element name="city" type="token"/>
+ <element name="sp" type="token" minOccurs="0"/>
+ <element name="pc" type="mark:pcType" minOccurs="0"/>
+ <element name="cc" type="mark:ccType"/>
+ </sequence>
+ </complexType>
+
+ <!--
+ <mark:protection> child elements
+ -->
+ <complexType name="protectionType">
+
+
+
+Lozano Standards Track [Page 18]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+ <sequence>
+ <element name="cc" type="mark:ccType"/>
+ <element name="region" type="token" minOccurs="0"/>
+ <element name="ruling" type="mark:ccType"
+ minOccurs="0" maxOccurs="unbounded"/>
+ </sequence>
+ </complexType>
+
+ <!--
+ Postal code definition
+ -->
+ <simpleType name="pcType">
+ <restriction base="token">
+ <maxLength value="16"/>
+ </restriction>
+ </simpleType>
+
+ <!--
+ Country code definition
+ -->
+ <simpleType name="ccType">
+ <restriction base="token">
+ <length value="2"/>
+ </restriction>
+ </simpleType>
+
+ <!--
+ Phone number with extension definition
+ -->
+ <complexType name="e164Type">
+ <simpleContent>
+ <extension base="mark:e164StringType">
+ <attribute name="x" type="token"/>
+ </extension>
+ </simpleContent>
+ </complexType>
+
+ <!--
+ Phone number with extension definition
+ -->
+ <simpleType name="e164StringType">
+ <restriction base="token">
+ <pattern value="(\+[0-9]{1,3}\.[0-9]{1,14})?"/>
+ <maxLength value="17"/>
+ </restriction>
+ </simpleType>
+
+ <!--
+
+
+
+Lozano Standards Track [Page 19]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+ Id type definition
+ -->
+ <simpleType name="idType">
+ <restriction base="token">
+ <pattern value="\d+-\d+"/>
+ </restriction>
+ </simpleType>
+
+ <!--
+ DNS label type definition
+ -->
+ <simpleType name="labelType">
+ <restriction base="token">
+ <minLength value="1"/>
+ <maxLength value="63"/>
+ <pattern value="[a-zA-Z0-9]([a-zA-Z0-9\-]*[a-zA-Z0-9])?"/>
+ </restriction>
+ </simpleType>
+
+ <!--
+ Type used for email addresses
+ -->
+ <simpleType name="minTokenType">
+ <restriction base="token">
+ <minLength value="1"/>
+ </restriction>
+ </simpleType>
+
+ <simpleType name="entitlementType">
+ <restriction base="token">
+ <enumeration value="owner"/>
+ <enumeration value="assignee"/>
+ <enumeration value="licensee"/>
+ </restriction>
+ </simpleType>
+
+ <simpleType name="contactTypeType">
+ <restriction base="token">
+ <enumeration value="owner"/>
+ <enumeration value="agent"/>
+ <enumeration value="thirdparty"/>
+ </restriction>
+ </simpleType>
+ </schema>
+ END
+
+
+
+
+
+
+Lozano Standards Track [Page 20]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+4. IANA Considerations
+
+ This document uses URNs to describe XML namespaces and XML schemas
+ conforming to the registry mechanism described in [RFC3688]. IANA
+ has registered two URI assignments: signed mark (signedMark-1.0) and
+ mark (mark-1.0).
+
+ o The signed mark namespace (signedMark-1.0) has been registered in
+ the "ns" registry.
+
+ URI: urn:ietf:params:xml:ns:signedMark-1.0
+
+ Registrant Contact: IESG
+
+ XML: None. Namespace URIs do not represent an XML specification.
+
+ o The signed mark schema (signedMark-1.0) has been registered in the
+ "schema" registry.
+
+ URI: urn:ietf:params:xml:schema:signedMark-1.0
+
+ Registrant Contact: IESG
+
+ XML: See the "Formal Syntax" section of this document.
+
+ o The mark namespace (mark-1.0) has been registered in the "ns"
+ registry.
+
+
+ URI: urn:ietf:params:xml:ns:mark-1.0
+
+ Registrant Contact: IESG
+
+ XML: None. Namespace URIs do not represent an XML specification.
+
+ o The mark schema (mark-1.0) has been registered in the "schema"
+ registry.
+
+ URI: urn:ietf:params:xml:schema:mark-1.0
+
+ Registrant Contact: IESG
+
+ XML: See the "Formal Syntax" section of this document.
+
+
+
+
+
+
+
+
+Lozano Standards Track [Page 21]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+5. Security Considerations
+
+ The security of a Signed Mark object depends on the security of the
+ underlying XML Digital Signature (DSIG) algorithms. As such, all the
+ security considerations from [XMLDSIG] apply here as well.
+
+ The digital signature algorithm used in Signed Mark objects SHOULD be
+ RSA-SHA256 [RFC6931]. The size of the RSA key SHOULD be at least
+ 2048 bits. A valid reason for choosing something else would be if
+ RSA-SHA256 is deemed to not provide sufficient security.
+
+ In the case of the ICANN TMCH, Signed Mark objects use the algorithms
+ for digesting and signing recommended in this document.
+
+ Signed Mark objects are used primarily for domain name registrations
+ in gTLDs during the Sunrise Period, but other third parties might be
+ using them. A party using Signed Mark objects should verify that the
+ digital signature is valid based on local policy. In the case of
+ gTLDs, the Rights Protection Mechanism Requirements document
+ [ICANN-TMCH] defines such policy, and the PKI is defined in [TMCH].
+ Implementations will need to implement such a PKI (or an equivalent)
+ in order for the signatures defined in this document to have any
+ useful semantics.
+
+6. References
+
+6.1. Normative References
+
+ [ICANN-TMCH]
+ ICANN, "Trademark Clearinghouse; Rights Protection
+ Mechanism Requirements", 2013,
+ <http://newgtlds.icann.org/en/about/
+ trademark-clearinghouse/rpm-requirements-30sep13-en.pdf>.
+
+ [ISO3166-2]
+ ISO, "International Standard for country codes and codes
+ for their subdivisions", 2006,
+ <http://www.iso.org/iso/home/standards/country_codes.htm>.
+
+ [ITU.E164.2005]
+ International Telecommunication Union, "The international
+ public telecommunication numbering plan", ITU-T
+ Recommendation E.164, November 2010,
+ <https://www.itu.int/rec/T-REC-E.164-201011-I/en>.
+
+
+
+
+
+
+
+Lozano Standards Track [Page 22]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+ DOI 10.17487/RFC3688, January 2004,
+ <http://www.rfc-editor.org/info/rfc3688>.
+
+ [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
+ Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
+ <http://www.rfc-editor.org/info/rfc4648>.
+
+ [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
+ DOI 10.17487/RFC5322, October 2008,
+ <http://www.rfc-editor.org/info/rfc5322>.
+
+ [RFC5890] Klensin, J., "Internationalized Domain Names for
+ Applications (IDNA): Definitions and Document Framework",
+ RFC 5890, DOI 10.17487/RFC5890, August 2010,
+ <http://www.rfc-editor.org/info/rfc5890>.
+
+ [RFC6931] Eastlake 3rd, D., "Additional XML Security Uniform
+ Resource Identifiers (URIs)", RFC 6931,
+ DOI 10.17487/RFC6931, April 2013,
+ <http://www.rfc-editor.org/info/rfc6931>.
+
+ [WIPO-NICE-CLASSES]
+ WIPO, "Nice Classification", January 2016,
+ <http://www.wipo.int/classifications/nice/en>.
+
+ [WIPO.ST3] WIPO, "Recommended standard on two-letter codes for the
+ representation of states, other entities and
+ intergovernmental organizations", Standard ST.3, February
+ 2015, <http://www.wipo.int/standards/en/pdf/03-03-01.pdf>.
+
+ [XMLC14N] W3C, "Exclusive XML Canonicalization Version 1.0",
+ W3C Recommendation, July 2002,
+ <http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718>.
+
+ [XMLDSIG] W3C, "XML Signature Syntax and Processing Version 1.1",
+ W3C Recommendation, April 2013,
+ <http://www.w3.org/TR/xmldsig-core1>.
+
+
+
+
+
+
+
+
+Lozano Standards Track [Page 23]
+
+RFC 7848 Mark and Signed Mark June 2016
+
+
+6.2. Informative References
+
+ [EPP-LAUNCH]
+ Gould, J., Tan, W., and G. Brown, "Launch Phase Mapping
+ for the Extensible Provisioning Protocol (EPP)", Work in
+ Progress, draft-ietf-regext-launchphase-00, April 2016.
+
+ [RFC5105] Lendl, O., "ENUM Validation Token Format Definition",
+ RFC 5105, DOI 10.17487/RFC5105, December 2007,
+ <http://www.rfc-editor.org/info/rfc5105>.
+
+ [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
+ STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
+ <http://www.rfc-editor.org/info/rfc5730>.
+
+ [TMCH] Lozano, G., "ICANN TMCH functional specifications", Work
+ in Progress, draft-ietf-regext-tmch-func-spec-00, April
+ 2016.
+
+Acknowledgements
+
+ Special thanks to Chris Wright for creating the first prototype of an
+ SMD and to James Gould, Wil Tan, and Gavin Brown for creating the
+ mark and SMD definitions in "Launch Phase Mapping for the Extensible
+ Provisioning Protocol (EPP)" [EPP-LAUNCH], on which this document is
+ based. Portions of the Security Considerations section were
+ shamefully copied from RFC 5105 [RFC5105]. The author would like to
+ acknowledge the following individuals for their contributions to this
+ document: Scott Hollenbeck and Jan Jansen.
+
+Author's Address
+
+ Gustavo Lozano
+ ICANN
+ 12025 Waterfront Drive, Suite 300
+ Los Angeles, CA 90292
+ United States
+
+ Phone: +1.3103015800
+ Email: gustavo.lozano@icann.org
+
+
+
+
+
+
+
+
+
+
+
+Lozano Standards Track [Page 24]
+