Re: [stir] [EXTERNAL] Re: PASSporT extensions: order of claims

"Politz, Ken" <> Wed, 14 March 2018 13:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1CB1912D0C3 for <>; Wed, 14 Mar 2018 06:43:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-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 0_NuEEzcRP8U for <>; Wed, 14 Mar 2018 06:43:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7F07112D775 for <>; Wed, 14 Mar 2018 06:42:57 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id w2EDWtPY004752; Wed, 14 Mar 2018 09:42:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=selector1; bh=YXEehS8X1/paOFflZ+vMjOtIm2Z5eYI43QhObaWv2EU=; b=bps22rZiUoCQKdsxv9SPza+oVjGxlx9MIRx9HgGx8MOFVKORA423vtkSUQCtqwgRbdZV 93alxO8Q9YMgiBLklsgXSg8vc8cN59jyiviNm7dg/xVAYVwI0Lz2+bGxsrKvELMsdWdU AdKgaXSpLS7Z8pELFlBmfBealEVhfsU0Hr9zb2VjTKhUgh6kQQ47jMaO9feV8AjFtRCU 1jtWsd+NKT5phlYCuNdE99AvYmpL68MFj+A7/Ck1taiCPujpYM3ZyggpkWUYVPMYUhA4 95DDglLA6gF621MV6N0DAZoJyhVDE8alszKsIoeJUSGN6TmLi8ydLzE7O28MIirQnt8K mQ==
Received: from ([]) by with ESMTP id 2gmaw35v2d-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Mar 2018 09:42:52 -0400
Received: from ([]) by ([::1]) with mapi id 14.03.0279.002; Wed, 14 Mar 2018 09:42:51 -0400
From: "Politz, Ken" <>
To: Chris Wendt <>, Christer Holmberg <>
CC: "" <>, "" <>
Thread-Topic: [EXTERNAL] Re: [stir] PASSporT extensions: order of claims
Thread-Index: AQHTuvvKLoGLTt5520aG5ALLxR8fX6POigGAgAERWYiAACL8UA==
Date: Wed, 14 Mar 2018 13:42:51 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_46946849EEFF3043A8FBCC3D102A2C1A3FCAF4E9stntexmb13cisne_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-14_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803140155
Archived-At: <>
X-Mailman-Approved-At: Wed, 14 Mar 2018 11:23:11 -0700
Subject: Re: [stir] [EXTERNAL] Re: PASSporT extensions: order of claims
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Mar 2018 13:43:05 -0000

All I can say is that, with relatively limited SHAKEN industry testing, JSON key order has come up twice.  As new extensions get added and for interoperability purposes, I would request that clarity be provided in related specs with consistent examples for implementers.  Thanks, Ken.

From: Chris Wendt []
Sent: Wednesday, March 14, 2018 7:36 AM
To: Christer Holmberg <>
Cc: Politz, Ken <>ar>;;
Subject: [EXTERNAL] Re: [stir] PASSporT extensions: order of claims

Perhaps its a bit over prescriptive, i think the intention was only to say that it should be documented what claims and provide order and examples.  It wasn’t to imply that it would be different or there would be implications of order or anything.

To step up a level, in general, JSON object key order never matters, it’s a key value object that you index on key, so order in most cases is arbitrary.  For PASSporT, we have a short form that is supported in RFC8224, where you don’t need to send the header/claims because those objects are already in the SIP INVITE.  So we needed a way to have the header/claims to be reconstructed in a predictable and reproducible way.  An therefore the dependency on order.

So again, yes we say you should say order in RFC8225, which i would say would inherently be the case with an example at a minimum.  A MUST might have been a bit strong, but i don’t see this as a huge concern.  I’d be curious to hear from others whether they think this is a real concern or not.

On Mar 13, 2018, at 3:58 PM, Christer Holmberg <<>> wrote:


>Try RFC 8225, Section 9, perhaps?

Ok, so if that’s a generic rule, why the statement saying that PASSporT extensions must specify the order?



From: Christer Holmberg []
Sent: Tuesday, March 13, 2018 2:47 PM
To: Chris Wendt <<>>
Subject: Re: [stir] PASSporT extensions: order of claims


>I would agree with the text, the only caveat i would point out is that the extension definition has
>no choice to the order other than alphabetic order, so the order is essentially implied.  So, it’s sort
>of a technicality that maybe we didn’t anticipate, but i think technically you are correct.

Not sure I understand the has-no-choice part. Where is it said that the claims must be ordered in alphabetic order? We could for sure specify it that way, but based on your e-mail it seems like it is already specified somewhere?



On Mar 10, 2018, at 8:27 AM, Christer Holmberg <<>> wrote:

Section 8.3 of RFC 8225, that is.

From: stir [] On Behalf Of Christer Holmberg
Sent: 10 March 2018 15:26
Subject: [stir] PASSporT extensions: order of claims


Section  says:

   “Specifications that define extensions to the PASSporT mechanism MUST
   explicitly specify what claims they include beyond the base set of
   claims from this document, the order in which they will appear,…”

When looking at the extensions we are currently working on:


…I don’t see anything about the order in any of the documents.

I think it would be good to have a dedicated “Order of claims” section, or something similar, in each extension specification.

When looking at the examples in the drafts above, it seems like even the base claims are in different orders. Not sure whether there is an explicit requirement that they need to be in order, thought.



stir mailing list<><>