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.
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.
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.
Best,
Mario
--
JG
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/>
On 1/4/23, 4:58 AM, "Mario Loffredo" <mario.loffr...@iit.cnr.it> 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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
