Re: [stir] PASSporT extensions: order of claims

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 14 March 2018 12:00 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F271271DF for <stir@ietfa.amsl.com>; Wed, 14 Mar 2018 05:00:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.42
X-Spam-Level:
X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oJoZC2YI4aY for <stir@ietfa.amsl.com>; Wed, 14 Mar 2018 05:00:51 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A97E0126CC7 for <stir@ietf.org>; Wed, 14 Mar 2018 05:00:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521028849; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=81hiP0tVqTDxFR/+hzk0gUc0zfcvXbMZNDbOng+7MWY=; b=VfOWUtJsC9AGgFHWRWlytjc/Z0LEh6mLw6m8lmgjF8462GfKfyuyOwYUCMCh/YyO ufjebQhkAyIsP7opvWoVYefLE0mh9PUijAQm6thueYgf7eIeb7pp26EXE3URNaoB xdJ52R4tHpl8EW4xIJqZ5is0lKODaFGXlAsJYGVpUw8=;
X-AuditID: c1b4fb2d-87c029c000005540-d6-5aa90ef08927
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0F.CA.21824.0FE09AA5; Wed, 14 Mar 2018 13:00:49 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.172]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0382.000; Wed, 14 Mar 2018 13:00:33 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Chris Wendt <chris-ietf@chriswendt.net>
CC: "Politz, Ken" <Kenneth.Politz@team.neustar>, "stir@ietf.org" <stir@ietf.org>, "adam@nostrum.com" <adam@nostrum.com>
Thread-Topic: [stir] PASSporT extensions: order of claims
Thread-Index: AdO4Vc+a+PS/xYPIRfO1T1CAVYYAVAAHa1xAAJ5T3oAAA66kkP//+HEA///ksgCAASxRgIAAKGgA
Date: Wed, 14 Mar 2018 12:00:33 +0000
Message-ID: <D6CED8EF.2CC5B%christer.holmberg@ericsson.com>
References: <7594FB04B1934943A5C02806D1A2204B6C1D17C1@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C1D1804@ESESSMB109.ericsson.se> <8B0E0275-68BD-41E9-B128-589F13C06D66@chriswendt.net> <7594FB04B1934943A5C02806D1A2204B6C2007A0@ESESSMB109.ericsson.se> <46946849EEFF3043A8FBCC3D102A2C1A3FCADE50@stntexmb13.cis.neustar.com> <7594FB04B1934943A5C02806D1A2204B6C200A0A@ESESSMB109.ericsson.se> <08B1E835-CA5E-4636-AE0E-983F3EFA82C1@chriswendt.net>
In-Reply-To: <08B1E835-CA5E-4636-AE0E-983F3EFA82C1@chriswendt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.16]
Content-Type: multipart/alternative; boundary="_000_D6CED8EF2CC5Bchristerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAIsWRmVeSWpSXmKPExsUyM2K7ou5HvpVRBi9cLfb8XcRuMf3TbmaL zR/WslgsX7uNyYHFY0LfGlaPJUt+MnnM2vmExeP1hjnsASxRXDYpqTmZZalF+nYJXBkfdx5i LPj7n7GibbJFA+One4xdjJwcEgImEkv62pi6GLk4hAQOM0r8PHWLGcJZwijxovseexcjBweb gIVE9z9tkAYRAW2Jw2cawJqZBSolZs2dzQxiCwOVTNj3kBWixlJi8rv1zCCtIgJRErMmuIOE WQRUJc5NOcIOYvMKWEu83/YfatVFZokld7+wgCQ4BZwk2qadYAOxGQXEJL6fWsMEsUtc4taT +UwQRwtILNlznhnCFpV4+fgf2F5RAT2JDSdus0PEFSV2nm1nhuhNkOhdt54FYrGgxMmZT1gm MIrOQjJ2FpKyWUjKIOIGEu/PzWeGsLUlli18DWXrS2z8cpYRwraWOHBmOzuymgWMHKsYRYtT i4tz042M9VKLMpOLi/Pz9PJSSzYxAuP14JbfujsYV792PMQowMGoxMP7m2lllBBrYllxZe4h RgkOZiUR3q0yK6KEeFMSK6tSi/Lji0pzUosPMUpzsCiJ85705I0SEkhPLEnNTk0tSC2CyTJx cEo1MFbf6Ord9Ghx68qHNXrL9d3Wvnjqe/BUnsz2zifPjYRZEs/e3nWrp2OHTd2k5IKpF9yL n19pV4+b/yrnbOePkH/Hn17P2Pp93hWno3N67PfOYmF8svyT9IqjdpuZ69xqTMyDK5zfcUw+ rrVsatHq8+Els/dvu3DQy0ut99OuxDUK++dL2j0v+VisxFKckWioxVxUnAgA3DhAftMCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/VqAcrLyjZEyTTceqhlKniTpH0jU>
Subject: Re: [stir] PASSporT extensions: order of claims
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Mar 2018 12:00:53 -0000

Hi,

> 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.

Correct. I wasn’t questioning the need for ordering, but maybe I wasn’t clear about that :)

> 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.

It depends on what is meant by “concern”. When people define PASSporT extensions future, they will not look at this e-mail thread – they will read RFC8225. We shouldn’t have MUSTs if they don’t mean anything.

Anyway, as far as the current PASSporT extensions are concerned, maybe we could solve the issue by including a statement saying something like:

“The order of the claims within the PASSporT <insert-name-of-PASSporT extension> JSON object does not matter. However, as defined in Section 9 of RFC8225, when the JSON serialisation takes place, the claims must be placed in lexicographic order”

Regards,

Christer






On Mar 13, 2018, at 3:58 PM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:

Hi,

>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?

Regards,

Christer

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Tuesday, March 13, 2018 2:47 PM
To: Chris Wendt <chris-ietf@chriswendt.net<mailto:chris-ietf@chriswendt.net>>
Cc: stir@ietf.org<mailto:stir@ietf.org>; adam@nostrum.com<mailto:adam@nostrum.com>
Subject: Re: [stir] PASSporT extensions: order of claims

Hi,

>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?

Regards,

Christer


On Mar 10, 2018, at 8:27 AM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:

Section 8.3 of RFC 8225, that is.

From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 10 March 2018 15:26
To: stir@ietf.org<mailto:stir@ietf.org>
Cc: adam@nostrum.com<mailto:adam@nostrum.com>
Subject: [stir] PASSporT extensions: order of claims

Hi,

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:

draft-ietf-stir-rph-03
draft-ietf-stir-passport-shaken-01
draft-ietf-stir-passport-divert-02

…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.

Regards,

Christer


_______________________________________________
stir mailing list
stir@ietf.org<mailto:stir@ietf.org>
https://www.ietf.org/mailman/listinfo/stir<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=ww1S9BHEcpE4MMUbgGQrsoL-SK3UCGY33Koaj2h9zYw&m=_DBdmUKpkUAUVv120PuHoMt-TVtTuzOHsfFQdAWmeFs&s=yYY6kvNSlx7W84nXLfYP7n4PSH0S7Uiq3VK2FI6iwEU&e=>