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

Chris Wendt <> Mon, 30 August 2021 15:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 76FF03A1642 for <>; Mon, 30 Aug 2021 08:18:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L9tVoXpM6-OA for <>; Mon, 30 Aug 2021 08:18:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1047C3A164F for <>; Mon, 30 Aug 2021 08:18:02 -0700 (PDT)
Received: by with SMTP id ew6so8487588qvb.5 for <>; Mon, 30 Aug 2021 08:18:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zXS7cIpfSD1/pJQdCmGb+M+eG3p/7uJq3bp9nxP6NEk=; b=OooBYVMBuRcst5z9Jnk+7R5XwPZvymcLpgduBGe/U0bWqAdwLuJBsx0XSPr0ZjYQLK ra+dYkEjtN8CKH3r+YjlnStXr4goSOlO+H3maqJnTa8/T4opEn46iq2G8lQd/ZrkscTB rEm8H3xknRcHqnbJRGaOCBol0j76hNCKXkePmJP8ZYCaemZM3RkJgJLWme3dsw7zipBX TStiRG4oRaR9Jc9RGXVSVwTe5CWh4lSAN/qXbhaD1w/oj1h/ReoluJZzoTpuZPkvY8/X mmoz61kDwMBURRnVXjRHnprxljEcGD5qfzrda+1Ze7NM0YWJWGQ+zZKL5ULxJLOVnbeB I5mg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zXS7cIpfSD1/pJQdCmGb+M+eG3p/7uJq3bp9nxP6NEk=; b=HP+VHfj88+ET9cCwZ19TGgQjCo8uh7ZzKQOdAgQGPtnRt/QFH6X8cYQ+RPDOzhPgsv JUrvFZW9ppqaLtTIypHkn7wu6P0QOBWxYl+zADBvSzdssIKME6UFydB+r4rnxE9b7I+9 MgYxItRfhpPkHy1lTAhg107cjMry0MNE5Z76xLPVlV16wK7oaf4e9t6T+yA+NVWAHkkn s4I2H38G17UqR5E3i/R3+zVcoPJJGUkUlT3SYxII4gCSflO79IZqs0RSLTpwFcxQnCXL Bh1Yc2P3RS9uXJmWfNXacEY+5q0+qkmVGYcbweYw4RXpQxKBlPZCPnSlE0HIDeBePhhC e9CQ==
X-Gm-Message-State: AOAM533gnxxKrxm6VfxD0N7/nkmw9npvfil+H7PW2ZHgtzBwy6LPp3IA Sdj2gti7z9VCz1Coop6YjU3Z/NYLfSGEHVEN
X-Google-Smtp-Source: ABdhPJxNuxHmFl5YlMocHNo28bI/vZhyDUlAEuW4QOcUouclfqH2bDTYkIIQFv/xcQyUIISx5yspSg==
X-Received: by 2002:a0c:9103:: with SMTP id q3mr24006597qvq.36.1630336682050; Mon, 30 Aug 2021 08:18:02 -0700 (PDT)
Received: from ( []) by with ESMTPSA id i14sm8622548qtx.64.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Aug 2021 08:18:01 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Chris Wendt <>
In-Reply-To: <>
Date: Mon, 30 Aug 2021 11:18:00 -0400
Cc: IETF STIR Mail List <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Jack Rickard <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [stir] Third WGLC: draft-ietf-stir-passport-rcd-12
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Aug 2021 15:18:15 -0000

Hi Jack,

Thanks for the review! Comments inline

> On Aug 6, 2021, at 8:45 AM, Jack Rickard <> wrote:
> 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.

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 should it include trailing =.

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 functions should be fine taking arbitrary bytes and treating all URIs the same would simplify things.

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.

> Jack
> -----Original Message-----
> From: stir <> On Behalf Of Russ Housley
> Sent: 29 July 2021 20:19
> To: IETF STIR Mail List <>
> 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;;sdata=Xiozp95qdNzxPHDV3rIhbixkdGgrff8yfRpqa2%2BPp3Q%3D&amp;reserved=0p;reserved=0.
> Please send reviews to the STIR mail list by the end of day 19 August 2021.
> Russ and Robert
> _______________________________________________
> stir mailing list
> _______________________________________________
> stir mailing list