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.
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.
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
