Registration Protocols Extensions (regext) A. Newton Internet-Draft ICANN Intended status: Standards Track 17 June 2024 Expires: 19 December 2024 RDAP Simple Redaction draft-newton-regext-rdap-simple-redaction-00 Abstract This document defines a simple redaction extension for the Registration Data Access Protocol (RDAP). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 19 December 2024. Copyright Notice Copyright (c) 2024 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Newton Expires 19 December 2024 [Page 1] Internet-Draft simple-redaction June 2024 Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Redaction Keys . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Unstructured Text . . . . . . . . . . . . . . . . . . . . 3 2.2. TEL URIs . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Email Addresses . . . . . . . . . . . . . . . . . . . . . 4 2.4. URIs with Host Names . . . . . . . . . . . . . . . . . . 4 3. Explicit Keying . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. The "simpleRedaction" Array . . . . . . . . . . . . . . . 5 3.2. Alternates . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Redaction Policy . . . . . . . . . . . . . . . . . . . . 8 3.4. Keying Strategies . . . . . . . . . . . . . . . . . . . . 9 3.4.1. Unclean Data . . . . . . . . . . . . . . . . . . . . 9 3.4.2. Handles . . . . . . . . . . . . . . . . . . . . . . . 10 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Unstructured Addresses . . . . . . . . . . . . . . . . . 10 4.2. Structured Addresses . . . . . . . . . . . . . . . . . . 11 4.3. A Complete Example . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Background This document defines "simple redaction", an extension for redacting information from Registration Data Access Protocol (RDAP) response. Simple redaction only defines redaction in JSON strings of RDAP responses. This narrowed scope meets the purposes of known redaction policies, such as the ICANN Registration Data Policy (https://www.icann.org/resources/pages/registration-data-policy- 2024-02-21-en), where redaction is applied against "personal data" which is only found in JSON strings in the RDAP specification ([RFC9083]). The only place in RDAP where booleans or integers are used in the base specification of [RFC9083] are in the DNSSEC portion of the domain object class, and there is unlikely to be policy for redaction of such information as it also visible in the public DNS. This specification does not require the removal of JSON values or components that would otherwise make the resulting JSON invalid according to [RFC9083] nor syntactically invalid according to [RFC9083] or [RFC7095]. Therefore, the resulting responses are syntactically valid but semantically redacted. Newton Expires 19 December 2024 [Page 2] Internet-Draft simple-redaction June 2024 Finally, this specification has the benefit that if an RDAP client does not recognize this extension and simply passes the redaction signals onto the user, in some contexts the user may still understand that the information is redacted. The following is an example of an RDAP response using simple redaction: { "rdapConformance" : [ "Rdap_level_0", “simpleRedaction” ], "objectClassName" : "entity", "handle":"////REDACTED_HANDLE////", "vcardArray":[ "vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "////REDACTED_FULL_NAME////"], ["email", { "type":"work" }, "text", "redacted_email@redacted.invalid" ] ] ], “simpleRedaction”: [ { “key”: “////REDACTED_HANDLE////” }, { “key”: “////REDACTED_FULL_NAME////” }, { “key”: “redacted_email@redacted.invalid” } ] } 2. Redaction Keys Simple redaction allows a server to define a set of keys, each used to signify when data in a string has been redacted. Clients use these keys to identify the information being redacted. 2.1. Unstructured Text Keys signifying redaction for unstructured text, i.e. free form text, take the form of ////REDACTION_KEY////. These keys begin with four forward-slash character ("////"), followed by one or more of the upper and lower case characters A through Z, 0 through 9, hyphen ("-"), or under-bar ("_"), followed by four more forward-slash characters. The following example demonstrates redaction of the full name value from a jCard ([RFC7095]) array: Newton Expires 19 December 2024 [Page 3] Internet-Draft simple-redaction June 2024 ["fn", {}, "text", "////REDACTED_FULL_NAME////"] These keys may be placed in a string with other characters thus allowing for the partial redaction of a string: "Alice ////LAST_NAME_REDACTION////" 2.2. TEL URIs Keys for use in "tel" URIs ([RFC3966]) follow a form similar to Section 2.1 but with a restricted set of characters to conform to the "tel" URI syntax. These keys begin and end with four forward-slash characters, but the set of characters allowed between the slashes is limited to 0 through 9. For example: ////0123456789////. The following is an example of a "tel" URI used in a jCard array: ["tel", {}, "uri", "tel:+////0000000////;ext=////999999////"] The above is just an example, but [RFC6530], which defines the structures in [RFC7095], does not require the "tel" property to be a URI. So this maybe written as: ["tel", {}, "text", "////TELEPHONE_REDACTION////"] 2.3. Email Addresses Keys for email addresses MUST use a host part that is "redacted.invalid" but may use any local part allowable in an email address. For example: redacted_email@redacted.invalid. The ".invalid" TLD is a special-use domain defined in [RFC6761] and is unusable on the Internet. 2.4. URIs with Host Names Keys used in a URI with host names, such as an HTTP URI, MUST use a host name that is "redacted.invalid". For example: https://redacted.invalid/redacted_web_page. The ".invalid" TLD is a special-use domain defined in [RFC6761] and is unusable on the Internet. 3. Explicit Keying All redaction keys (Section 2) are explicitly specified by the server. Newton Expires 19 December 2024 [Page 4] Internet-Draft simple-redaction June 2024 3.1. The "simpleRedaction" Array Each defined key MUST be given in the "simpleRedaction" array value. This array contains JSON objects. Each JSON object has a REQUIRED JSON string named "key", a JSON array named "reasons", and an OPTIONAL "links" array as defined by [RFC9083] (see Section 3.2 and Section 3.3 on usage). The "reasons" array is OPTIONAL but if present MUST NOT be empty. The "reasons" array contains JSON objects. These objects SHOULD have a "lang" member as defined by [RFC9083] and MUST have a JSON array named "description". The "description" array contains only JSON strings. The following is an example: “simpleRedaction”: [ { “key”: “////REDACTED_FULL_NAME////”, “reasons” : [ { “lang”: “en”, “description” : [ “The full name of registrants has not been given.”, “This redaction is done according to policy.” ] }, { “lang”: “ja”, “description” : [ “登録者のフルネームは公表されていない。”, “この編集はポリシーに従って行われます。” ] } ], "links": [ { "value": "https://example.com/value", "rel": "about", "href": "https://example.com/some-policy.html", "type": "text/html" } ] } ] Newton Expires 19 December 2024 [Page 5] Internet-Draft simple-redaction June 2024 A key MAY be used more than once in an RDAP object, but it MUST only appear once in the "simpleRedaction" array of objects. A client MUST NOT consider any key not found to be the "simpleRedaction" array of objects as a valid redaction (i.e. do not signal to the user that the information has been redacted). The "simpleRedaction" JSON value MUST only be in the top-most object of the RDAP response. 3.2. Alternates The "simpleRedaction" array described in Section 3.1 allows each key to be accompanied by an array of links, as defined by [RFC9083]. Usage of the links may be used to signal an alternate usage in cases where the alternate can be expressed as a URI. To do this, servers MUST use the "alternate" link relation and clients SHOULD signal to users that the "href" value is available for alternate usage. The following example demonstrates the signaling on a web-based contact form to be used instead of email. Newton Expires 19 December 2024 [Page 6] Internet-Draft simple-redaction June 2024 { "rdapConformance" : [ "Rdap_level_0", “simpleRedaction” ], "objectClassName" : "entity", "handle":"foo", "vcardArray":[ "vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Bob Allison"], ["email", { "type":"work" }, "text", "redacted_email@redacted.invalid" ] ] ], “simpleRedaction”: [ { “key”: “redacted_email@redacted.invalid”, "links": [ { "value": "https://example.com/value", "rel": "alternate", "href": "https://example.com/contact-form", "type": "text/html" } ] } ] } This example demonstrates signaling that an alternate email address is to be used. Newton Expires 19 December 2024 [Page 7] Internet-Draft simple-redaction June 2024 { "rdapConformance" : [ "Rdap_level_0", “simpleRedaction” ], "objectClassName" : "entity", "handle":"foo", "vcardArray":[ "vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Bob Allison"], ["email", { "type":"work" }, "text", "redacted_email@redacted.invalid" ] ] ], “simpleRedaction”: [ { “key”: “redacted_email@redacted.invalid”, "links": [ { "value": "https://example.com/value", "rel": "alternate", "href": "mailto:proxy-service@example.com" } ] } ] } Clients should consider, when presenting information to a user, that an alternate use may differ from the form in the RDAP response. For example, the RDAP response may contain an email address but the alternate usage is a web page. 3.3. Redaction Policy The "links" array described in Section 3.1 may also be used to link to a web page describing the redaction policy. When the array is to be used for this purpose, the "about" relationship MUST be used. The following is an example. Newton Expires 19 December 2024 [Page 8] Internet-Draft simple-redaction June 2024 { "rdapConformance" : [ "Rdap_level_0", “simpleRedaction” ], "objectClassName" : "entity", "handle":"foo", "vcardArray":[ "vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Bob Allison"], ["email", { "type":"work" }, "text", "redacted_email@redacted.invalid" ] ] ], “simpleRedaction”: [ { “key”: “redacted_email@redacted.invalid”, "links": [ { "value": "https://example.com/value", "rel": "about", "href": "https://example.com/some-policy.html", "type": "text/html" } ] } ] } 3.4. Keying Strategies 3.4.1. Unclean Data While it seems odd that some users would be allowed to give an email address with a host of "redacted.invalid" or a string that begins and ends with four forward-slashes to an Internet registration authority, some registries must deal with such data for various reasons. One strategy servers may use would be to append a set of random characters to each key. For example, if a registered resource was given as "////I-fooled-you////" then the server could thwart this by appending the random characters "1234-NO-YOU-DID-NOT" to make the key "////I-fooled-you_1234-NO-YOU-DID-NOT////". Newton Expires 19 December 2024 [Page 9] Internet-Draft simple-redaction June 2024 3.4.2. Handles For servers operating under policies in which the "handle", as defined by [RFC9083] must be redacted, it would be beneficial to some clients to create unique redaction keys for each handle. While clients SHOULD use "self" links, as described in [RFC9083], to differentiate between between objects returned in a response, in the absence of "self" links they often use the "handle". Therefore, servers SHOULD create a unique redaction key for each handle that is redacted. 4. Examples 4.1. Unstructured Addresses [RFC7095] allows for the representation of unstructured postal addresses. The following is a simple example of an RDAP response with simple redactions where the postal address is given as unstructured. { "rdapConformance" : [ "Rdap_level_0", “simpleRedaction” ], "objectClassName" : "entity", "handle":"foo", "vcardArray":[ "vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Bob"], ["adr", { "type":"home", "label":"////REDACTED_STREET////\nVancouver\nBC\n////REDACTED_POSTAL_CODE////\n" }, "text", [ "", "", "", "", "", "", "" ] ], ] ], “simpleRedaction”: [ { “key”: “////REDACTED_STREET////” }, { “key”: “////REDACTED_POSTAL_CODE////” }, ] } Newton Expires 19 December 2024 [Page 10] Internet-Draft simple-redaction June 2024 4.2. Structured Addresses [RFC7095] allows for the representation of structured postal addresses. The following is a simple example of an RDAP response with simple redactions where the postal address is given as structured. { "rdapConformance" : [ "Rdap_level_0", “simpleRedaction” ], "objectClassName" : "entity", "handle":"foo", "vcardArray":[ "vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Bob"], ["adr", { "type":"work" }, "text", [ "", "////REDACTED_STREET////", "////REDACTED_STREET////", "Quebec", "QC", "////REDACTED_POSTAL_CODE////", "Canada" ] ] ] ], “simpleRedaction”: [ { “key”: “////REDACTED_STREET////” }, { “key”: “////REDACTED_POSTAL_CODE////” }, ] } 4.3. A Complete Example The following is an example an RDAP response to a domain lookup in which the redactions specified in ICANN Registration Data Policy (https://www.icann.org/resources/pages/registration-data-policy- 2024-02-21-en), have been applied. Newton Expires 19 December 2024 [Page 11] Internet-Draft simple-redaction June 2024 { "rdapConformance": [ "rdap_level_0", "simpleRedaction" ], "objectClassName": "domain", "handle": "////REGISTRY_DOMAIN_ID_REDACTION////", "ldhName": "example.com", "secureDNS": { "delegationSigned": false }, "notices": [ { "title": "Terms of Use", "description": [ "Service subject to Terms of Use." ], "links": [ { "rel": "self", "href": "https://www.example.com/terms-of-use", "type": "text/html", "value": "https://www.example.com/terms-of-use" } ] } ], "nameservers": [ { "objectClassName": "nameserver", "ldhName": "ns1.example.com" }, { "objectClassName": "nameserver", "ldhName": "ns2.example.com" } ], "entities": [ { "objectClassName": "entity", "handle": "123", "roles": [ "registrar" ], "publicIds": [ { "type": "IANA Registrar ID", "identifier": "1" } Newton Expires 19 December 2024 [Page 12] Internet-Draft simple-redaction June 2024 ], "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "fn", {}, "text", "Example Registrar Inc." ], [ "adr", {}, "text", [ "", "Suite 100", "123 Example Dr.", "Dulles", "VA", "20166-6503", "US" ] ], [ "email", {}, "text", "contact@organization.example" ], [ "tel", { "type": "voice" }, "uri", "tel:+1.7035555555;ext=1234" ], [ "tel", { "type": "fax" Newton Expires 19 December 2024 [Page 13] Internet-Draft simple-redaction June 2024 }, "uri", "tel:+1.7035555556" ] ] ], "entities": [ { "objectClassName": "entity", "roles": [ "abuse" ], "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "fn", {}, "text", "Abuse Contact" ], [ "email", {}, "text", "abuse@organization.example" ], [ "tel", { "type": "voice" }, "uri", "tel:+1.7035555555;ext=1234" ] ] ] } ] }, { "objectClassName": "entity", Newton Expires 19 December 2024 [Page 14] Internet-Draft simple-redaction June 2024 "handle": "////REGISTRY_REGISTRANT_ID_REDACTION////", "roles": [ "registrant" ], "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "fn", {}, "text", "////REGISTRANT_NAME_REDACTION////" ], [ "org", {}, "text", "////REGISTRANT_ORG_REDACTION////" ], [ "adr", {}, "text", [ "", "////REGISTRANT_STREET_REDACTION////", "////REGISTRANT_STREET_REDACTION////", "Quebec", "////REGISTRANT_CITY_REDACTION////", "////REGISTRANT_POSTAL_CODE_REDACTION////", "Canada" ] ], [ "email", {}, "text", "registrant-email-redaction@redacted.invalid" ], [ "tel", { Newton Expires 19 December 2024 [Page 15] Internet-Draft simple-redaction June 2024 "type": "voice" }, "uri", "tel:+////0000000000////;ext=////1111111111////" ], [ "tel", { "type": "fax" }, "uri", "tel:+////2222222222////" ] ] ] }, { "objectClassName": "entity", "handle": "////REGISTRY_TECH_ID_REDACTION////", "roles": [ "technical" ], "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "fn", {}, "text", "////TECH_NAME_REDACTION////" ], [ "org", {}, "text", "Example Inc." ], [ "adr", {}, "text", [ Newton Expires 19 December 2024 [Page 16] Internet-Draft simple-redaction June 2024 "", "Suite 1234", "4321 Rue Somewhere", "Quebec", "QC", "G1V 2M2", "Canada" ] ], [ "email", {}, "text", "technical-email-redaction@redacted.invalid" ], [ "tel", { "type": "voice" }, "uri", "tel:+////3333333333////;ext=321" ], [ "tel", { "type": "fax" }, "uri", "tel:+1-555-555-4321" ] ] ] } ], "events": [ { "eventAction": "registration", "eventDate": "1997-06-03T00:00:00Z" }, { "eventAction": "last changed", "eventDate": "2020-05-28T01:35:00Z" }, { "eventAction": "expiration", "eventDate": "2021-06-03T04:00:00Z" } Newton Expires 19 December 2024 [Page 17] Internet-Draft simple-redaction June 2024 ], "status": [ "server delete prohibited", "server update prohibited", "server transfer prohibited", "client transfer prohibited" ], “simpleRedaction”: [ { “key”: “////REGISTRY_DOMAIN_ID_REDACTION////” }, { “key”: “////REGISTRY_REGISTRANT_ID_REDACTION////” }, { “key”: “////REGISTRANT_NAME_REDACTION////” }, { “key”: “////REGISTRANT_STREET_REDACTION////” }, { “key”: “////REGISTRANT_POSTAL_CODE_REDACTION////” }, { “key”: “////0000000000////” }, { “key”: “////1111111111////” }, { “key”: “////REGISTRY_TECH_ID_REDACTION////” }, { “key”: “////TECH_NAME_REDACTION////” }, { “key”: “////1111111111////” }, { “key”: “////2222222222////” }, { “key”: “registrant-email-redaction@redacted.invalid” }, { “key”: “tech-email-redaction@redacted.invalid” }, { “key”: “////REGISTRANT_ORG_REDACTION////” }, { “key”: “////REGISTRANT_CITY_REDACTION////” } ] } 5. Security Considerations TBD. 6. IANA Considerations TBD: registration of "simpleRedaction". 7. References 7.1. Normative References [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, . [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, . Newton Expires 19 December 2024 [Page 18] Internet-Draft simple-redaction June 2024 [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the Registration Data Access Protocol (RDAP)", STD 95, RFC 9083, DOI 10.17487/RFC9083, June 2021, . 7.2. Informative References [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, February 2012, . [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, DOI 10.17487/RFC7095, January 2014, . Author's Address Andy Newton ICANN Email: andy@hxr.us Newton Expires 19 December 2024 [Page 19]