Subject: Re: [stir] Third WGLC: draft-ietf-stir-passport-rcd-12

From: Jack Rickard <[email-masked]>
Date: Fri, 6 Aug 2021 12:45:19 +0000

I have a few, hopefully minor, comments around clarifying rcdi digests.

In all of section 6, the rules for creating the digest are reasonably complicated having test vectors in the form of valid examples would be very useful. The first example doesn't have a corresponding "rcd" that it was generated from, and the following examples ("sha256-30SFLGHL40498527", etc) look too short to be valid.

In section 6, the penultimate line states "The subsequent characters are the base64 encoded digest of...", I have the standard questions around base 64 encoding, which flavour (+ / or - _), and should it include trailing =.

At the end of section 6.1, point 3 states that the URI content should be Base64 encoded if it's binary, this invites the same questions as above. Alternatively, why encode them at all? All hash functions should be fine taking arbitrary bytes and treating all URIs the same would simplify things.

Jack

-----Original Message-----
From: stir <[email-masked]> On Behalf Of Russ Housley
Sent: 29 July 2021 20:19
To: IETF STIR Mail List <[email-masked]>
Subject: [EXTERNAL] [stir] Third WGLC: draft-ietf-stir-passport-rcd-12

As we discussed on the IETF 111 session today, significant changes were made to address concerns that were raised during the second WGLC.

This note begins a third WGLC for draft-ietf-stir-passport-rcd-12 (PASSporT Extension for Rich Call Data).  See https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-stir-passport-rcd%2F&amp;data=04%7C01%7Cjack.rickard%40microsoft.com%7Cec8dd8519858402472db08d952c5c31e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637631832214037400%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Xiozp95qdNzxPHDV3rIhbixkdGgrff8yfRpqa2%2BPp3Q%3D&amp;reserved=0.

Please send reviews to the STIR mail list by the end of day 19 August 2021.

Russ and Robert
_______________________________________________
stir mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&amp;data=04%7C01%7Cjack.rickard%40microsoft.com%7Cec8dd8519858402472db08d952c5c31e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637631832214037400%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2nVZxdxT53m%2FDe2unHIxA86pTXVERyxD0CuN6C4WMPM%3D&amp;reserved=0

---

From: Chris Wendt <[email-masked]>
Date: Mon, 30 Aug 2021 11:18:00 -0400

Hi Jack,

Thanks for the review! Comments inline

> On Aug 6, 2021, at 8:45 AM, Jack Rickard <jack.rickard=[email-masked]> wrote:
> 

I fixed the examples calculating specific hash.

> In section 6, the penultimate line states "The subsequent characters are the base64 encoded digest of...", I have the standard questions around base 64 encoding, which flavour (+ / or - _), and sho…

RFC4648 pretty much says implementations can ignore “=“, so while i think the intent is for no “=“ for no other reason than it’s not necessary, and the examples i’ve included don’t show them either, i don’t think it would break Base64 decoder implementations if they were included or not included.

> At the end of section 6.1, point 3 states that the URI content should be Base64 encoded if it's binary, this invites the same questions as above. Alternatively, why encode them at all? All hash fun…

Yeah i think i confused things and got the base64 procedure backwards, so i fixed that text to say that either string/binary input should be hashed and the output value should be in base64 format.

I will be releasing new version soon once i finish fixing Ben’s comments.

> https://www.ietf.org/mailman/listinfo/stir