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

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

Mario,

My responses are embedded below.

--

JG

[cid:image001.png@01D921E7.54563C80]

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: Wednesday, January 4, 2023 at 11:04 AM
To: James Gould <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft-ietf-regext-rdap-jscontact-15.txt


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.



JG – We do have the case of redaction of the entity “handle” property for the registrant and tech contacts in the domain query response, where if the “handle” property is redacted that would match the “uid” property.  My recommendation is to make the “uid” property recommended by not required in draft-ietf-regext-rdap-jscontact, where it may be required for JSCard but needs to be redactable in RDAP.

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.

JG – The redaction is not related to the entity lookup, but with the inclusion of the entities in the domain response.  I don’t see any reason to redact the “handle” if the handle is used as the key for an entity lookup.  The issue is when an entity sub-object is included in a response, where the “handle” or JSCard “uid” properties may need to be redacted; therefore draft-ietf-regext-rdap-jscontact cannot make the JSCard “uid” property required.  The best approach is to ensure that the base RDAP extension is not overly strict on the mandatory properties to support redaction.



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.

JG – Can JSContact make the “uid” property required while the JSContact use in RDAP, as defined by draft-ietf-regext-rdap-jscontact can make it recommended or optional?  If not, you need to push to make draft-ietf-calext-jscontact-vcard more conservative to support its downstream use in RDAP by making the “uid” property recommended (SHOULD) or optional (MAY).

Best,

Mario





--



JG







James Gould

Fellow Engineer

[e-mail]<mailto:[e-mail]> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]><mailto:applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com <http://verisigninc.com/><http://secure-web.cisco.com/1BVtUli3KeUSmJ_2Fxp3htIFHb6gfsqGGc1Xh1nYAXgPq3-Um-p0XSQxO2pce6dmaSMMp1WRpVzPjNgO9KH5vfBhywplGD9Stw46WUhA2ASE6Jm0vmdGKe5EQOrDYHdypWaeUzGAfenHeb8H1H74bDavprJvbL3Uy2OqtFuYHA8AAJgP9erndfYGcdx3pTzVWtbo12Z6js87QeHJJiIkho6SUjnDiFjXfhYWmvFqwEIr1q0G1fAPnT_rWoQD9Y7iIgh66fJCEfJnD9ImhZP7VFQkvrWY0vjoT8CqHB8XAzas/http%3A%2F%2Fverisigninc.com%2F>



On 1/4/23, 4:58 AM, "Mario Loffredo" <[e-mail]><mailto:[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<http://secure-web.cisco.com/1m0KCb6Bb8wxqaiTD3Vz2MKU07qBAfYD1TpHzh4mINLKFNLGy4awNCadmrky5JxkBj1sWUa7oUZJzds9BvD6kDrE_IFvr07n1PrTkhvvVQlbPBDnc-cGieZX4gaBVObOxzvmqm-kkNOHglNZZH-BAE-1JVaekrwjszMKg1EvGgZzovM7siby4wA83Nx3bGgQ1_la7HqGo_azn0gvOu_52l1b_mRdCD3HadKclM_529-EfqdJR9dznAu3ZbhsAHuQll0otbHzPMARInYPpEkmy6CkNwadLOGbNcu8IhkLmOJA/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>