Re: [regext] RDAP queries based on redacted properties

["Gould, James" <[e-mail]>]

Mario,

My responses are embedded below.

--

JG

[cid:image001.png@01D923FC.13858AF0]

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: Mario Loffredo <[e-mail]>
Date: Sunday, January 8, 2023 at 8:38 AM
To: James Gould <[e-mail]>, "[e-mail]" <[e-mail]>
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: [phone]

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>