Mario, My responses are embedded below.
-- JG [cid:[email protected]] James Gould Fellow Engineer [email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Mario Loffredo <[email protected]> Date: Wednesday, January 4, 2023 at 11:04 AM To: James Gould <[email protected]>, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-jscontact-15.txt Hi James, please find my comments in line. Il 04/01/2023 14:49, Gould, James ha scritto: Mario, The recommendation in draft-ietf-regext-rdap-jscontact is that the JSCard “uid” property SHOULD contain the same value as the RDAP “handle” property. Have already changed that sentence as in the following to make the "uid" field in RDAP more compliant with its definition in JSContact hence restricting the use of the free-text format: The JSCard "uid" property SHOULD be a URN in the UUID namespace, MAY be a URI where the URI is the URL of the lookup query for the entity related to the contact card. The entity lookup URL MUST always be used regardless of the query generating the response including the contact card. If a UUID is used, there is no need to redact the "uid" field since the UUIDs are not inherently sensitive information. If a URI can be used, it seemed to me quite natural to mandate the use of the entity lookup URL since it is the basic RDAP query to get information about an entity and, as such, I assumed that an entity handle is generally not sensitive too. JG – We do have the case of redaction of the entity “handle” property for the registrant and tech contacts in the domain query response, where if the “handle” property is redacted that would match the “uid” property. My recommendation is to make the “uid” property recommended by not required in draft-ietf-regext-rdap-jscontact, where it may be required for JSCard but needs to be redactable in RDAP. We do provide an example of redacting the domain RDAP “handle” property in draft-ietf-regext-rdap-redacted, so it’s not a stretch to also redact the entity RDAP “handle” property. Based on the IRT OneDoc and the supporting draft Version 2.2 of the RDAP Response Profile, the “handle” for the Registrant (e.g., “Registry Registrant ID”) and Tech (e.g., “Registry Tech ID”) contacts are subject to redaction requirements, so this is not much of a corner case in RDAP. You may want to follow-up with calext on the possibility of having to redact the “uid” field, since it looks like a true possibility downstream in RDAP. I don’t believe draft-ietf-regext-rdap-jscontact can make a required field of JSContact optional, but I don’t believe it can be made mandatory in RDAP. Attempting to redact a required field of an RDAP extension in draft-ietf-regext-rdap-redacted gets into thorny compliance issues, such as removing a required field via the Redaction by Removal Method or keeping the field by clearing the value that may have format requirements via the Redaction by Empty Value Method. Wonder how can an RDAP operator allow the entity lookup and, at the same time, redact the handle information. I mean, it should depend on the user grants, not on the handle value. If an user is not allowed to access the handle information, he can't submit the entity lookup and viceversa. Otherwise, a requestor could desume the redacted handle by simply submitting the entity lookup and receiving a successful response. I'll open a new post about this topic regarding redaction on the mailing list. That said, on the admission that an RDAP operator redacts the entity handle and the "uid" field includes the entity lookup URL, I recommended to use the same redaction method as used for jCard "fn". Both are mandatory in their related specifications, both are provided as text (free-text is also allowed for JSContact uid), and in both cases the use of the Empty Value is a workaround to keep them compliant with the constraint that they must be present. JG – The redaction is not related to the entity lookup, but with the inclusion of the entities in the domain response. I don’t see any reason to redact the “handle” if the handle is used as the key for an entity lookup. The issue is when an entity sub-object is included in a response, where the “handle” or JSCard “uid” properties may need to be redacted; therefore draft-ietf-regext-rdap-jscontact cannot make the JSCard “uid” property required. The best approach is to ensure that the base RDAP extension is not overly strict on the mandatory properties to support redaction. I believe Redaction by Removal Method is the cleanest method of redaction for a standard JSON member. It will be up to the RDAP extensions to be more conservative in their normative language for JSON members to support redaction if required by server policy. I don’t recommend updating draft-ietf-regext-rdap-redacted to attempt to override the normative language of an RDAP extension explicitly by removing the member or implicitly by returning an empty value. Undoubtedly, it would be much better if the uid field could be optional when JSContact is used as a contact representation within another protocol. I'll follow-up with calext on this possibility. The alternative is to change the above sentence as in the following: The JSCard "uid" property MUST be a URN in the UUID namespace. A UUIDv5 is fairly secure from being reversed even when it is generated from a sensitive or redacted information. JG – Can JSContact make the “uid” property required while the JSContact use in RDAP, as defined by draft-ietf-regext-rdap-jscontact can make it recommended or optional? If not, you need to push to make draft-ietf-calext-jscontact-vcard more conservative to support its downstream use in RDAP by making the “uid” property recommended (SHOULD) or optional (MAY). Best, Mario -- JG James Gould Fellow Engineer [email protected]<mailto:[email protected]> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]><mailto:applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/><http://secure-web.cisco.com/1BVtUli3KeUSmJ_2Fxp3htIFHb6gfsqGGc1Xh1nYAXgPq3-Um-p0XSQxO2pce6dmaSMMp1WRpVzPjNgO9KH5vfBhywplGD9Stw46WUhA2ASE6Jm0vmdGKe5EQOrDYHdypWaeUzGAfenHeb8H1H74bDavprJvbL3Uy2OqtFuYHA8AAJgP9erndfYGcdx3pTzVWtbo12Z6js87QeHJJiIkho6SUjnDiFjXfhYWmvFqwEIr1q0G1fAPnT_rWoQD9Y7iIgh66fJCEfJnD9ImhZP7VFQkvrWY0vjoT8CqHB8XAzas/http%3A%2F%2Fverisigninc.com%2F> On 1/4/23, 4:58 AM, "Mario Loffredo" <[email protected]><mailto:[email protected]> wrote: Hi James, honestly don't think that the "uid" field will ever get redacted, I mean, it's recommended to be an UUID and normally UUIDs are opaque. Both UUIDv3 (MD5) and UUIDv5 (SHA1) can be derived from a string (like for example the entity handle) so there is no need to generate and store a new value. If it was optionally represented as an URI, a reasonable value could be the URL of the entity lookup whose response includes the contact card. Since the entity lookup is based on the entity handle value and such a value is a registry unique identifier, either in this case, the "uid" redaction seems very unlikely to me. Anyway, I can't completely exclude such a corner case. In the unlikely event that the "uid" field is redacted, I would process it in the same way as the jCard "fn" property. Both of them are required text fields so don't see why they should be processed differently. In addition, there is a requirement from calext about keeping uid mandatory. Best, Mario Il 03/01/2023 17:33, Gould, James ha scritto: > Mario, > > I don't see any need to add a dependency between draft-ietf-regext-rdap-jscontact and draft-ietf-regext-rdap-redacted, but this does add an interesting case for draft-ietf-regext-rdap-redacted with redacting a required JSON member. Do you see the requirement to be able to redact the required "uid" JSContact property? If there is the need to redact it, then wouldn't that make the case for it not to be defined as mandatory in draft-ietf-calext-jscontact? I'm not sure whether providing an empty value via the Redaction by Empty Value Method is any better than simply removing it via the Redaction by Removal Method. We would need to first determine whether there is the need to cover the case of redacting a required JSON member in draft-ietf-regext-rdap-redacted and if so how best to handle it. > > Thanks, > -- Dott. Mario Loffredo Technological Unit “Digital Innovation” Institute of Informatics and Telematics (IIT) National Research Council (CNR) via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Web: http://secure-web.cisco.com/1dUrW2nmIC0BLllxqOdvyNJK5jfCH4-D45wpX6KaFLgWfNx6Le_Mud9m9ktIoHTtzUlk6SlpeYMgGQfmJzds6HeOkZj1FfogRWY5RhWmnpk_EPL0BD7rHq_455H43ZDeaKw0Q-sqQ7YkhmF2P0Adk40p5dh5EU__t9yITWm551g0_Uqs90zOztBNH7H4wL2gmnkaAOYeYWTsVhoNWX7ctYsHaYgBBfwWXwxa8xRzSjbaNJMblH--htjDjKydpncQJJZevOW9_fICNnUf5GZih5lIRzGvDFUnqb_4QSFuu73M/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo -- Dott. Mario Loffredo Technological Unit “Digital Innovation” Institute of Informatics and Telematics (IIT) National Research Council (CNR) via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Web: http://www.iit.cnr.it/mario.loffredo<http://secure-web.cisco.com/1m0KCb6Bb8wxqaiTD3Vz2MKU07qBAfYD1TpHzh4mINLKFNLGy4awNCadmrky5JxkBj1sWUa7oUZJzds9BvD6kDrE_IFvr07n1PrTkhvvVQlbPBDnc-cGieZX4gaBVObOxzvmqm-kkNOHglNZZH-BAE-1JVaekrwjszMKg1EvGgZzovM7siby4wA83Nx3bGgQ1_la7HqGo_azn0gvOu_52l1b_mRdCD3HadKclM_529-EfqdJR9dznAu3ZbhsAHuQll0otbHzPMARInYPpEkmy6CkNwadLOGbNcu8IhkLmOJA/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
