Re: [stir] WGLC: draft-ietf-stir-passport-rcd-09

[Chris Wendt <[e-mail]>]

Hi Ben, All,

I’ve gone through your comments and will release a forthcoming 19 with your comments and Russ’s comments addressed.
I recognize this is a day before our STIR meeting, but thought it would be best to have it available, hoping this should be fairly complete in terms of addressing comments.

-Chris

> On Apr 29, 2022, at 5:44 PM, Ben Campbell <[e-mail]> wrote:
> 
> Hi,
> 
> I think version 17 is in pretty good shape, and I think we’ve handled the “hard” problems. I have some mostly minor comments There are a few that I probably should have noticed on previous versions. Hopefully they don’t fall too far outside of Russ’s guidance for feedback, and in any case I don’t think they are showstoppers:
> 
> Substantive:
> 
> §3, 2nd paragraph: This should probably mention “icn” in the first category, since it is separate from jCard data.

Yes agree, added a reference to icon data.

> 
> §6.1.2: “Even though this is probably not the typical case, an "rcdi" JSON pointer or integrity digest is optional if the image value is directly included via a data URI.”
> 
> Apologies, I should have caught this one in an earlier version. But wouldn’t a data: URL typically point to a body part that is not covered by the PASSporT signature? If so, it could be subject to tampering in route. Would that need integrity protection less than a HTTPS URL? I guess tampering would require an on-path attacker. But I am still skeptical of the exception unless the data: URL points to data covered by the PASSporT signature.

My understanding is that data URIs (rfc2397) always include the data inline, so would not be separate from the data:.  Here is an image example: data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==

That said, i included an explicit reference to RFC2397.

> 
> $9.3: Third example: Some of the examples shows a jcard photo and logo URIs, but no “icn” keys. Given the guidance to use “icn” for a default image, should “icn” keys be included?

Yes i included two examples, one with https and one with data URIs

> 
> §14.2, 2nd paragraph: “Similarly, the "jcd" or linked "jcl" jcard information and "crn" can be optionally, based on local policy for devices that support it, used to populate a Call-Info header field following the format of [I-D.ietf-sipcore-callinfo-rcd].”
> 
> Should this mention “icn”?

Added both “icn” and “apn"

> 
> §18 (Apologies, these are probably things I missed in previous versions:
> 
> First paragrapoh: The normative MUST seems dubious. Can we assert normative requirements to ecosystems we don’t control?

Changed to SHOULD

> 
> Third paragraph: “may be a recommended way “. I suggest “may be a useful way” or “is a recommended way”.

Fixed


> 
> Editorial comments:
> 
> §4, 3rd paragraph: “pass-by-value or passed-by-reference;”
> Inconsistent use of “pass” vs “passed”. Either is okay, but we should pick one.

Fixed

> 
> §4, table, first row, 2nd column: s/RDC/RCD

Fixed

> 
> §5.1.1: “If there is no string associated with a display name, the claim value MUST then be an empty string.”
> Should “claim value” be “key value”?
> 

I think claim value is appropriate, "key value" is generic to JSON, but claim value is specific to JWT.  I actually recall being told to use this terminology by JWT folks.

> 
> 
> 
> 
>> On Apr 25, 2022, at 2:51 PM, Russ Housley <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> This might be the longest WG Last Call in history ....
>> 
>> A new version was just posted: https://www.ietf.org/id/draft-ietf-stir-passport-rcd-17.txt <https://www.ietf.org/id/draft-ietf-stir-passport-rcd-17.txt>
>> 
>> Regarding the ongoing WG Last Call, we have two questions:
>> 
>> (1) Have any of the changes introduced new issues?
>> 
>> (2) Have all previously raised issues are resolved?
>> 
>> For the STIR WG Chairs,
>>  Russ
>> 
>> 
>>> On Dec 8, 2020, at 4:30 PM, Robert Sparks <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> This is a WGLC for draft-ietf-stir-passport-rcd-09.
>>> 
>>> Please send reviews to the list by the end of day 22 Dec 2020.
>>> 
>>> If you plan to provide a review but need more time, please let us know early.
>>> 
>>> See <https://datatracker.ietf.org/doc/draft-ietf-stir-passport-rcd/ <https://datatracker.ietf.org/doc/draft-ietf-stir-passport-rcd/>>
>>> 
>>> RjS
>> 
>> _______________________________________________
>> stir mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/stir
> 
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir