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

I have one additional thought that I am sending separately because it is not really a comment on draft-ietf-stir-passport and probably more a SIPCORE issue than a STIR one:

§9.2: “Consequently, if URIs with contents covered by integrity digests are passed to another entity, the corresponding integrity digest MUST also be included, for example by passing the PASSporT.”

 I understand some SPs plan to strip the passport and verify/modify SIP header fields to convey the RCD.  Conveying the digest outside of the PASSporT may become important sooner than later. We talked about defining a way to add the digest to SIP header fields. Do we have concrete plans to do that? I don’t see any mention in draft-ietf-sipcore-callinfo-rcd. 

OTOH, maybe we can encourage SPs to just send the passport already :-)

Thanks!

Ben.

> On Apr 29, 2022, at 4:44 PM, Ben Campbell <ben@nostrum.com> 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.
> 
> §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.
> 
> $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?
> 
> §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”?
> 
> §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?
> 
> Third paragraph: “may be a recommended way “. I suggest “may be a useful way” or “is a recommended way”.
> 
> 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.
> 
> §4, table, first row, 2nd column: s/RDC/RCD
> 
> §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”?
> 
> 
> 
> 
> 
>> On Apr 25, 2022, at 2:51 PM, Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>> 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 <rjsparks@nostrum.com <mailto:rjsparks@nostrum.com>> 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
>> stir@ietf.org <mailto:stir@ietf.org>
>> https://www.ietf.org/mailman/listinfo/stir
> 