[stir] Comments on draft-ietf-stir-rfc4474bis-13.txt
Alan Ford <alan.ford@gmail.com> Sun, 02 October 2016 11:17 UTC
Return-Path: <alan.ford@gmail.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 93A2D12B012 for <stir@ietfa.amsl.com>; Sun, 2 Oct 2016 04:17:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 cZQTqTLVbU1R for <stir@ietfa.amsl.com>; Sun, 2 Oct 2016 04:17:06 -0700 (PDT)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990891288B8 for <stir@ietf.org>; Sun, 2 Oct 2016 04:17:06 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id f193so8577280wmg.0 for <stir@ietf.org>; Sun, 02 Oct 2016 04:17:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:message-id:date:to:mime-version; bh=5mbIpJdjiERHrS8oKoTnosOlX0RJ2mX5wBu5gw9lQVM=; b=ELBM/lYtdU6YzRJq2YxQ1PmbHkZkHaWY5sPHL7YjzuvK4JHZcSogsQV36QJLhgzTOf pFpaX9bBdVrUVbkJvxo3gBNONCxxp/SVnb4wmWbtezKHgKGHNq7i343XA9BSfz+dRBob V+qc99ZII1JTItWtWr0cSRV+gYVsldQmqtOnbPnekd1TesbFC7SNj27lgIY0okf+W7qI dE+XuWJN4/pQyrykuVDr5Ht7qws5Zh8lY+UQ1mtaKzm7iukqTxPgSotRW7Y91QZq04yk ODZ1BGTDPl6zgWoaK44ce4FlrDBzwInwVoGP/rPjhyvPMgsPG3DKeKF+xkmbjJlW2ckn 0/Lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=5mbIpJdjiERHrS8oKoTnosOlX0RJ2mX5wBu5gw9lQVM=; b=kOKUJM5ZyFDJdwuzXZl52Mc5aGIPmYK+L8+OmyK7+Ohm+fo6siC0kRPP26tlK6knXr XlKRgqaXvFckilORfkIzyza1IQMI3KU5sNqJ61mrg6GQgbNv3pl8pYN6ie/B12MEKSdL kETHKlpvidtzldjSDBvrt5yLkA+F2sfz4qPArAyMenGvw19U2VQVf733Ox6HKBsFwGiz owWJJ3IdQrxGU35tIYBqJGFMebD6EvmH1ptY0InR+EL8+6xeNFZTYjBMr6ibwjiSTlvt Q5NZhzVvubucQiBb1TfITmeWA60nlDOqYCmR58NEIoqHZMmZIhjJQpIaPUFqxxIAngFL +jkA==
X-Gm-Message-State: AA6/9Rmo+pJarCRTHuPRnYJvrSZPQAnVLNa2Zx5OGAVABn4XfrdnorhY1dspizExp091lQ==
X-Received: by 10.28.50.3 with SMTP id y3mr4908895wmy.23.1475407022743; Sun, 02 Oct 2016 04:17:02 -0700 (PDT)
Received: from alans-mbp.lan (80.61.112.87.dyn.plus.net. [87.112.61.80]) by smtp.gmail.com with ESMTPSA id x124sm13532848wmf.22.2016.10.02.04.17.02 for <stir@ietf.org> (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 02 Oct 2016 04:17:02 -0700 (PDT)
From: Alan Ford <alan.ford@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_50E56BAE-A4C1-40AE-B16B-0247DC8190ED"
Message-Id: <D85061A2-B778-4213-92F2-56EBF4170A9E@gmail.com>
Date: Sun, 02 Oct 2016 12:17:58 +0100
To: stir@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/fkaeCpjVTTmYzwDGpDMiWmJnwGU>
Subject: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 02 Oct 2016 11:17:08 -0000
Hi all, In general this clarifies a number of the issues raised, and I feel the use of the compact/full distinction is much clearer for current and future implementors than “canon". However, there is still opportunity for providing guidance of when to use each form, to avoid interop issues further down the line. In particular, in Section 6.1, it says: An authentication service MAY use the full form of the PASSporT in the Identity header field. The presence of the full form is OPTIONAL because the information carried in the baseline PASSporT object's headers and claims is usually redundant with information already carried elsewhere in the SIP request. Using the compact form can significantly reduce SIP message size, especially when the PASSporT object contains media keys. The syntax of the compact form is given in [I-D.ietf-stir-passport <https://tools.ietf.org/html/draft-ietf-stir-rfc4474bis-13#ref-I-D.ietf-stir-passport>] Section 6 <https://tools.ietf.org/html/draft-ietf-stir-rfc4474bis-13#section-6>; essentially, it contains a base64 encoding of the JSON header and payload in the PASSporT object. Firstly, "essentially, it contains a base64 encoding of the JSON header and payload in the PASSporT object” surely is a typo? The compact form contains a base64 encoding of the signature? This text also does not clarify why you would want to use the full form when not using optional extensions. The point I have been making in earlier mails, and which I feel would be valuable to add to the document, is something along the lines of “If, however, a sender does not know how a receiver may canonicalise the source or destination addresses, for example if it does not know whether tn, uri, or both would be used, then it SHOULD include the full form.”. (Section 8 makes comments along these lines but not as explicitly). Also, in Section 6.2.3, it talks about using the full form to help with canonicalisation of orig: As an optimization, when the full form is present, the verification service MAY compute its own canonicalization of an originating telephone number and compare it to the values in the "orig" element of PASSporT before performing any cryptographic functions in order to ascertain whether or not the two ends agree on the canonical number form. I think it would be helpful to also point out it helps with the canonicalisation of dest, by adding a sentence such as: “Similarly, the presence of the full form allows the receiver to see how the sender canonicalised the destination address(es), such as whether it was canonicalised to a tn, a uri, or both, and so this can help the receiver know how to canonicalise the headers and thus verify the claims.” Regards, Alan
- [stir] Comments on draft-ietf-stir-rfc4474bis-13.… Alan Ford
- [stir] Comments on draft-ietf-stir-rfc4474bis-13.… N WEINRONK
- Re: [stir] Comments on draft-ietf-stir-rfc4474bis… Richard Shockey
- Re: [stir] Comments on draft-ietf-stir-rfc4474bis… Alan Ford
- Re: [stir] Comments on draft-ietf-stir-rfc4474bis… Alan Ford
- Re: [stir] Comments on draft-ietf-stir-rfc4474bis… Chris Wendt
- Re: [stir] Comments on draft-ietf-stir-rfc4474bis… Richard Shockey
- Re: [stir] Comments on draft-ietf-stir-rfc4474bis… Peterson, Jon
- Re: [stir] Comments on draft-ietf-stir-rfc4474bis… Alan Ford
- Re: [stir] Comments on draft-ietf-stir-rfc4474bis… Peterson, Jon
- Re: [stir] Comments on draft-ietf-stir-rfc4474bis… Alan Ford
- Re: [stir] Comments on draft-ietf-stir-rfc4474bis… Peterson, Jon