Mario, My responses are embedded below.
-- JG [cid:image001.png@01D923FC.13858AF0] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Mario Loffredo <mario.loffr...@iit.cnr.it> Date: Sunday, January 8, 2023 at 8:38 AM To: James Gould <jgo...@verisign.com>, "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] RDAP queries based on redacted properties Hi James, please find my comments below. Il 06/01/2023 14:54, Gould, James ha scritto: Mario, The JSContact "uid" and the jCard "handle" may be redacted in the entities member of a domain query response, where the entity is returned as a sub-object. Redaction of the JSContact "uid" and the jCard "handle" in the domain query response doesn't impact the query at all. I don't believe it makes much sense to redact the lookup key (JSContact "uid" and the jCard "handle") for an object in the case of an entity query. Think that, at least in theory, such a policy may result in a privacy bug. Given that the entity handle must be the same when the entity is included in both a domain query response and an entity query response, if one was able to discover the method used to assign handle values to entities, he would also be able to desume a possible redacted value by submitting a an entity lookup and receiving a valid response. Obviously, in practice, the RDAP server can implement some stategies to operate consistently such as making the entity lookup to return an error when the handle is redacted somewhere in an RDAP response as well as allowing the entity lookup only to those users who can access the entity handle. But, without a clarification in that sense, redacting the entity handle depending on the entity role in domain query responses and, at the same time, allowing the entity lookup to everyone appear to me two inconsistent statements. JG – I’m not advocating for redaction of the entity handle in the domain response or the entity response but bringing up the possibility that it may be redacted in the domain response per the draft RDAP Profile. Considering that there is a known use case that the “uid” will be redacted, it’s important for draft-ietf-regext-rdap-jscontact directly or indirectly via the use of draft-ietf-calext-jscontact to make it required. This is one reason that the draft-ietf-regext-rdap-jscontact "uid" member should not be mandatory due to the need for redaction at the sub-object level. Can draft-ietf-regext-rdap-jscontact override the draft-ietf-calext-jscontact mandatory "uid" member to be optional to support redaction in RDAP? The draft-ietf-regext-rdap-redacted is strictly focused on the redaction methods of the responses and I don't believe it needs to mandate or recommend policy on what quires a server needs to support or not support. As already said, I'll propose to calext to make uid optional when JSContact is used as a contact representation within protocols supporting other contact identifiers. Therefore, my proposal for the uid field in RDAP will be the following: Option 1) uid is optional - uid can be redacted or not depending on its format and server policy The JSCard "uid" property SHOULD be a URN in the UUID namespace [RFC4122], 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. Option 2) uid is required - uid must be inherently opaque and undecipherable The JSCard "uid" property MUST be a URN in the UUID namespace [RFC4122]. If the uid value is generated starting from a redacted value (i.e. name-based UUID), SHA-1 MUST be used as hashing algorithm. JG – Either draft-ietf-calext-jscontact needs to remove the “(mandatory)” marking or draft-ietf-regext-rdap-jscontact needs to override the mandatory marking to make it optional in RDAP. Best, Mario 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://www.iit.cnr.it/mario.loffredo<http://secure-web.cisco.com/1BbmuPqS2BAJK2bTpjZqNHpJG1vYbreydeGM-DH5CafJ17E6WkfXZdKRw_p-blZFE4VQNYJFFPmdbMMzZv4cMmj6TMUWhUIAUAXZGxKaUOIFg8VFZ_mGkzm3MgoiIPNCYBU4nS7Jwy81wB0v4EWzwzUXGHLVmrfZIC2oPDEmMxqSwfM6jYeAp-EDKVv52TtXWFlQbR3LLWk0Z_kG_7vXBvuLZExzirKcOnP3T__X9Oif7Dn5ANjPhzkJgJ3xR4Pxr98B1aK0VmYWQo6WSaoWIXJklBvoQEqhwfrP6eA9bL7I/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
