Re: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt

Chris Wendt <> Thu, 13 October 2016 12:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F5C9129423 for <>; Thu, 13 Oct 2016 05:45:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 2QpI82mfsBF6 for <>; Thu, 13 Oct 2016 05:45:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0030B129437 for <>; Thu, 13 Oct 2016 05:45:33 -0700 (PDT)
Received: by with SMTP id o68so133101604qkf.3 for <>; Thu, 13 Oct 2016 05:45:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=IOKM9wyT3XX1XiGPNzamhAWZUAI3cLOWadzwC7My4YE=; b=QwluUuek7is7ntuu1i7l5YMlNwU3kR0XOW/1GSvYlrwkrfSGYMXA+EcTkcDEvbvplB CHms3MZKic8kyfA4tKu2y3EYReViXQH77ttv2I1GadmjyfnjCfjjU9QElhQXKacqWEtt g97swUVjJTTi9yIXLk6uRvnSiDAynkOs7Rp1TIfzTsOYVvlq1p0ecOOxakTlxRqQ3444 wcd2qtvOrJiQSTSRBnuANk0BKzM5CO5gRv2mFLNzEAvaLw9A+4E8dnoB/QfVbUxANn83 Xxc33Pd+ulk7VBN7wyDd8bGH/mGYMspKLbRFJuTfPrKWAkp0koOPmpQgOttnC+3a/bWU y5aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=IOKM9wyT3XX1XiGPNzamhAWZUAI3cLOWadzwC7My4YE=; b=hCfelKwm8mPZkIc5NErCXOJvamHRkh13btrLR8Ei66JqJnM6pc8ZBAlRZfZyeRVyoQ ueJvWkGcdPhB8A1t4gBKXiYjx5M+tBn5DJ1JYe02T5KFoDPlzhgoLVA82SCUv9ZXN2YG bgJweCUYiQwSUVyTJUEL732zZ778i+PlKzxI+r+2dwFqUSw+Vq3nWmQIx+GPiDDeGv9e KdrYuKXhLfzOHfHmvXkosxRIVMMwqNRdMi5mK7o9/nPWxYV8+lhBKM+s3uLT4jtOGGvz 4IJEhQESjWzRy/GXy9aNjX1z8o7MhcTqFYacim+SNpARCIdbr+RssbI6hMEO068+Ixl+ 752A==
X-Gm-Message-State: AA6/9RmXaoP7eItBYj5GAGGnC+UZcBJPNRJduqhjzqfbihEonrPCuXF7woDK0HJaEwYH0g==
X-Received: by with SMTP id l3mr5790001qkd.128.1476362733052; Thu, 13 Oct 2016 05:45:33 -0700 (PDT)
Received: from ?IPv6:2601:a40:100:d3:1b2:f6f3:144f:901c? ([2601:a40:100:d3:1b2:f6f3:144f:901c]) by with ESMTPSA id p22sm4653867qka.43.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Oct 2016 05:45:32 -0700 (PDT)
From: Chris Wendt <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_84B5D688-BD74-4F9E-BC2A-BCAD8F7FB71F"
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
Date: Thu, 13 Oct 2016 08:45:31 -0400
In-Reply-To: <>
To: Alan Ford <>
References: <> <>
X-Mailer: Apple Mail (2.3226)
Archived-At: <>
Subject: Re: [stir] Comments on draft-ietf-stir-rfc4474bis-13.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Oct 2016 12:45:36 -0000

We will be using the full form of PASSporT in the SHAKEN framework, but I don’t think we should necessarily remove compact form, there are applications that may want to use it, particularly in more controlled eco-systems.

Obviously, Appendix F in RFC7515 is evidence that other people are thinking about these uses of JWT as well.

> On Oct 13, 2016, at 4:05 AM, Alan Ford <> wrote:
> Hi all,
> Does anybody else have any thoughts on this? I still fear I may be missing something, but in its present form I see there being a lot of unnecessary deployment headaches around canonicalisations and the need to go into a 438 exchange. Guidance on the use of full form (which in reality would probably lead to the use of full form in most scenarios) would seem to make this much easier. I personally think this issue needs to be resolved before publication.
> Regards,
> Alan
>> On 2 Oct 2016, at 12:17, Alan Ford < <>> wrote:
>> 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 <>] 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 mailing list