I'm getting a little confused, where the ability to redact a field like the mandatory "uid" field in draft-ietf-calext-jscontact and indirectly in draft-ietf-regext-rdap-jscontact is needed for privacy reasons. It is up to server policy related to whether to include the "uid" field in the domain response, entity query, and entity response, which should not be dictated by the protocol. The base specification or specifications need to be less strict on the definition of a field such as the "uid" field to support the use of those specifications downstream. In this case, RDAP is the downstream protocol that needs to support redaction of the "uid" field, since it's defined as being the same as the "handle" field of jCard. My recommendation is to make the "uid" a SHOULD or MAY in draft-ietf-calext-jscontact that doesn't seem desired by CALEXT or have draft-ietf-regext-rdap-jscontact override it to make it optional in RDAP to support the known redaction use case.
-- 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/9/23, 11:56 AM, "Andrew Newton" <a...@hxr.us> wrote: IMHO, James is right. Redaction of handles and correlations to them need to be supported. The fact that they are optional in the base spec is very deliberate. And entities show up in the results of other queries, not just entity lookups. The privacy issue, as I understand it, is that if an entity from one response can be cross-reference through a handle or UUID to an entity on another response, that is a privacy leak. My sense is that JSContact needs the "uid" property for some sort of contact correlation by a user agent, which in some contexts is something an RDAP policy might want to prevent. Maybe a compromise is to invent a known ephemeral identifier for the "uid" property, which would allow RDAP policy to meet whatever privacy context is needed but also signal to the user agent that the "uid" is not very useful. (maybe use the data: URI). -andy On Mon, Jan 9, 2023 at 7:29 AM Gould, James <jgould=40verisign....@dmarc.ietf.org> wrote: > > Mario, > > > > My responses are embedded below. > > > > -- > > > > JG > > > > > James Gould > Fellow Engineer > jgo...@verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com > > > > From: Mario Loffredo <mario.loffr...@iit.cnr.it> > Date: Sunday, January 8, 2023 at 8:38 AM > To: James Gould <jgo...@verisign.com>, "regext@ietf.org" <regext@ietf.org> > 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: +39.0503153497 > > Web: http://secure-web.cisco.com/1xvsGS-PC71_K7224GLBnNR10A9otbtVEnSwKszREsecQz95Zl1pIWaybzOtQHis6LzxhuYV07B8LJJOvXmwdIalSxwJb72Ct0LLTDUuzpCLRqRY7dMYcjlMIc_Dlb4k5EWmEK2JAfgZvU3PwTAMl4C7KRoX-UkEorpqZUvLeOncuMfGc7pEt5j760QusMXK9-eXJAnx8YEmWUxyqv9LvlEO1ffIuMfZAwYh0xMmbYMWGB81afiKuPNxCtPGqdoFllRV518w0H6jX2iYZaE_cAJsXSAVXus8-sEaaPUza4XY/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo > > _______________________________________________ > regext mailing list > regext@ietf.org > https://secure-web.cisco.com/1bLl493cdg_9iiyfwCe0LD-h0L5WxiPZUBSYTnuFupBWcbHfP5qCiom__w6un9VrnSHuVp7Icx_dzwTUfzq6Ync1ibTYAn9O8-nWZtJWequGgJrTxezJunJflmFxHAdkQk-i-K-zcENP3ojzgMkWKbdHNS_QbzG1sDSxoaK1zA1dZN80XPpPK6PvVl1LIX20UVWIhGQWfGmv24BFKeLSE_wEjKEG_HA_ILup1YixfLRr4vVhFRTZ-lGT6_oyj54WnFTniT22I3FG9bixObK5LSxN-53rjSEb6T3DI2bGQOj0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
