Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-jscontact-15.txt

[Mario Loffredo <[e-mail]>]

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
>
> [e-mail] 
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
> 703-948-3271
>
> 12061 Bluemont Way
>
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> On 1/4/23, 4:58 AM, "Mario Loffredo" <[e-mail]> 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: [phone]
>
>     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: [phone]
Web:http://www.iit.cnr.it/mario.loffredo